Even in these days of broadband, download size is very important. I think the USA is on track for 65% broadband coverage in the next year or two. So there are a lot of modem users still out there. Even with broadband, file size can still put off people who are browsing and aren't necessarily hunting for your game.

When you look at the size of your game installer you usually find a very high proportion of that space is taken up by artwork. It's a rule of thumb, but most textures are often around 256×256 pixels, so they look nice and crisp at fairly high resolutions like 1024×768. Each pixel has an 8 bit red, green, blue and alpha component. We don't always need the alpha part, it is used by the hardware to control transparent portions of the image. So our example texture will take up 262,144 bytes on disk. MrRobot has about 300 textures currently, which is roughly 75MB. Using something like winzip we can get that down to about 15MB with no loss of quality, a 5 to 1 compression. Now instead of saving the images at full quality (using the tga format) we can use a lossy format like jpg. By saving the image out as a jpg you are pre-compressing it and the harder you do it the worse the image looks. As the compression system is vaguely similar to winzip anyway, then you haven't saved much as winzip wont be able to make a jpg much smaller if at all. The only benefit is you can set the compression level per image by hand, so some might be forced smaller without suffering loss of image quality. So you might get up to 6 to 1, but probably with some image quality issues.

An evolution of the jpg format that isn't widely used is j2k, which means jpeg2000. This system is far superior to jpg and can easily compress our source artwork at a 10 to 1 ratio, from 75MB to 7.5MB with little to no perceived loss of quality in most images. What I normally do is compress everything at 10:1 and then do a run through of all artwork at the end of the project lowering the compression on the 1-2% of images that are highly complex and suffer artifacts.

The power of j2k has a downside which is extremely slow encode and decode times due to the highly complex nature of the algorithms being used. Probably the oldest freely downloadable j2k library is jasper and the creator did a great service by releasing it. The only problem is, speed wasn't a priority in its development and it is very slow.

http://www.ece.uvic.ca/~mdadams/jasper/

Encoding time doesn't really matter, because we encode the images once when building the installer. It's decode time that is vital, the image must be decoded back into a flat 32bit image so the graphics card can load it. Or if you're very clever then one of DirectX's compressed formats like DXT3.

All is not lost. A new decoder codec saves the day by being about 40x faster than jasper and unlike all the other big companies making decoders it doesn't cost $10k :-)

I was also shocked by how easy it was to use compared to jasper, just a couple of lines of code and away it went.

http://www.j2k-codec.com/

The new codec is so fast we don't need to have a decompression on install application. Starscape used to install and then launch a small app that crunched through all the images and it took minutes on low spec hardware. The next version of Starscape will hopefully have a rewritten decompressor app that should just take seconds. I think it is worth keeping that post-install decompression app as Starscape is meant to run on very low spec hardware and has a huge amount of artwork. MrRobot being a fully 3d game, is far more efficient with regards to texture space and also needs a higher minimum spec machine to run. Therefore I'm probably going to leave the textures in their j2k format and decompress them on the fly when loaded. Initial tests showed this made the one-off game start load go from 9 sec to 13 sec which I think is fine. Further testing will be needed of course, but I think it's worth a slightly slower load to make the install process faster and simpler.