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!
oh By the way using this code for memory leak check:
----------------
1
2
3
4
5
6
7
8
9
10
| 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) |
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
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!
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 :)
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).
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.
views:1648 update：2011/10/13 16:39:51