AtlasSprite/Sprite - memory usage differences

cocos2d for iPhone » Programming » cocos2d support (graphics engine)

AtlasSprite/Sprite - memory usage differences

(8 posts) (3 voices)

Started 2 years ago by shw
Latest reply from shw

Tags:

shw
Member

As I wrote in other topic - I decided to rewrite some part of application to use AtlasSprites instead of Sprites and AtlasAnimations instead of Animations. It forced me to change some parts of my theme system which I also made a little more universal to use. I've also added reactions for the device rotation.
After making those changes I decided to check if there aren't any leaks. Fortunately - no leaks was found but I found something else. After running the app before all of those changes the ObjectAlloc was showing about 9.5mb of memory usage. Now it's showing a bit over 13mb.

Is larger memory usage normal when using AtlasSprites compared to Sprites or should I look for the cause somewhere else?

The texture files after changes are a little bit bigger than individual files was before, because it's almost always some empty space in the grid (like there's a grid 4x3 and only 10 textures in it == 2 empty spaces) but I don't think that's the only cause of such large increase.

Posted 2 years ago #
Steve Oldmeadow
Administrator

We can't say anything about the memory usage without knowing the facts - most importantly the dimension of your images.

The key to understanding memory usage is knowing that images will be stored in a texture with power of two dimensions. So if you have a sprite with a 32x32 image then it is stored in a 32x32 texture so no texture memory is wasted. If you had a sprite with a 33x33 image then it is stored in a 64x64 texture so a huge amount of texture memory is wasted.

If we then take those sprite images and put them into a sprite sheet then it is likely that the 32x32 images will use more memory when put into a spritesheet but the 33x33 will use less. Again it depends on how many images you have and how optimally they are packed. If all your sprites pack into a 320x320 spritesheet that is going to be stored in a 512x512 texture so a huge amount of texture memory is wasted.

Ultimately the reason we want to pack the sprites into one texture is for performance, not memory. It is quite common to trade memory use for performance.

Posted 2 years ago #
shw
Member

I wasn't aware that bigger images are packed to 512x512. Than the increase might be caused by the images since now 1/3 of textures has some dimension over 256px therefore are loaded as 512x512 textures.

Posted 2 years ago #
Steve Oldmeadow
Administrator

It won't necessarily be 512x512 - it is just the next power of two dimension. So a 257x128 will be stored in 512x128. The worst case is a square image with dimensions 1 pixel greater than a power of two. For example 513x513, will be stored in 1024x1024 and nearly three quarters of the texture memory will be wasted.

Posted 2 years ago #
shw
Member

I've decided to make sure what was the cause - it's no longer just for me - just thought that maybe it would be useful for someone else which would like to decide which sprite to choose.

I've made some calculations comparing old images and it's texture sizes (plus the quantity of course) and the new, merged images. It seems that the memory increase is caused by using merged textures - the texture needed to load images did increase by about 1.4 which correlates with memory increase from about 9 MB to 13 MB (also 1.4 increase). Now I load 10 textures instead of 40 and theme files are much easier to create and work with so I think that AltasSprites were a good choice. Especially that it took very little time to rewrite the code which was creating sprites.
But of course it's just my opinion and it works only for my app - it might not work for some other app but I hope my example will help others to make more informative decision.

Oh - and I've also made few hypothetical calculations - with min height, min weight, if images would be merged near each other instead of 128x128 slots like ImageMagick does by default (still looking in the manual how to do it) - and in theory - with the theme I'm testing the system and app on - it would be the most efficient to make the merged images in one row (the min height scenario) and it would be even a little bit more efficient (when it comes to memory usage of course) than loading those 40 images using normal Sprites. But I think it's mostly because those images are usually higher than wider.
So it's wise to make those kind of calculations before choosing the way how the images for textures would be packed.

Posted 2 years ago #
shw
Member

I finally wrote a shell script that makes calculations and finds the best way to fit few images into one atlas texture. Few modifications in code for creating atlassprites and loading texture and animation and I've got improvement in memory used from 23% by choosing the best grid to 33% by also changing few switches in ImageMagick so it packs images closes together.
I don't know how usefull it would be for other people but I probably tweak it a little, make it a bit more user-friendly and publish it - maybe it will help someone :)

Posted 2 years ago #
JeDi
Member

In the new cocos2d alpha, you can easily use the Zwoptex texture packing tool (http://zwoptex.zwopple.com/) to create your sprite sheets. In our case, going from our naive packing to using the tool, we decreased memory by almost half!

So make sure you check out that tool. It will probably save you some more texture memory.

Posted 2 years ago #
shw
Member

those images which I use as atlassprites are actually states of controls and are loaded as themes of those controls. I used this tool now and it looks like I actually make some similar thing with my theme file to zwoptex - I also store things like file path, height, width etc. in a plist file - one for each theme. unfortunately zwoptex wouldn't be as useful since I use some other attributes (like scale etc.) which aren't available in zwoptex plist files. but thanks for the link.

I'm happy with my 33% decrease - actually I'm a bit lower with memory usage than in my original design and the process of creating textures and making sure they will result in the smallest possible texture size is in a way very automatic and I don't have to worry about making those calculations, placing images on some GUI in the correct order and position. I export separate files, execute my script in the terminal and it does all the tough work for me :)

Maybe in some next project where I will just need my textures to be packed the more efficient and nothing else.

Posted 2 years ago #

RSS feed for this topic

Reply

You must log in to post.