How do you maintain content size vs. content quality in a mobile application?

Question

I am developing my first Cocos2d iPhone/iPad game that includes quite a few sprites, I would need approximately 80 different. As this is for both normal and HD displays I have 2x of each sprite. I am using TexturePacker to optimize the thing.

I would like to ask if there are any rules-of-thumb, tricks, ideas etc. to adjust to in regards to size of content, quality and how you maintain high-quality HD-based graphics due to its size vs. the device memory sizes?

Also, is it a good idea to only have one copy of the sprites and scale it using code?

Answer 1

There are multiple ways to save space on textures These are ones I have seen and used (with internal dev tools):

You can reduce the colorspace of some of your textures, you don't need 32bit for everything.

You can use very modest palettes for most (very) small textures. You can even share those palettes across textures.

You can use color-keys for some textures which are reused for different teams but with different colors. This way you don't end-up with 4 versions of the same texture.

You can remove alpha from textures which don't need it and use a given color as background.

Monochromatic textures can be given a color at runtime and they only use 1 bit per pixel without alpha. Otherwise you only need to store the alpha value. (fonts for example).

You can also take all your textures and compress them into one file (this can be advantageous over compressing each file separately).

You can reuse some textures across resolutions/screen sizes.

As to using only the highest resolution files and scaling them on the client this can work but you should make sure it all scales down well. If some scaled textures don't look good you can add the lower resolution version only for those in your app.

To speedup the loading time during scaling/uncompressing you could create a cache on first launch with the desired scales/colors/alphas on the device and load those subsequently to avoid expensive loading/processing between scenes/levels... This can save you if use many optimization techniques and you have a lot of loading/unloading to do. But don't rely on having the necessary disk space every time.

Answer 2

If you have a lot of sprites it could certainly be an option to scale down high-res assets on devices with lower resolutions. These devices also usually have a lower maximum texture size, so you can't just use the high-res assets as textures.

To go about this you could use the Quartz 2D API (basically create a bitmap-context and draw your image with the desired size using CGContextDrawImage). Then you can use the CGImageRef you get and add it to the CCTextureCache as there's already a built-in function for this. Once you done this, you have the CCTexture2D ready and you can use it for sprites etc.

Loading the data from pre-rendered files is going to be faster though. If you have lots of sprites, it might have a significant impact on the loading time of your game, so you'll have to try if it's worth trading loading-time for application-size.

I'd say if you can fit the application into the new 50 MB limit (download limit for cellular networks) with the above trick, then do it. If your application will get larger anyway, I think it isn't worth the effort.

Another thing you might want to check out first is a PNG optimizer like ImageOptim. There's even a small guide for iOS optimization and what you'll have to change in XCode too. I updated an app for iPad 3 and managed to have both low- and highres assets in there without increasing the app-size compared to the previous low-res version (although I only had very few assets and also ones that can be compressed very well without losing quality).

Answer 3

I'm not familiar with iOS specifically. For my Android game, I tried the "make big images and sample it down" thing people usually say. It looked quite odd.

For my current iOS/Android game, I'm using vector images instead; I create them in Flash (CS3), then rasterize them in-game depending on the size of the size of the device's display surface. It works quite well, but you need to rethink how you lay things out.

An alternative method I tried in the past is keeping multiple sets of assets, and dynamically picking the right set at compile time -- so making an HD build and a non-HD build.

You can try all three methods and see what works best for you. It's not just about graphics, it's about sustainably maintaining your workflow with your tool chain.