CRABBY Vs. ICEBREAKER

I grabbed a copy of Icebreaker the other day. Great game really. But when I opened up the APK to take a look at some of their artwork in higher detail, I found the game’s asset sizes were larger than they should be.

I’ve always been a fan of the artistic style and design quality of Nitrome games. Like most of their content, there’s lots of hand-optimized transparent sprites that are used. But I was appalled when I saw that that 20% of their asset footprint came from 32bpp PNG files. (sound took another 11% was taken by sound files, but that’s a separate article)

As you may have known, I’ve been on a tirade lately about the problems of texture compression in Android apps. Seeing such a great app with obvious texture bloat problems was troubling to me.

In March 2013, I released Crabby, an extended texture compression format meant to replace the use of simple PNG for sprite-based texture games. So I decided to run some of the assets from Icebreaker through Crabby to see what wins could be had. Here’s a small sampling of the results:

	srcfile.png	crabby.zip	srcfile.gpu	crabby.gpu
mapscreen-2cavern.png	163 k	114 k	4 mb	877 k
active.png	121 k	221 k	4 mb	1.38 k
android_levelcomplete.png	80 k	58 k	4 mb	519 k
bg_0_layer2.png	28.3 k	46 k	1.6 mb	394 k

The first 3 images in this list are sprite-sheets (the final is just a big, unique background image). I’ve noted before that passing a simple sprite-sheet to crabby does not result in savings. This is because that most chart atlases have been rotated or translated to be offset in the atlas for packing. The result is that the 4x4 block matching mode in Crabby doesn’t end up finding as many duplicate 4x4 blocks. As such, I wrote a quick tool to break apart the atlases, which is loosely based on a flood-fill algorithm. The end result is loose, boundary-optimized, PNG files, which help remove the 4x4 block alignment issue (I haven’t found a way to fix the rotation issue yet though, so there is some bloat in my numbers..)

As far as distribution is concerned, you can see that simplistic PNG files will often give wins when it comes the APK size by itself. This is roughly to be expected; We haven’t done significant lossless compression of the on-disk format, so it makes sense that the optimized Deflate algorithm would win on that part.

However, it’s clear that once you’re loading these textures into the GPU, it’s no contest. The raw sprite atlases are 4MB a piece, while the crabby footprint never gets above 900k. This is night-and-day difference. anywhere between 78% savings and 99% savings on the GPU. For lower-powered devices, or just looking at how much content you can cram into a level, this is a large savings.

Although Crabby is far from being a completed project, tests like these help solidify the need for such a library out there for mobile game devs. It’s hard enough to get someone to find your game, and decide to install it. They shouldn’t be turned off by the size of the package, or restrictions on GPU sizes.

Disclaimer As with any comparisons, there’s some wiggle room in the numbers.

Firstly, my atlas-breaker algorithm will do it’s best to cut cut up the image into discrete chunks, but there are cases where it isolates sections of a sprite (for example, a small explosion frame) that may not be connected using a flood fill, and will extract them out into their own images.

Secondly, the Crabby mode I ran this through did not require Power-of-Two textures. You can check out the decoding examples I’ve provided to see that this mode is often available on modern mobile hardware. So some of my numbers will naturally be lower due to the removal of this requirement, since the source assets are all POW2 aligned.

Thirdly, Icebreaker is entirely owned by Nitrome. I have no right to the images, trademarks, distribution, or identification of any content involved with it. Also, this analysis is entirely a personal process, it’s not nothing to do with any employer, organization, or secret society that I may (or may not) be involved with.

~Main

You can find Colt McAnlis here: