I started playing around with this and think I found a bug when using SubTextures. My particles are all invisible.
The switch from PDParticleSystem to FFParticleSystem was mostly painless once I created a lookup for SystemObjects. No problems here.
I know the pfx are running fine because all the timings and onComplete event dispatches are still happening, so it's just a texture issue.
I'm creating my SystemOptions from a SubTexture that I just grab from AssetManager. This is how PDParticleSystem works so I think this will be a common port case.
var so : SystemOptions = SystemOptions.fromXML(
PuzzleFuzz.assets.getXml( _name ),
PuzzleFuzz.assets.getTexture( _name ) );
One thing of note is that I save out my texture atlases in non-POT and then init starling in BASELINE_CONSTRAINED profile which automatically sizes them to POT. (Smaller png filesize this way.)
I noticed in SystemOptions.updateFrameLUT() around line 580 you check for a SubTexture and then do some math to create the Frame. It's possible that this math is not accounting for my non-POT situation. Could you describe the purpose of your Frame class and its public members and I can validate the math and try to correct it if it's wrong?
I already tried saving out my atlas with POT dimensions and indeed the pfx started showing up so it is a bug related to non-POT atlases.
To give you some data my png is 1319x512 but the SubTexture.root ConcreteTexture reports 2048x512 on nativeWidth/Height which throws off multiplying by the SubTexture.clipping rect.