Ideas for the particle system

[Christian Nielebock]

Hi there,

first of all, the 4.0.0 release is awesome with very nice features!

Then I have some ideas for the particle system, because of my current development where I'm using them, there are some features which would be great:

• more than one image for one emitter (like this one in PhaserJS: https://phaser.io/examples/v2/particles/random-sprite)
• animated particles, for example handling such animations: https://de.pinterest.com/pin/323977766923934472/
• interesting would be also to animate the tile over the particle lifetime: 1st frame - particle start, last frame - particle end of life
• practical use are fire places for example
• precalculation of particle positions
• as a good example think of snow falling down. if you leave a house in a game the snow currently starts falling at the top of the screen.
  to make it more realistic, it would be nice to have most of the flakes already spread over the viewport

What do you think?
I've already looke into the particle code and I have some ideas how to handle multiple sprites. Maybe I find some time in the christmas holidays to try some things out for this case.

Best regards and keep up the good work,

Christian

[aaron.g...@gmail.com]

Hello :)

Personally I think those are all good ideas for example. For more than one image, i would recommend updating the emitter image property to be that of an array, and instead of accepting a raw image object, make it use instances of me.Sprite, or anything that's me.Renderable. The particle class can then update the selected sprite that it has in its update cycle, as well as call the draw function. This will allow usage of me.AnimationSheet

As for your snowfall example, I've ended up coding something entirely separate from the particle emitter to do it. Really if we want this to work, we essentially need a line & direction of which the partials can emit from, rather than a single point.

I did a snowfall in a couple games, but here's my more recent iteration of it: https://github.com/agmcleod/ld28/blob/master/js/scenes/father_scene.js to run it, and the sprite itself: https://github.com/agmcleod/ld28/blob/master/js/entities/snow_flake.js

On Thursday, December 1, 2016 at 6:20:15 AM UTC-5, Christian Nielebock wrote:
> Hi there,
>
>
> first of all, the 4.0.0 release is awesome with very nice features!
>
>
> Then I have some ideas for the particle system, because of my current development where I'm using them, there are some features which would be great:
>
>

> more than one image for one emitter (like this one in PhaserJS: https://phaser.io/examples/v2/particles/random-sprite)animated particles, for example handling such animations: https://de.pinterest.com/pin/323977766923934472/interesting would be also to animate the tile over the particle lifetime: 1st frame - particle start, last frame - particle end of lifepractical use are fire places for exampleprecalculation of particle positionsas a good example think of snow falling down. if you leave a house in a game the snow currently starts falling at the top of the screen.

[aaron.g...@gmail.com]

Ahh I can't type. I meant to say "those are all good ideas for expansion".

[Christian Nielebock]

No problem 😉.

I did a first, quick test where I'm not relying on me.Renderable or me.Sprite. I've just added an image with 8 frames and drawed the specific frame in the particle lifecycle (only for testing if it's looking good!).

This is a first (and very interesting) result: https://www.youtube.com/watch?v=TaVHBj7FdSw

This is the image which I used: 

What I have done:

• gave the emitter two additional properties: an array with frame numbers and the frame width (because I'm only using horizontal images here).
• set the animation frame in the particle itself (just recognized that my implementation is really wrong because it just increases the animation frame and goes from left to right ^^)

Currently it's not compliant with the rest of MelonJS and just done for testing purposes but what do you think?

Regards,

Christian

[aaron.g...@gmail.com]

That looks pretty good!

I would definitely recommend swapping to use me.Sprite as a concrete solution, or basically a sprite that sub classes me.Renderable. Can get benefits of using things like texture packer, object pooling more so, etc. Keeps the API we have a bit more consistent with the rest too.

Awesome work!

On Thursday, December 1, 2016 at 1:39:23 PM UTC-5, Christian Nielebock wrote:
> No problem 😉.
>
>
> I did a first, quick test where I'm not relying on me.Renderable or me.Sprite. I've just added an image with 8 frames and drawed the specific frame in the particle lifecycle (only for testing if it's looking good!).
> This is a first (and very interesting) result: https://www.youtube.com/watch?v=TaVHBj7FdSw
>
>
>

> This is the image which I used: 
>
> What I have done:

> gave the emitter two additional properties: an array with frame numbers and the frame width (because I'm only using horizontal images here).set the animation frame in the particle itself (just recognized that my implementation is really wrong because it just increases the animation frame and goes from left to right ^^)

[Christian Nielebock]

Am Donnerstag, 1. Dezember 2016 19:52:01 UTC+1 schrieb aaron.g...@gmail.com:

That looks pretty good!

I would definitely recommend swapping to use me.Sprite as a concrete solution, or basically a sprite that sub classes me.Renderable. Can get benefits of using things like texture packer, object pooling more so, etc. Keeps the API we have a bit more consistent with the rest too.

Sure, I will do this to benefit from the engines features and to comply with it. Here's end of day in Germany so I'll have a look the next days or on the weekend to finish this first steps 😀.

PS: With the right image sheet you can create awesome effects ^^: https://www.youtube.com/watch?v=Hp1IvhZh2wg 

[aaron.g...@gmail.com]

Of course, take your time, enjoy yourself working with it. Submit a PR whenever you're ready for feedback.

That does look pretty sweet. Makes my frame by frame firepit look kinda sad ;). https://raw.githubusercontent.com/agmcleod/snowballeffect/master/data/img/fire.png?token=AAG6exi08CBIGLy-xetkAlb-eKdFV4gvks5YSbm_wA%3D%3D The first 8 frames anyways. The last 4 are for when it gets put out.

[melonJS]

Hi Christian, nice hearing from you again!

We indeed did talk about using renderable instead of regular images, but we did not give it a try yet. My only concern though was on the performance side as using Sprite is much more consuming than just a regular image, so i think that any other alternative might be useful investigating as well. Maybe some in between solutions is the way to go ?

Happy to discuss them anyway :)

[melonJS]

see here as well :

https://github.com/melonjs/melonJS/issues/385

[Christian Nielebock]

Am Freitag, 2. Dezember 2016 11:12:29 UTC+1 schrieb melonJS:

Hi Christian, nice hearing from you again!

We indeed did talk about using renderable instead of regular images, but we did not give it a try yet. My only concern though was on the performance side as using Sprite is much more consuming than just a regular image, so i think that any other alternative might be useful investigating as well. Maybe some in between solutions is the way to go ?

Indeed these are things to be considered. I think, I'll try out different things and see how it proceeds.

Also thank you for the link! Interesting suggestions!

[aaron.g...@gmail.com]

Yeah that's a good concern to raise Olivier. I was thinking about it myself. Having a draw image call over an array of image objects is a fair bit lighter than our renderables. Given the dynamic nature of the language, one can support both. Just don't know if there would be any perf problems with using typeof or instanceof on the array of images/objects every frame.