First, I hope all my fellow U.S. residents had a safe and fun July 4 holiday!
I'm working on a problem where my game is getting slower as the player progresses. In-game framerate initially starts at about 41 (still working on improving that) but as the player wins levels, returns to the level select screen, and starts new levels, the framerate suffers more and more.
I've ruled out memory leaks in my code pretty well, I think. I used Visual Leak Detector in Visual Studio (0 leaks) and have disabled all non-Orx iOS-specific code in my project. The problem remains.
Here are some before (good) and after (bad) screenshots of the profiler:
http://imgur.com/a/Xi7br#qoPm1
So we can see the problem is in object/viewport rendering and probably is caused by the slowdown in the orxBank_Allocate and orxBank_Free calls?
I suspected my objects weren't getting deleted properly, but things look okay there. I call orxObject_DeleteAll (copied from Orx itself) whenever a "scene" ends.
Any ideas? Thanks!
Comments
iarwain, I'm still on SVN revision 2942 for iOS, since I am in a time crunch and didn't want to make the updates for the Orx orientation difference yet.
But I updated Windows SVN to 2964 and the behavior seems the same there.
Btw, as I've already been able to chat with acksys about my discoveries outside of the forum, I'll mainly add what I found here for other people who may encounter similar behaviors.
The problem is actually twofold. There's a memory leak (not completely leaked as we still have pointers to it but that ends up in a non-limited memory expansion) and a performance degradation happening. They are both somewhat related.
The memory growth was coming from an asymmetric orxConfig_PushSection()/orxConfig_PopSection configuration.
There are no visual feedback of this right now beside checking one's code or breaking inside orx internals (and check for the element counter of sstConfig.pstStackBank). I'll add some stat/info page similar to the profiler one at some point that will display some very important info about internals at runtime. Till then, your best bet is to break in your code and go back into orx's one to check things that look fishy.
The second issue was that event handlers were registered everytime a level was started but never unregistered. So after playing X levels, you have X handlers registered which means every event will be handled X times.
In this specific case it was the orxRENDER_EVENT_OBJECT_START that was the problem. There are ~120 objects rendered per frame, after playing 10 levels, that means we're handling 1200 events instead of 120 per frame.
The event handler in this case was calling orxConfig_PushSection() (and as it turned out, that was the asymmetric "leaking" one, which enhanced the slowdown/memory consumption rate problem).
orxConfig_PushSection() is calling orxBank_Allocate in its turn (for the internal section stack handling) and those are the ones that showed in acksys' screenshots, eating up processing resources.
By fixing both issues locally (ie symmetric orxConfig_PushSection/orxConfig_PopSection and symmetry orxEvent_AddHandler/orxEvent_RemoveHandler), everything look stable now after playing a few levels.
Let me know if there are other issues I would have missed!
As I mentioned to you in chat, I will try to add some notes on performance optim./troubleshooting on the wiki soon.
Thanks again for helping so quickly.