koobas.hobune.stream
Image size correlation between disk and memory
We've been working to reduce the memory footprint of our iOS game. We discovered the worst offenders were 3 2D images we were using as background textures. We've dealt with them by loading/unloading as necessary.
But we are puzzled at how the size of the graphic on disk correlates to the memory it takes in-game. For instance, for images 1, 2, and 3, the png sizes were ~900k, ~800k and ~170k, however during runtime they consumed, 8 mb, 8mb and 10mb. Since png's are compressed we decided to save them as BMPs to see if the uncompressed sizes correlated more closely, but they came out at around 2mb. Still far off from the 8-10mb sizes we were seeing.
I know we can use smaller images, texture compression, etc, to solve the issue, but we'd like to know a little more about what causes the images to consume so much more memory during runtime. Does anybody know anything about this? We are assuming the textures are completely uncompressed are runtime but wanted to know if there are any other factors.
Thanks, Geoff
Well, do you use mipmaps? this would effectively add 1/3 of the size. Are they stored as power-of-two? $$anonymous$$eep in $$anonymous$$d that the asset format you put into Unity is not the format used in a build. Check the build log file for more details. Just restart Unity (to clear the editor log), create a build of your game, open the console window (in unity) and press the "open editor log" button at the top right.
It usually gives you a quite detailed list of asset ordered by size. iOS also has a special image / texture format. I never developed for iOS yet, so i can't tell much about it ;)
I found an interesting Post on StackOverflow that really helped us figure out what's going on, StackOverflow.com
We also experimented around quite a bit with the various compression choices we had for iOS. PVRTC 4 bit for for RGB and RGBA worked very well for most items. The compression was good and the quality is much more acceptable than the more generic ones we tried. The PowerVR chip in iDevices is made to work with this format so it makes total sense. Though for things like Atlases for UI graphics and text, it did not work well at all. Luckily those weren't using all that much memory to start with. We ended up using either RGBA 32 bit in the iPhone Override tab or just falling back to True Color on the default tab for things that just didn't work well with any sort of compression (like Font atlases).
The long and short of it is, there's a lot more going on than meets the eye. Uncompressed, is really uncompressed when it comes to run time. Experiment with your compression options and see what works better for your particular case, texture, platform, etc. Texture Type: Advanced is your friend.
It still doesn't explain the huge difference. As you said your uncompressed 24 bit images (bmp) are just 2 $$anonymous$$B.
Anyway i'm glad you fould at least a solution ;)
