I'm running into some memory problems when running my game on the ipad.
I've now profiled the game inside the simulator. there the memory problems will of course not occur.
one thing I noticed is that the used memory will always grow, but never decrease.
it's like this:
in the game menu: 30MB
inside a level: 200 MB
back in the game menu: 200MB
it's not a leak. after starting as this amount will not increase after starting the level again.
it'S just like the textures are not unloaded. so if I start different levels they will all contribute to the overall memory consumption, even though they might not be active.
is this intended?
if so is there a way to clear the currently unused textures?
I know that I have to do something against my memory consumption generally
currently I'm packaging all the textures of the animations into huge power-of-two textures. however I guess this will not be enough. I already though about extending orx with support of compressed textures.
and are you sure you delete the object in the game when switching to the game menu?
as far as I know, the textures are categoried by its filename and its deleting is based on the reference counter in the structure.
You can go through all the textures using the orxStructure_GetFirst/GetNext accessor and check their reference counter.
You should never try to delete something that you didn't explicitly create as its legal owner will probably call the delete itself at some point and you'll crash/assert.
You can also parse all the objects to see what graphic/texture they're using and verify you don't keep objects alive that you thought were destroyed.
As for compressed texture, it's something I'd like to add for iDevice plugins at some point but I never had the need so far as I've never used more than 14MB of video memory at once on those devices.
I modify orx lib code to print all deleting info, I found that one of bitmaps which is a role bodies' atlas picture won't be deleted.
in debug mode, there is a warning said that:
"Animset is locked, can't remove all anims."
the animset is locked therefore the pictures contain the anim textures. how to unlock it?
then I remove all animation. and test it again.
Still, the memory of the process in the system monitor won't go down, it seems that some resources still won't be removed from memory.
I am sure that I delete all config section since I get the sectionCount is 1
Thanks for your help.
in orxDisplay.m I changed the creation of the Image to as the other initializer will do some caching itself. which is unnecessary as orx will do some caching(or rather reuse textures) anyway.
that said it doesn't really change the behavior in a noticable way(memory wise). but as those problems are also present on the linux platform the cause obviously lies somewhere else.
I just ran the app again on the iPad and I get the same message that complains about locked animsets.
while game to menu no any difference in memory at most time
then go to game again, sometimes, it increase 0.2MB
the game scene it totally the same.
that's my complement of this issue.
or is it related to dlmalloc's running strategy?
dlmalloc lib request the memory but won't be released. then it remove them from system afterwards at some right time.
therefore memory shows in the monitor won't decrease.
I'm pretty sure we can rule out dlmalloc as being the source of the problem.
I didn't know for UIImage, thanks for pointing it out. Can you send me a diff of your changes?
If you feel more comfortable I can sign a NDA too.
I guess a release is need somewhere for the UIImage isn't it? I don't have access to a mac right now so I'd feel more comfortable with a diff so as to not break the plugin compiling.
I'm implementing compressed textures btw
it's already working, beside the resulting texture being flipped vertically
Welcome to the fabulous world of upside-down coordinates.
The most fun I had was when I was grabbing the screen content and was trying to reapply it via a shader as I would with a regular texture. I had to rewrite all coordinate-related parts in the display plugins at that time as I previously took the short path of using an upside-down viewport. Bad bad choice. ^^
lesson learned so far: compressed textures are awesome in regard to the memory consumption, but are pretty much useless for animations. the artifcats will cause some really irritating flickering. however they seem to be great for static images.
now I'm now considering to load my textures as GL_UNSIGNED_SHORT_4_4_4_4. couldn't tell any difference after converting some pictures and it would save me halve the memory.
Also, I did a blind try at fixing the animset issue. I haven't tried it at all but I believe in my lucky star. Let me know if it helped with your problem or not.
all bitmap have been removed.
but the memory still could not decrease
the similar problem also occur in windows.
at the beginning the size is 16Mb
after enter the game it increase to 19MB
then I switch the view again and again the size of memory almost remains at 19MB, every time it slightly increase 0.1.
Also, can you try not using dlmalloc in the orxMemory.c file and see what happens with the default memory allocator, just to be sure?
Those memory changes you notice (going up but stabilizing after a while) comes from the use of orxBANKs.
An orxBANK will allocate memory chunks when it's out of free slots and will never free them but will instead reuse the free slots when needed, becoming then very efficient as no memory allocation will actually take place.
I'll add a function to compact memory banks to your convenience that you can call between levels when you want to claim all the previously used memory. I could do it automatically but this "garbage collection" might impact performances at the wrong time, whereas if you call for the collection manualy that shouldn't be a problem. What do you think?
When simply having the basic particle spawner and the four walls, orx internally holds on ~361KB of allocated memory in ~300 distincts allocations. The total memory used, including orx and its external dependencies is ~40MB.
After spawning physical objects for about a minute (some sprite based, some text based) with a max of 500 physical objects at once, the memory peaks (and remains at):
- orx: ~700KB in ~360 distinct allocations
- total, including dependencies: 44MB
After collecting unused bank segments with orxBank_CompactAll(), we go down to:
- orx: ~361KB in ~300 distincts allocations
- total, including dependencies: still 44MB
I guess the next step will be to try to monitor what's so expensive in the dependencies.
The total video memory used for the textures, including power of two rounding if/when needed, is exactly 156KB + 128KB for the internal font.
We're still under 1MB in peak which means that the OS needs + external dependencies still account for over 40 MB (ie. 40 times more than what orx internally uses in this case).
External dependencies are: GLFW, Box2d, SOIL, OpenAL-soft, libsndfile, stb_vorbis. This test isn't using any audio resources so I expect the corresponding external dependencies to have pretty low memory consumption. My guess is that on alternative platforms/plugins, such as iDevices, results might be pretty different but I don't have the required hardware to try it right now.
the memory still remain no change.
Two reasons for that: dlmalloc won't give the memory back to the OS by itself unless someone calls dlmalloc_trim() and secondly and most importantly it's not orx that uses the most memory but the external dependencies. I unfortunately have no control on how they allocate/free their memory. Box2D is using a high watermark policy, which means it'll allocate more memory if needed but will never free it (as stated by its author, Erin Catto, on Box2D forum). I don't know for the other dependencies.
If you have any idea, please let me know.
but if the memory is going to be reused for other graphics it's totally fine with me.
What worries me is all the memory that is not directly allocated by orx. I'll try to see if I can modify the dependencies to hook their allocation back to orx so as to monitor them more closely.
Not sure when I can do that though...
attached you will find the first part. I don't you if it fits your style of code.
your code is always so clean etc, that don't want to change it and mess it up
anyway I added some part to check whether the right extension is present or not. then I check for the file ending, if it ends in PVR i will load the specific compressed texture. If compressed textures are not supported it will try to load texture that has the same file name but ends in PNG. For loading the texture I added the PVRTexture class that can be found in the sample project from apple. I just modified it slightly to support the orx smoothing.
I hope that my code is not too ugly and this helps somebody else as well.
I also wrote something about creating the compressed texture here:
Don't worry about the coding style, I can easily adapt it if need be.
I'll integrate this in the trunk either tonight or during the week end and it'll be part of the next release candidate.
PS: I read your wiki post about it but I think the first sentence is lacking a word or two.
I just wanted to give a heads-up that I will add support for PVR textures in ARGB_4444 format and also support for repeatable textures, if they are not compressed. I guess I can drop the mipmapping support, because it's not relevant for orx, anyway?
Sounds like a plan. I wanted to support different pixel format on computer as well but I wasn't sure how to do the interface part, especially for changing the texture values on the fly.
As for repeatable textures, how do you see that working, code and config wise?
And yes, mipmaps are not very relevant for 2D as you said.
I couldn't apply this patch as there's a version mismatch apparently: svn is trying to fetch a revision 278 (?) from the trunk before patching and if I use the latest from trunk it tells me the lines don't match. Would you mind sending me another patch for that?
I updated the pre-multiplied issue but I wrote the code directly (same version issue with the patch). I did it from windows so it might not work/compile on iPhone. If that's the case please let me know but I should be able to test myself on iPhone before the end of the week end!
I will do some more code cleanup and testing and then upload it to trunk directly if that's ok.
So if you don't mind I'd rather review the code before it gets there. I'm using a branch for new dev on the anim system myself.
If you send me a diff from made from the latest version on the trunk I should be able to merge it with no difficulties.
until when would you need them?
I would create them next week during the holidays, after adding some stuff and cleaning up a bit, if that's ok with you.