How to cleanup explosion particles after each explosion?

Particle Candy / Text Candy
#1

Hello,

I am not sure if this question make sense but here my problem. I am starting an emitter “explosion” every time an enemy is hit by a laser. So far so good. But recently looking at memory leaks in my game and I noticed that every time an explosion is started I can see that the memUsage is increased but never goes down even after the explosion is done?

I do a:

gunEmitter = nil
Particles.CleanUp()

when a switch screen or when it is game over. I am using director 1.2 and FX library.

I guess I am trying to figure if it is normal that memUsage is increasing at each explosion and never goes down. I am still using the simulator since I do not have a Mac yet.

I will appreciate any pointers.

Thank you.

Mo.

ps: LOVE Particle Candy! [import]uid: 49236 topic_id: 14147 reply_id: 314147[/import]

#2

oh By the way using this code for memory leak check:

  
local monitorMem = function()  
  
 collectgarbage("collect")  
 print( "\nMemUsage: " .. collectgarbage("count") )  
 local textMem = system.getInfo( "textureMemoryUsed" ) / 1000000  
 print( "TexMem: " .. textMem )  
  
 end  
  
 local memTimer = timer.performWithDelay(3000, monitorMem, -1)

And here the terminal view below: You will notice that the memUsage will go and up down as “rocks” are created and then destroyed by the gun. BUT when an explosion (PC) happens, the memUsage go up (which is normal since images are displayed on the screen) but when the explosion is done, the memUsage stays high?

If I knew how to detect the end of an PC effect (explosion) then maybe I could just cleanup those particles image. I would assumed that when an explosion effect is done during the game, that the particle would be removed in real time when their lifetime is over. Am I right on that?

I definitively need to resolve this issue of memory leaks before releasing since after a while the game slows very badly!

Thanks again for any help.

Mo.
----------------------- TERMINAL VIEW(better listing) -------------

new rock…

MemUsage: 371.037109375
TexMem: 2.754048

MemUsage: 371.802734375
TexMem: 2.754048

MemUsage: 370.216796875
TexMem: 2.754048

MemUsage: 371.447265625
TexMem: 2.754048

MemUsage: 370.599609375
TexMem: 2.754048
–> Particles.StartEmitter(): EMITTER ‘gunEmitter’ STARTED.
–> Particles.ClearParticles()

  • 0 bytes rock.png
    rock image deleted
  • 0 bytes Particle_Images/flare.png
  • 0 bytes Particle_Images/flare.png
  • 0 bytes Particle_Images/fireball_medium.png
  • 0 bytes Particle_Images/fireball_bright.png
  • 0 bytes Particle_Images/flare.png
  • 0 bytes Particle_Images/flare.png
  • 0 bytes Particle_Images/fireball_medium.png
  • 0 bytes Particle_Images/fireball_bright.png
  • 0 bytes Particle_Images/flare.png
  • 0 bytes Particle_Images/flare.png
  • 0 bytes Particle_Images/fireball_medium.png
  • 0 bytes Particle_Images/fireball_bright.png
  • 0 bytes Particle_Images/fireball_medium.png
  • 0 bytes Particle_Images/fireball_bright.png

MemUsage: 387.451171875
TexMem: 2.758144

  • 0 bytes Particle_Images/fireball_medium.png
  • 0 bytes Particle_Images/fireball_bright.png
  • 0 bytes Particle_Images/fireball_medium.png
  • 0 bytes Particle_Images/fireball_bright.png
  • 0 bytes Particle_Images/fireball_medium.png
  • 0 bytes Particle_Images/fireball_bright.png
  • 0 bytes Particle_Images/fireball_medium.png
  • 0 bytes Particle_Images/fireball_bright.png

MemUsage: 397.857421875
TexMem: 2.758144

  • 0 bytes rock.png
    new rock…
  • 0 bytes Particle_Images/smoke1_light_dark.png
  • 0 bytes Particle_Images/smoke1_light_dark.png
  • 0 bytes Particle_Images/smoke1_light_dark.png
  • 0 bytes Particle_Images/smoke1_light_dark.png
  • 0 bytes Particle_Images/smoke1_light_dark.png
  • 0 bytes Particle_Images/smoke1_light_dark.png
  • 0 bytes Particle_Images/smoke1_light_dark.png
    –> Particles.StopEmitter(): EMITTER ‘gunEmitter’ STOPPED.

MemUsage: 407.712890625
TexMem: 2.758144

MemUsage: 405.826171875
TexMem: 2.758144

MemUsage: 407.056640625
TexMem: 2.758144

MemUsage: 405.990234375
TexMem: 2.758144

MemUsage: 406.017578125
TexMem: 2.758144
–> Particles.Freeze() - PARTICLE SYSTEM FROZEN.
[import]uid: 49236 topic_id: 14147 reply_id: 52045[/import]

#3

Hello all.

I will assume that x-pressive guys are in vacation (which is fine!) Anybody here who uses Particle Candy having any issues with “memory leaks” after using an explosion effect? I am not sure I can call it a memory leak but once the effect is done, I can see (using the memUsage code above) that that number went up during the effect but did not come down after it was done. Worst yet the number (memUsage) still high after I come back to the main menu (using Director 1.2) Even so the terminal clearly show that PC is deleting emitters and particles.

I was thinking of using “stop emitter” command but not sure where to put it since I never know when the explosion is actually finish.

Any ideas guys?

Thanks.

Mo [import]uid: 49236 topic_id: 14147 reply_id: 52374[/import]

#4

GOT IT!!!

I found why I was getting the huge memory leak and it has nothing to do with Particle Candy I must add.

I used a text memory indicator MTM.LUA found in the code exchange. Unfortunately I should have read all the messages in that topic. MTM.lua is really made to monitor texture memory (graphics) rather than normal memory (as shown by memUsage). Anyway MTM.lua do not clear memory and it “look like” the regular memory goes up and up which look like a memory leak.

Once I commented out – require (“mtm.lua”) the memUseage went up and down with what happening in the screen but never went out of control. Best of all exiting the main game screen brought the memUseage to the start value. So no memory leak!

Here the link of the text memory monitor I am talking about. As some of the posts shows, this code is for texture memory only.

Anyway I hope someone here will be help by this finding. It really made me crazy since I was sure Particile Candy will not have such amount of leaks without anybody noticing.

Have fun!

Mo
Ps: by the way I love MTM.lua and works superbly for what it was designed for!
[import]uid: 49236 topic_id: 14147 reply_id: 52983[/import]

#5

Just read your post :). It’s not x-pressive guys fault or let say not entirely their fault. This is why next LUA version will have diffrent external library support. Particle and Text Candy modules create globals even if you try to specify local. To fix it have to be completely rewriten with this pattern:

http://blog.anscamobile.com/2011/09/a-better-approach-to-external-modules/

It’s faster and clean way to use Particle Candy and Text Candy. Made with few often used function of PC but Text Candy is way to big for may free time :slight_smile: [import]uid: 12704 topic_id: 14147 reply_id: 55320[/import]

#6

This should not have caused any problems so far, but to fit proper coding standards, the upcoming Particle Candy version 1.0.17 has been rewritten to get rid of LUAs module( ) function (it’s an internal change only, usage will stay exactly the same as before). [import]uid: 10504 topic_id: 14147 reply_id: 55456[/import]

#7

Hello,

Sorry for the delay. Thank you very much to both of you (gtatarkin and x-pressive.com) Yes I do not have any complains about PC. I actually LOVE IT. can’t wait about the new version not using modules as you suggested. Cannot wait to use the new tint feature once i am almost done with my game and buy a Corona subscription.

Keep up the great work.

Mo. [import]uid: 49236 topic_id: 14147 reply_id: 55785[/import]