I’m testing my game in XCode sim. The memory keeps going up as the game is played. Not really sure how to delete stuff, I’ve read that the engine garbage collects on its own terms. But I was hoping that, by replacing the scene with cc.director.runScene(), that the memory would reset, but that doesn’t seem to be working. I tried saving a reference to the old scene, and manually setting it to null, but the memory still isn’t affected. How do I manage memory specifically in the cocos-js engine? Even if there are leaks or whatever, I was hoping to have some kind of reset when I change scenes… I’ve tried retain/release, removeAllChildren, setting elements within the scene to null, and nothing seems to work for me. Thanks in advance!
Have you checked if the textures and similar resources are still loaded into memory?
You can clear out unused textures with this command in C++, and I assume that should be an interface method in JS for it:
Director::getInstance()->getTextureCache()->removeUnusedTextures();
This is what you would call to figure out what textures are loaded into memory (again in C++):
const auto cacheInfo = Director::getInstance()->getTextureCache()->getCachedTextureInfo();
CCLOG("%s", cacheInfo.c_str());
Thanks for your quick response! Having trouble because the Director seems structured very differently in JS with different functions. (cc.Director | JsDoc Reference) But looking for equivalent methods as the ones you listed, I found “cc.director.purgeCachedData()”, and that’s allowed me to cut down on the memory I’m using when I change scenes! Please let me know if you are aware of other methods I can call to save memory or detect what kinds of elements are persisting. There is a purgeDirector() function listed but cocos doesn’t recognize it when I call it. Purging the cached data (which includes the textures) seems to solve the problem basically though, thank you for giving me a direction to go in.
That must be an older version of Cocos2d-x, so the API would be slightly different.
Is there something wrong with the code and documentation? They’re all in there. In addition to that, there are very specific places where large amounts of memory would be used, like the texture cache, so you can quickly look at the code at how the textures are stored, and then just as quickly find the functions that manipulate those stores.