There’s absolutely nothing funny going on in the code - it’s just a tiny header explaining the type, dimensions, and length etc. and then gzipped delta planar data. It’s in sourceforge right now so have a look.
Cas 
I wrote a PNG 1.0 encoder/decoder once before that was included in Sun’s Java implementation. It does not support all the chunks, but it does support the standard ones and all image types I think. The encoder and decoder are written as two separate classes so there are not a bunch of small classes to keep track of, but both classes depend on the java.zip package for compression/decompression. The codec was written for an image editing application project so it used raw arrays rather than the standard java image classes.
Is there any interest from any of you people with library projects going to include such a codec in your libraries? I can probably clean up the classes and send them to you, but I will only do it if they would actually be useful to anyone since I soon expect to get busy with my own project (see volunteer projects section).
Cas, the more you write about it - the more it souds like you’re using the wrong tool for the job and should be importing the JVM into C as opposed to using C libs from Java.
Sometimes I think it’s that way round as well. But to be honest I’d write the whole thing in straight C or C++ if I wanted to make life easy for myself My enemy is still the size of core Java. I really, really, want a J2ME VM specifically tailored for games, for Win32 and Linux. If they could just get it down to under a meg and as fast as the server VM I’d be sold but it won’t happen any time soon.
The advantages in using Java are probably only going to become apparent in the next game I write. Most of my code is reusable or very easily refactored. The same can’t usually be said of the final horrible stages of dragging a C++ game into production unless you’ve got rather more time on your hands.
I’ve got to remember that I only started A.F. in December so it’s had less than 3 months of part-time work on it. It would have been less probably if I’d hacked it all up in C++ but then I suspect that trying to use the code for the next game - probably Quest For The Holy Grail - would be counterproductive.
Cas
Cas, your decoder is faster than the png one ?
Well, it uses the same zlib decompressor that comes with Java so I suspect it’s about the same. The crucial difference for us LWJGL devs is that it does it all in bytebuffers so we can directly shove it into OpenGL. And of course, the fact that it stores sprites at around 50% of the size of compressed .PNGs. And even more of course, it doesn’t rely on 1,000 other classes to be loaded prior to using it.
Cas
I think its rather moot to compare a format you created to PNG. PNG format is not that bad of a format and has lots of uses. But even the groups who make PNG recognize that its not always the best tool for the job.
http://www.libpng.org/pub/png/pngintro.html
Does your format cover 256 layers of partial transparency? Probably not if its intended for games. But whoever said PNG was good for games? I myself prefer GIF and BMP for that. Thats more of an issue of preference and ease of use since both those formats can be edited with tools like Photoshop or GIMP.
PNGs a good format. Maybe not for games … but it has its uses.
Er, yes, exactly.
Cas
Here is a nice library, not too large that does PNGs, its also used by the gl4java guys.
http://www.sixlegs.com/software/png/
The jar itself is only 60k in size and comes with a load of source code as well.
Regards,
Andy.
It’ll still require images 100% bigger than they need to be though. And sixlegs drags in a huge chunk of the AWT as well…
Cas
Why not just announce you created a program that reads in your own image format rather than compare it to PNG? Discrediting PNG wont make your code any more appealing to game developers since there are plenty of other formats in the world to choose from. Information that might make it appealing:
- What bit formats does it support (4, 8, 16, 32, etc)?
- Transparency?
- Animation?
- Color palette?
- Render speed?
- Size of compression?
Arguments over “number of classes” or “size in megabytes” is redundant. If a developer is concerned about these issues he/she could just as simply opt not to use your format and just use Java’s core support for GIF and/or JPEG since your format adds both a class and increases the apps footprint. Food for thought.
Precisely. If you read the post again, I’m not discrediting PNG, which I think is an excellent general image format. However, its use in Java brings a ton of extra code you don’t need, and the image footprint on disk/download is twice as high as can be achieved when compressing game sprites.
I was shying away from outright demanding that people use my code Besides, it’s open source so you can see if it fits your criteria, but anyway:
1 & 2 & 4. Supports 8-bpp colour channels: Alpha, Luminance, Luminance Alpha, RGB, RGBA, BGR, BGRA, ARGB, ABGR. Oh, and 8-bit palette.
3. No animation. It’s an image file format, not an animation file format.
5. It’s not a rendering component, it’s a data store. It’s for use with LWJGL, which does the rendering.
6. Compression is considerably better than .PNG files (approx 50% original size for my sprites, YMMV).
I think you’ve misread the whole post somewhere ;D Those are exactly the issues I’m raising. My format adds one class and removes about 1,000 other classes. But I can’t stress this enough: most importantly it achieves far better compression than .PNG for game sprites.
Cas
What are you using to get your images to your image format in the first place? I’m playing with SPGL right now and I need some acual image data to load. 
Tomorrow (edit: later today since it’s 3am) I’m gonna write a java .png->puppy image converter unless you got one I can look at?
Edit: btw I like the new puppy logo, no offense, but the old one made me want to stab myself blind.
;D
The SPGL tools, in the same CVS as the rest of SPGL. There’s a sprite-packing thingy in there, and a resource converter, and an image converter. The sprite-packing thingy works well with the sprite engine in SPGL.
Cas
Edit: sonofabitch. What you were saying just clicked, I just looked at the sourceforge page and indeed there is spgl-tools, which I don’t have. It just wouldn’t do for me if I didn’t look like a jackass EVERY day.
Thanks Cas.
2nd edit: I just looked at the tools, yay. Mabey I’ll get something going today.
Hmm, by using the PNG loading with AWT, will it slow down my game, even if I´m loading the images when I start the game? And what will the license stop me from doing exactly? And why is PNGs bad for games, don´t really get it? 
The argument isn’t that PNGs are bad for games… it is more like PNGs are bad for download size when compared to other relatively simply image storage methods that are suitable for game images.
Cas is getting data that is half the size as PNG for the same image… since he is making a downloadable and images make up a big chunk… he is saving quite a bit by not using PNG.
Ok, and the licensing? My game is going to be free, how will using AWT to load png´s limit my ability to distribute the game etc?
(The other advantage of not using standard Java PNG support is I don’t have to load a ton of other classes and DLLs just to read a trivial image file)
There are no licensing restrictions on PNG usage.
Cas
[quote]Ok, and the licensing? My game is going to be free, how will using AWT to load png´s limit my ability to distribute the game etc?
[/quote]
That was referring to making a native executable from the Java classes. Which is something Cas wants to do for Alien Flux (and have the standard .JAR for non-windows platforms)… The thing that makes binaries requires that you distribute the whole JRE if you use any of the Sun’s AWT classes… I guess they don’t have their own implementation of mst of that stuff, and the Sun license says you can’t “cripple” the JRE by only shipping bits and pieces.