I noticed in FFParticleSystem.initInstance that textures that are SubTextures build their frame by referencing SubTexture.clipping multiple times.

var frame:Frame = new Frame(1, 1, st.clipping.x, st.clipping.y, st.clipping.width,
    st.clipping.height, st.rotated);

The clipping property on SubTextures must generate the clipping from scratch each time, here it is from Starling 1.8:

public function get clipping():Rectangle
{
    var topLeft:Point = new Point();
    var bottomRight:Point = new Point();

    MatrixUtil.transformCoords(mTransformationMatrix, 0.0, 0.0, topLeft);
    MatrixUtil.transformCoords(mTransformationMatrix, 1.0, 1.0, bottomRight);

     var clipping:Rectangle = new Rectangle(topLeft.x, topLeft.y,
         bottomRight.x - topLeft.x, bottomRight.y - topLeft.y);

     RectangleUtil.normalize(clipping);
     return clipping;
 }

Would it be more performant to call clipping once into a local var and use that var when initializing frame?

@shin10
Trying to compile the Demo I get these errors with Starling 2.3:

DemoStarlingMain.as(247): col: 26 Error: Call to a possibly undefined method createBuffers.
				ffpsStyle.effectType.createBuffers(4096, 16);
				                     ^
DemoStarlingMain.as(248): col: 37 Error: Call to a possibly undefined method createBuffers.
				FFParticleStyleClone.effectType.createBuffers(4096, 16);

Any idea on a workaroud in order to compile?

Hi,

The start method has no effect if called after the disappearance of all particles following a call to stop.

This behavior is a bit annoying because sometimes user would like to have a particles system which start, stop and restart later on. Perhaps start should handle internally the resume case. It's maybe easier to have only start and stop and remove resume.

The above issue seems to come from that condition in the start method :

if (mEmissionRate != 0 && !mCompleted) { ... }

If complete, impossible to restart by just calling start.

Thanks in advance for your feedback.

Used this extesion a lot, great work!

But after upgrading to Starling 2.0 it stops compiling //
starling.core.RenderSupport and starling.utils.VertexData not found anymore.

Are there any plans to update for 2.0 compatibility? Hoping there is not much to do.

I'm getting these error when I call start()
Error #1009: Cannot access a property or method of a null object reference.
.......FFParticleSystem.as:1738

that's mJuggler.add(this);

I'm using the standard code to initialize

                var particleTexture:Texture = Game.assets.getTexture("particle_bullet");
        var particleConfig:XML = XML(Game.assets.getXml("particle"));
        // create system options
        var sysOpt:SystemOptions = SystemOptions.fromXML(particleConfig, particleTexture);
        FFParticleSystem.init(1024, false, 512, 4);

        ps = new FFParticleSystem(sysOpt);
        ps.emitterX = 160;
        ps.emitterY = 240;
        addChild(ps);

        ps.start();

Hey, hate to open an issue here when I'm not sure if your project is to blame, but want to make sure you see it.

http://forum.starling-framework.org/topic/filter-error

I was wondering if it was possible if there could be issues related to the particles going beyond 2048 in dimension, or something like that?

Thanks! Feel free to close this issue if it's not applicable. :)

I have finished experimenting with FFParticle stress tests and although the performance is amazing I had an issue tracking down a memory leak which ended in FFParticleSystem.
In my current setup I relying on "FFParticleSystem.init(1024, false, 512, 8);" and "FFParticleSystem.dispose();" (resetting the particle system with different configurations for the current scene state). During a scene lifetime I spawn particle systems ( alot of them ). When "FFParticleSystem.dispose()" is called I noticed memory not being released. The static function "dispose()" calls internally for "disposePool()" which looks like this:

public static function disposePool():void
{
for each (var instance:FFParticleSystem in sInstances)
{
instance.dispose();
}

sParticlePool = null;

}

Following down the "instance.dispose()" method leads to this:

public override function dispose():void
{
sInstances.splice(sInstances.indexOf(this), 1); // <= modifies the length
removeEventListener(starling.events.Event.ADDED_TO_STAGE, addedToStageHandler);
stop(true);
mBatched = false;
super.filter = mFilter = null;
removeFromParent();

super.dispose();
mDisposed = true;

}

You call "sInstances.splice(sInstances.indexOf(this), 1);" which modifies the vector length and messes up the previous loop "for each (var instance:FFParticleSystem in sInstances)" resulting in a number of skipped instances not getting disposed. The quick fix I did was this:

for (var i : int=sInstances.length-1; i>=0; i--)
{
sInstances[i].dispose();
}

This bug does not lead to a memory leak but it can lead to a runtime error when after calling:
FFParticleSystem.dispose(), a "skipped from being disposed" ParticleSystem may be left on stage or inside a starling sprite and if you call dispose() on that sprite container it will iterate trough all children and call dispose on them. Call will brake when a particle system is encountered.

I have a particle that is longer than it is tall. The image file itself is 64x64 but when I set Texture Packer to trim whitespace it ends up as 64x25. I've also allowed rotations in Texture Packer. The combination of these two things seems to confuse FFParticleSystem about which dimension is the height and the width. So it mistakes the 25 for the width and scales up the particles accordingly (64/25 = 256% scale).

I can work around this issue by disallowing rotation in my texture atlas

Hi shin10,
I'm trying to add boilds movement for the particles, just like this:
http://blog.soulwire.co.uk/laboratory/flash/as3-flocking-steering-behaviors

two main feature are:

• boilds will chase and flying around an object or point.
• then boilds change to scatter state when going to move to another object.

Can you suggest some ways to apply this?

I'm getting the following error:

Error: Error #3694
    at de.flintfabrik.starling.display::FFParticleSystem/renderCustom()
    at de.flintfabrik.starling.display::FFParticleSystem/render()
    at starling.display::DisplayObjectContainer/render()
    at starling.display::Sprite/render()
    at starling.display::DisplayObjectContainer/render()
    at starling.display::Sprite/render()
    at starling.display::DisplayObjectContainer/render()
    at starling.display::Sprite/render()
    at starling.display::DisplayObjectContainer/render()
    at starling.display::Sprite/render()
    at starling.display::DisplayObjectContainer/render()
    at starling.display::Sprite/render()
    at starling.display::DisplayObjectContainer/render()
    at starling.display::Sprite/render()
    at starling.display::DisplayObjectContainer/render()
    at starling.display::Sprite/render()
    at starling.display::DisplayObjectContainer/render()
    at starling.display::Sprite/render()
    at starling.display::DisplayObjectContainer/render()
    at starling.display::Sprite/render()
    at starling.display::DisplayObjectContainer/render()
    at starling.core::Starling/render()
    at starling.core::Starling/nextFrame()
    at starling.core::Starling/onEnterFrame()

This can be reliably reproduced for my project when I trigger a context loss while loading my assets. To clarify, I can easily reproduce this by calling Starling.context.dispose() while AssetManager.loadQueue() is in progress (and the particle assets are part of the assets being loaded).

Any ideas for fixing this? The Event.TEXTURES_RESTORED appears to be coming back before the FFParticleSystem instances are created, so I'm not sure why it's problematic.

Has this already been updated to support Starling 2.1? Is this ready for release in a production app?

If you allow rotations in TexturePacker to save space, FFParticleSystem won't adjust for the rotation and instead draws the pfx in whatever orientation is saved to the atlas. Starling has had atlas rotation support since 1.5 so FFParticleSystem should support it as well for parity.