I was dead happy with PNG format for a while. It was open, efficient, fully-featured, and available everywhere, and it turned out that it's also available in Java.
The love affair is over!
Here's why you don't need PNGs for little games. Or even big ones:
1. To load a PNG from Java typically you'll be needing the AWT, and the ImageIO framework. This is a great big old bloater of an API designed to decode the kitchen sink if necessary. As usual, it is about 100x as complicated as you need to deploy your game. If, like me, you're going to rely on native compilation that requires no JDK to be present, you're pretty much stuffed because of the licensing agreement. This will mean you have to use another PNG library anyway - and that will almost certainly plug in to the AWT anyway.
2. 90% of what is actually in
the PNG file format has no relevance to you at all.
PNG is a generic solution for storing graphics. You don't
hava a generic problem. You've got a very specific problem: you're writing a game
and that game has to be delivered on the Internet in demo form
. My views on Internet delivery are unorthodox because they are not the views of a tech-savvy nerb
but instead the views of a businessman who understands internet delivery
. So all you nerds with cable modems / infinite patience out there - can it, I don't want to hear it. If your demo is over 5Mb very few people with bother to download it
and you can take this as gospel for the foreseeable future.
So now that's all clear, what do I suggest you do about it? Well, at the risk of plugging the SPGL, I suggest you use your own image format
Here are the advantages of using your own format. Or more specifically, my Image format:
1. It relies on... 1 class! That's right; the whole Image thing is only one class, and the amount of code in that class is tiny. It deals with loading and saving images and getting direct access to the image data - and that's all it does. So not only is it tiny
it's also much faster than using AWT
. Data is loaded directly into a Buffer - so it can go straight to OpenGL.
2. The compression is vastly superior to PNG format
. I was actually quite gobsmacked. Because we know that game sprites have certain properties which are different from generic images we can do a few special optimisations to the image compression. In my case, I split the image into its planes, so that each R, G, B, and A plane comes after the next instead of all packed as RGBA integers. Then for each line of the image I am recording just the delta
of one colour to the next. This leads to an awful lot of very small integers, like 1, 0, and -1, in longer runs, which compress very well using gzip.
So as I mentioned in the diary: 4Mb of graphics suddenly has become 2Mb of graphics
. This is good because A.F. was already considerably over 5Mb, and therefore on the road to commercial failure.