Should I just scale small images to other form factors in a cocos2d game?

Question

I have a universal iOS game built with cocos2d-iphone that has a large number of small images (amongst others). For these small images, the game works fine with a 1:2:4 ratio for iphone:ipad/iphone-retina:ipad-retina. I have two approaches to enable this in the game:

A) Have three sets of sprites/spritesheets - for the three form factors required and name them appropriately and have the images picked up

B) Have one set of highest resolution images that are then scaled depending on the device and its resolution aSprite.scale=[self getScaleAccordingToDevice];

Option A has the advantage of lesser runtime overhead at the cost of high on disk footprint (an important consideration, as the app is currently ~94 MB). Option B has the advantage of a smaller on disk footprint, but the cost is that ipad retina images will be loaded in memory even for the iphone 3gs (lowest supported device).

Can someone provide arguments that will help me decide one way or the other?

Thanks

Answer 1

There is no argument: use option A.

Option B is absolutely out of the question because you would be loading images that may be 6-8 times larger in memory (as a texture) on a device (3GS) that has a quarter of the memory of an iPad 3 or 4 (256 MB vs 1 GB). Not to mention the additional processing power needed to render a scaled down version of such a large image. There's a good chance it won't work at all due to running out of memory and running too slowly (have you tried?).

Next, it stands to reason that at 95 MB you might still not get your app below 50 MB with option B. The large Retina textures make up two thirds or three quarters of your bundle size , the SD textures don't weigh in much. This is the only app bundle size target you should ever consider because below 50 MB users can download your app over the air, at over 50 MB they'll have to sync via Wifi or connected to a computer. If you can't get below 50 MB, it really doesn't matter if your bundle size is 55 MB or 155 MB.

Finally there are better options to decrease bundle size. Read my article and especially the second part.

If your images are PNG the first thing you should try is to convert them all to .pvr.ccz and as NPOT texture atlases (easiest way to do that: TexturePacker). You may be able to cut down bundle size by as much as 30-50% without losing image quality. And if you can afford to lose some image quality there are even greater savings possible (plus additional loading and performance improvements).

Answer 2

Well, at 94Mb, your app is already way beyond the download limit for phone network, ie it will only ever be downloaded when some internet connection is available. So ... is it really an issue? The other big factor you need to consider is memory footprint when running. If you run 4x on a 3G and scale down, the memory requirement will still be for the full size sprite (ie 16x the amount of memory :). So the other question you have to ask yourself is whether that game is likely to 'run' with a high memory foot print on older devices. Also, the load time for the textures could be enough to affect the usability of your app on older devices. You need to measure these things and decide based on some hard data (unfortunately).

The first test you need to do is to see whether your 'scaled down' sprites will look ok on standard resolution iphones. Scaling down sometimes falls short of expectations when rendered. If your graphic designer turns option B down, you dont have a decision. He/she has the onus of providing all 3 formats. After that, if option B is still an option, I would start with option B, and measure on 3GS (small scale project, not the complete implementation). If all is well, you are done.

ps : for app size, consider using .pvr.ccz formats ( I use texture packer). Smaller textures and much faster load time (because of the pvr format). The load time improvement may be smaller on 3GS because of generally slower processor - need to un compress.