Halfway through our development cycle we noticed that we had memory leaks in the game. The game would eventually crash because of it. I took charge of trying to detect the memory leaks. We tried to set up VisualLeakDetector, but it did not seem compatible with Marmalade, and we failed to accomplish that. I spent a good chunk of time researching ways to detect memory leaks in marmalade and in cocos2d-x, but most answers pointed to Memory Leak detection tools in XCode. Obviously, we don’t have access to XCode. So we did much more crude approaches – reference counting. We set up static variables in constructors of: CCSprites, b2Bodies, CGCObjects.
It turned out that not all CGCObjects were getting deleted. In the new framework, objects created via OGMO are not deleted anywhere. Unless they have an object group, that is. Objects get deleted in their respective object groups. But a lot of our objects did not have groups – why would the player have a group for example? There’s only one of them after all.
I emailed Alex about it for advice on how to proceed, took one of his suggestions and adapted it slightly: to have an object group that manages objects with no specific object group and delete them there. Furthermore, it turned out that such a group already existed and managed all of the objects – it just wasn’t deleting them. It was the CGCObjGroupDefault included in the framework. So I simply created a DestroyObjects() function for it and made it destroy everything there. That fixed it for the most part and the game wouldn’t blatantly crash anymore.
However, after 2 consecutive playthroughs of the game, it would start running incredibly slowly. We only discovered that a day before release and didn’t have time to fix it completely. However, at least the likelihood of it happening should be pretty low – it would be surprising for someone to play through the game twice in one sitting.
I still tried to make sense of what’s going on, and I mainly checked for memory leaks. I discovered these tools in Visual Studio to assist me:
Build->Run Code Analysis on Solution. It popped up with some warnings about memory initialisation before use, but no memory leaks. Apart from cocos2d-x’s CCArray class, but we don’t use that anyway. It helped us find a bug where we used a single-equals in an if-statement though, so useful stuff to know about.
Debug->Performance and Diagnostics. I ran memory diagnostics, but it wasn’t all that useful, as we couldn’t quite trace back the memory calls due to it running on the Marmalade simulator.
All in all, I would love to spend more time fixing the performance issues, but I don’t have an iPad for testing over Christmas break. I will try to do it on PC at least as much as I can. Further bugs are bound to pop up as well, as we had very limited time to play-test the game, and all of us had expert knowledge, which means that new players will play it completely differently and will discover bugs that we didn’t know about at all. While we are not aware of any game-breaking bugs, it would still be great to patch up the game as much as possible before release, and then continue to support it afterwards if it is at all successful.
Godsend Programming #12: Memory Leaks
Halfway through our development cycle we noticed that we had memory leaks in the game. The game would eventually crash because of it. I took charge of trying to detect the memory leaks. We tried to set up VisualLeakDetector, but it did not seem compatible with Marmalade, and we failed to accomplish that. I spent a good chunk of time researching ways to detect memory leaks in marmalade and in cocos2d-x, but most answers pointed to Memory Leak detection tools in XCode. Obviously, we don’t have access to XCode. So we did much more crude approaches – reference counting. We set up static variables in constructors of: CCSprites, b2Bodies, CGCObjects.
It turned out that not all CGCObjects were getting deleted. In the new framework, objects created via OGMO are not deleted anywhere. Unless they have an object group, that is. Objects get deleted in their respective object groups. But a lot of our objects did not have groups – why would the player have a group for example? There’s only one of them after all.
I emailed Alex about it for advice on how to proceed, took one of his suggestions and adapted it slightly: to have an object group that manages objects with no specific object group and delete them there. Furthermore, it turned out that such a group already existed and managed all of the objects – it just wasn’t deleting them. It was the CGCObjGroupDefault included in the framework. So I simply created a DestroyObjects() function for it and made it destroy everything there. That fixed it for the most part and the game wouldn’t blatantly crash anymore.
However, after 2 consecutive playthroughs of the game, it would start running incredibly slowly. We only discovered that a day before release and didn’t have time to fix it completely. However, at least the likelihood of it happening should be pretty low – it would be surprising for someone to play through the game twice in one sitting.
I still tried to make sense of what’s going on, and I mainly checked for memory leaks. I discovered these tools in Visual Studio to assist me:
All in all, I would love to spend more time fixing the performance issues, but I don’t have an iPad for testing over Christmas break. I will try to do it on PC at least as much as I can. Further bugs are bound to pop up as well, as we had very limited time to play-test the game, and all of us had expert knowledge, which means that new players will play it completely differently and will discover bugs that we didn’t know about at all. While we are not aware of any game-breaking bugs, it would still be great to patch up the game as much as possible before release, and then continue to support it afterwards if it is at all successful.
Related files
GCObjGroupDefault.h – https://drive.google.com/open?id=0B_BnvnFZLH7mZ3RjWmJtWjIzYmc
GCObjGroupDefault.cpp – https://drive.google.com/open?id=0B_BnvnFZLH7mc1dWLVotVGNDcTQ