Jump to content

Repeat calls to emitter.makeParticles killed Safari on iPad.


Recommended Posts

I was implementing some simple fireworks using emitters that looked pretty, but after a couple of minutes on the iPad,

they killed the browser.


Psudeo code is:

Firework Constructor:

 - Create sprite for positioning, and to be the visible projectile.

 - Create primary emitter for particle trail and primary explosion.

 - Create secondary emitter for multicolour explosions.

 - Call makeParticles on both emitters with a random (out of 4) particle sprite.


Firework Update function:

 - Decrement life timer.

 - Set emitters position to match projectile sprite position.

 - When time is up, call begin.

 - If already started, call boom instead.


Firework Begin function:

 - Reset all positions.

 - Revive projectile sprite.

 - Set velocity on the projectile sprite to shoot it up the screen.

 - Call makeParticles on the secondary emitter with a random particle sprite to change up the explosion colours.

 - Start emitter 1 to leave a particle trail up the screen.


Firework Boom function:

 - Kill projectile sprite

 - Call start on primary emitter, set to explode.

 - 50% chance to call start on secondary emitter, set to explode.



This created a really nice visual effect, but after a couple of minutes of running on the iPad, it caused Safari to close.

I altered the code to only call makeParticles on the secondary emitter once at the creation of the firework object and now it runs fine without killing the browser.


So, lesson for today is to not call makeParticles on an emitter (or 4) every few seconds. It is probably better to have a bunch of secondary emitters from the start, and pick one to explode at random.

Link to comment
Share on other sites

That doesn't totally surprise me. You basically exhausted the available memory Safari had. Emitter.makeParticles will literally create a whole bunch of new Sprites and add them to the Group (Emitter extends Group). What would be better would be to recycle particles already in the group and re-use them, as although they are killed they still persist in memory. If you find there aren't the functions you need in Emitter to make this happen then let me know and I'll see what I can do.

Link to comment
Share on other sites

Actually thinking about it - Flixel had a system in place whereby a Group would have a fixed size. So you'd set it to say 100. Then whenever the Group was asked to create a new Sprite it would scan itself for any 'nulled' object and use that instead. If it couldn't find one it would then either grow the size of the Group or abort. Sort of like a self recycling feature. Might be useful to add that back in perhaps (although it does add to the time it takes a Group to create something, as it has to scan all children first, each time)

Link to comment
Share on other sites

I have had to move on from the pretty explosions due to time constraints in the current project, but would it be as "simple" as changing the way MakeParticles works to loop through existing child sprites and updating the properties/texture until it runs out, then making new ones as needed?

Link to comment
Share on other sites

Hmm sort of - makeParticles isn't what should be used though, that should be a 1-hit thing on instantiation only. You need something much more specific I reckon. Don't forget Emitter extends Group, so anything a Group can do, an Emitter can do. This includes forEach'ing over any alive/dead particle, setAll, callAll, countDead, etc. So if an emitter was finished (countLiving=0) then you could callAll on it to change the sprite texture or whatever, and then just call 'start' again.

Link to comment
Share on other sites

  • 1 year later...

  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...