Cutting down app size
by Eyal Erez · in iTorque 2D · 10/19/2009 (6:30 pm) · 7 replies
So I'm trying to cut down another 1Mb from my already slimed app.
Here's what I did so far. maybe you guys can give me more ideas.
Images - compressed where possible
Audio - 8bit 11k ( I suppose I can go lower than 11k, but that's pretty bad as it is)
scripts - all .dso are deleted
Common - all the gui images and font data(utf) are deleted . as well as some scripts that I'm not using.
So now that I'm looking at my bundle I get:
Default.png 300Kb - any way to cut this down ?
TGBGame 5.6 Mb - it would be great to cut this down.
I already removed from my project most of the gui controls that I'm not using and the whole TGB folder.
What else have you guys removed from the project?
Here's what I did so far. maybe you guys can give me more ideas.
Images - compressed where possible
Audio - 8bit 11k ( I suppose I can go lower than 11k, but that's pretty bad as it is)
scripts - all .dso are deleted
Common - all the gui images and font data(utf) are deleted . as well as some scripts that I'm not using.
So now that I'm looking at my bundle I get:
Default.png 300Kb - any way to cut this down ?
TGBGame 5.6 Mb - it would be great to cut this down.
I already removed from my project most of the gui controls that I'm not using and the whole TGB folder.
What else have you guys removed from the project?
#2
Over 5MB actual binary inside the bundle?! I'm sure I've cut it down to 2.3MB without additional static libs. Play around with optimisation options and see what you can get, remove networking.
With OpenFeint, I can get a binary down to 3.7MB before fiddling with removal of unused parts. With OF handling its own networking parts, you can save another 30k by stripping out that (maybe more - it's not much, in perspective). The landscape and orientation modes each take a little shy of 1MB of space with NIBs and graphics.
The end result is an app bundle a little over 6 200 000 bytes on the simplest test game. Are you using external strip (a toggle in settings)? I've read that this might affect when and what is stripped. Also ensure dead code is stripped, in C++/linker settings.
10/19/2009 (7:21 pm)
There are some server-related scripts you can definitely remove for a single-player game.Over 5MB actual binary inside the bundle?! I'm sure I've cut it down to 2.3MB without additional static libs. Play around with optimisation options and see what you can get, remove networking.
With OpenFeint, I can get a binary down to 3.7MB before fiddling with removal of unused parts. With OF handling its own networking parts, you can save another 30k by stripping out that (maybe more - it's not much, in perspective). The landscape and orientation modes each take a little shy of 1MB of space with NIBs and graphics.
The end result is an app bundle a little over 6 200 000 bytes on the simplest test game. Are you using external strip (a toggle in settings)? I've read that this might affect when and what is stripped. Also ensure dead code is stripped, in C++/linker settings.
#3
Ronny, here's what I'm currently using. Do I need to check all of them?
Additional Strip Flags
Deployment PostProcessing
Strip Debug Symbols During Copy - check
Strip linked Product - check
Strip Style - All Symbols
Use Separate Strip
Dead Code Stripping - check
Don't Dead-Strip Inits and Terms
10/19/2009 (7:54 pm)
Sven, I just compressed my Default.png using pngOut and got almost a 100kb saving. not bad.Ronny, here's what I'm currently using. Do I need to check all of them?
Additional Strip Flags
Deployment PostProcessing
Strip Debug Symbols During Copy - check
Strip linked Product - check
Strip Style - All Symbols
Use Separate Strip
Dead Code Stripping - check
Don't Dead-Strip Inits and Terms
#4
But it makes sense to do this if your sitting around 40fps as in that case you might ad well be at 30fps and save 1MB off of your bundle :)
10/20/2009 (3:22 am)
If your game isn't too intensive or you have fps to spare (hehehe... yeah right!), you can enable Thumb Mode compiling for the build in XCode. That will use 16 bit operations instead of 32 bit ones (except for floating point operations), and will generally reduce your executable by plus/minus 30 percent. You'll more than likely take a performance drop (for our latest project, it was plus/minus 20 percent) unless you are somehow bound to memory bandwith / cache, which is unlikely in iTGB.But it makes sense to do this if your sitting around 40fps as in that case you might ad well be at 30fps and save 1MB off of your bundle :)
#5
The thumb switching option is possible, but the laws of programming say that expecting there to be no special circumstances (lower than usual framerate) will force special circumstances :)
Yes, pngout is king. I haven't found any other PNG optimiser as efficient. Saves oodles of space on webpages. When you can, use PVRs of course. If PVR works fine for certain images, you can try 2-bit PVRs and see what you get. I expect crap, but it can work for some buttons and other generally uniform surfaces.
Have you merged as many images as possible into spritesheets? Can you optimise the arrangement a little more? Fewer files mean less loading, and if two files become one the image compression can give you a smaller file than the sum of the previous two.
Too bad OpenAL can't read IMA4 compressed audio, or you could get a 75% saving on the space there. This is high on my wishlist (use OS functions to decompress IMA4, play with OpenAL from memory rather than file).
10/20/2009 (3:13 pm)
I've seen recommendations to use "Deployment Postprocessing" and "Use Separate Strip". The latter is because of the order some linking happens, meaning a strip that should happen doesn't in some cases, from what I understood. Postprocessing supposedly obfuscates and tidies up symbol names, but I haven't really seen it amount to anything :PThe thumb switching option is possible, but the laws of programming say that expecting there to be no special circumstances (lower than usual framerate) will force special circumstances :)
Yes, pngout is king. I haven't found any other PNG optimiser as efficient. Saves oodles of space on webpages. When you can, use PVRs of course. If PVR works fine for certain images, you can try 2-bit PVRs and see what you get. I expect crap, but it can work for some buttons and other generally uniform surfaces.
Have you merged as many images as possible into spritesheets? Can you optimise the arrangement a little more? Fewer files mean less loading, and if two files become one the image compression can give you a smaller file than the sum of the previous two.
Too bad OpenAL can't read IMA4 compressed audio, or you could get a 75% saving on the space there. This is high on my wishlist (use OS functions to decompress IMA4, play with OpenAL from memory rather than file).
#6
I've checked both "Deployment Postprocessing" and "Use Separate Strip" and the TGBGame executable in the bundle is now down to 3.2Mb from 5.6Mb
Whaoo. Pretty impressive!
Thanks a lot.
I'm good to go ;)
10/20/2009 (3:46 pm)
Ronny,I've checked both "Deployment Postprocessing" and "Use Separate Strip" and the TGBGame executable in the bundle is now down to 3.2Mb from 5.6Mb
Whaoo. Pretty impressive!
Thanks a lot.
I'm good to go ;)
#7
10/20/2009 (4:45 pm)
This is a great thread. I've been crunching down the size of Zombie Karts with hopes that I can double the number of tracks with its first update. I've done stuff like removed animation frames, removed underused / useless files, etc... hadn't thought to clip out the useless frameworks or optimize the PNGs... definitely looking at those tonight. :) 
Associate Sven Bergström
Luma Arcade
The dso's are normally marginally smaller than the cs equivalents.. This may help.
The default.png can be run out of SuperPNG or using the free pngOut tools to compress the PNG's much smaller.
The TGBGame, you mean the executable? How many libraries are you linking externally? Those add size to the executable...
What art assets are there , those can probably be made to be a lot faster/neater/usable/smaller? Using spritesheets, using PVR (this will help sometimes).
What all is in the bundle? There is also sounds that are in WAV which is big, this is always a problem and if you can cut down on sounds, and reuse sounds elsewhere i would start there.