Hoping someone can help me with this issue. I’m submitting my game to the Pax East Indie Showcase today and it’s ready except for one critical issue. When I export the game to the Xcode Runtime and make a release it runs okay but slowly bogs down (over like 3 to 5 minutes) and then crashes. Feels like a memory leak or something… but in Codea my game has no problem at all.
Makes me think the Runtime has an issue - am I right to think that? Anything I can do to improve the performance / fix the issue?
I was told recently the Codea Runtime has some issues with iOS 7 still, is that the issue? The only other thing I can think of in my app is the use of one mesh.
Mark - good idea, but I only print out once at the beginning (though it is a bit large - I’ll try getting rid of it).
Zoyt - how can I capture the crash from the device? (the game runs way too slowly on the simulator - never waited long enough to see it happen there). I’ll see if that happens on the simulator too.
New info: I’ve been watching the memory report and it gobbles up 2 MB of memory every second constantly. I walked around the application and it only happens on pages that use the physics engine (even if there are no objects) - any ideas?
I was going to say, 20 MB is a bit crazy. It’s kind of hard to find an issue with your eyes blindfolded, so there’s not much I can do, sadly. Not to mention there’s not much you can do if it’s a Codea runtime issue. Can you tell me what technologies you’re using (meshes, shaders, etc.)
@Neztec have you tried using the Memory diagnostic tools in Instruments within Xcode? Build and deploy it to the target device (instead of the Simulator) and track its progress in Instruments. it might give you some extra clues while its running ‘live’.
The other thing I would look for right away is creation of any substatial objects within the draw() routine, particularly tables. Creating tables or complex objects inside of draw stands a good chance of outrunning the garbage collector’s ability to squash them unless you take active measures.
I’d also say check for recursive method calls in objects, but that usually eats the memory so quickly it leaves little doubt about the cause.
Oh, and one more: what are you doing about saving data? If you’re updating local data frequently with current status that can also turn into a problem .
Zoyt - no shades, one mesh that only appears when a user makes an active move (probably not involved in this issue). I use clipping a decent amount of the time. Lots and lots of images. Some tinting occasionally. Uh, I draw ellipses some of the time (which I know is expensive). Thanks.
Andy - I haven’t tried that yet, but I will next! Thanks.
Mark - Oh my, yes I do lots of creation in the draw method. In other words I don’t do much in the setup method. But usually it’s I build a level, etc, and then I’m done with creation for a long while until. In the memory consumption I’m seeing the app is just sitting idle - almost no creation happening at all. Still, I’m tempted to throw down some manual garbage collection now - when is the best time to do so? Post drawing?
Creating tables or complex objects inside of draw stands a good chance of outrunning the garbage collector’s ability to squash them unless you take active measures.
I would guess its not destroying tables properly too and most likely inside the draw function.
During testing I was having a crash after a few levels and I relized my table would have times added but never removed.
I started using a technique like this to resolve it:
bs = {} -- temp table
mybullets = 0
for a,b in pairs(bullets) do
if b.age < b.lifespan then
mybullets = mybullets + 1
table.insert(bs,b)
end
end
bullets = bs -- replace bullets table
bs = {} -- make sure you destroy it.
To an advanced Lua program I am sure this is just the way you do it…
but really I would need to look at your code to help. as would anyone. we are all guessing what it could be… and without looking we don’t really know.
I would guess its not the engine but an oversight in programming.
@SkyTheCoder - the physics “engine” is always running, it’s just a matter of whether you have objects in it or not. Well I guess you could physics.pause() - but I’m not doing that… I wonder if that would help?
I’ve been trying to isolate the exact drain. When I comment out my drawing code the memory drain slows to a crawl, which is interesting. One block that was hurting it a lot was when I created a bunch of local variables to set things up neatly in a draw method - surprisingly that was hurting it more than helping. When I refactored them away there was less memory drain (though some still).
