Particle emitter compatible with Particle Designer


#1

When I need particles for one of my games, I searched a bit, and found excellent Particle Designer 2 for mac. Although this app is a little expensive (€36.99) and sometimes crashes, it allows you to create particle systems in an easy way.

Then I started looking for particle emitter, compatible with OpenFL, but all I found – it is old and abandoned projects.

I decide to create my own library.

Demo - http://blog.zame-dev.org/pub/particles/html5-dom/

Features

  • Can load .plist files from Particle Designer or Particle Designer 2.
  • Has drawTiles renderer along with GL renderer.

More info about how to use it in my blog - http://blog.zame-dev.org/particle-emitter-for-openfl-compatible-with-particle-designer/


#2

My favorites are 4 and 8, 8 is cute :smile:


#3

Thanks! :slight_smile: Particle Designer has more cool particles, and I believe anyone can use them via my library.


#4

Just updated library:

  • Code refactored a little
  • Bug with radial emitter fixed
  • Support for .json format added
  • Support for .pex and .lap formats added

github - https://github.com/restorer/zame-haxe-particles


#5

Wow awesome library. Fact is that I used this library before moving to haxe/openfl. Now I can probably use it again thanks to you :slight_smile:


#6

Hi.

I’ve tried and this is good.

I’ve made a pull request for your project to add Stage3D support for flash fallback. Can you consider merging ?

Also, how do you handle z-ordering with other stuff ? For now, it seems that you can have your particles only in one layer or you have to create many Renderers. I think we should externalize the ENTER_FRAME, to store the particules in a map or something, and to render only one particule on demand (and not all the particules in one time). What do you think about this ?


#7

Thanks for PR, I already merged it.

Also, how do you handle z-ordering with other stuff ? For now, it seems
that you can have your particles only in one layer or you have to create
many Renderers.

Yes, if you need multiple layers, you should add multiple Renderers.

Initially there was only one ParticleEmitter class (ParticleEmitter = ParticleSystem + Renderer), but in my games I often need to render different particles on the same layer, so I separate it.

I think we should externalize the ENTER_FRAME, to store the particules
in a map or something, and to render only one particule on demand (and
not all the particules in one time).

Hmm… You want to have different z-index of each individual particle (not on particle system)? But it is 2D particle system :slight_smile: and all particles in particle system should be on one layer.

Correct me if I understood you wrongly.


#8

Thanks for the merge. That was fast :smile:

I’m not sure of what do you mean. Let’s say that you have a scene composed by a fire (particle) in background, a character and then an other fire (particle) in foreground. How do you achieve that in your current system? I think we should let the coder manage his z-ordering and decide when he wants to execture the drawTiles function.


#9

Let’s say that you have a scene composed by a fire (particle) in
background, a character and then an other fire (particle) in foreground.
How do you achieve that in your current system?

It’s easy:

class App extends Sprite {
    public function new() {
        var fireRenderer = DefaultParticleRenderer.createInstance();
        fireRenderer.addParticleSystem(ParticleLoader.load("fire.plist"));

        var heroSprite = SomeBitmapHelper.bitmapFromAsset("hero.png");

        var otherFireRenderer = DefaultParticleRenderer.createInstance();
        otherRenderer.addParticleSystem(ParticleLoader.load("fire-4.plist"));

        addChild(cast fireRenderer);
        addChild(heroSprite);
        addChild(cast otherFireRenderer);
    }
}

If addParticleSystem will return this instead of void to allow chaining, than it could be simplified:

var fireRenderer = DefaultParticleRenderer.createInstance().addParticleSystem(ParticleLoader.load("fire.plist"));

#10

Oh thanks. I didn’t notice that the Renderer inherited from Sprite :confused:

But regarding performance, it should be better to have a batching class and not to make individual drawing calls, right ?

So, here we have tiny little tilesheet making individual drawing calls. If we externalize the drawing call and allow using a bigger spritesheet, we could gain some improvement. It just a thought, I’m not sure of my theory, so correct me if I’m wrong.

Anyway, I think I will try to create a tilelayer renderer next days.


#11

Most time I use GL renderer along with standard openfl DOM renderer (which renders images / divs / canvases). In this case externalizing render method is possible, but will add additional complexity.

Indeed, if you targeting flash with Stage3D, you can do some optimizations, for example instead of having multiple Tilesheet’s for each texture use only one Tilesheet, externalize render method, etc…

I want to keep library as simple as possible, and it should work well on all targets, not only flash.

Probably we can make ParticleSystem more renderer-independent or even engine-independent (by removing BitmapData from it). In this case you can use ParticleSystem (which will take care of all math) with you own super optimized renderer, and not only on openfl, but on lime, show or luxeengine.


#12

Ok that makes sense! Thanks :slight_smile:


#13

Will I see blendmodes correctly if I am rendering to canvas?

And… is the project being updated?


#14

No, effects (blendmode or color transform) is not supported for -Dcanvas. Look at “Renderers comparison” in README.md for more information about renderers.

Yes, it actively maintained. Look at “Product support” in README.md for more information about project support.