I’m just about finished my project but I’m still having a really hard time tracking down a device crash that I believe is memory related. It happens if you play the game from the beginning and just work your way through. Eventually it starts to slow and the device will crash - not always in the same place and not always with the same error, and restarting the game seems to be a fine solution but obviously not ideal for players.
I’m also not totally clear on how to use the malloc log – I can see the heap size increasing but nothing else displays in the window. I suspect there is just too much being kept in memory as the game creates new rooms while the player explores the world. I’d love some help tracking this down and coming up with a solution.
Not a silver bullet, but did you try Lazy Load-ing your assets?
Hey Diego! Sorry I’ve been distracted with bugs and stuff and also unable to remember anything that happened more than a day or two ago… I’ll give the game a run this evening and see what I can find. If it’s a memory leak that should stand out pretty quickly. The other possibility that comes to mind is memory fragmentation, and that’s much trickier…
I’ll let you know what I find!
Cool, thanks! I’m not positive that lazy load would address what’s going on here, but maybe? Though I might want some input on how best to implement in the case of my behemoth of a tiny game.
On the fragmentation subject, I added the fps counter to the sprite game sample from the C_API examples folder and let it run. In about an hour it goes from 20fps to 8. There’s no leaks I can see in the code, but certainly a lot of allocations and deallocations.
Elsewhere folks have recommended pre-allocating everything to avoid fragmentation, which makes sense to me, but I can’t see how to do that with the sprite collision system.
Something I found on Friday that appears to help with the fragmentation problem is increasing the minimum allocatable size so that the free list doesn’t fill up with tiny unusable blocks. We were looking at performance problems with frameTimer.lua, and I found that at the default minimum allocation size of 4 bytes, a 4-byte block would be added to the free list every time I created a new frameTimer–after 1000 iterations, the system has to walk through the list of 1000 4-byte blocks before it can allocate the size it needs. When I bumped that up to 32 bytes the list didn’t fill up at all, since the larger blocks are more “recyclable”. I’ll do some profiling, see if there’s anything to be gained by increasing that further.