Java-Gaming.org    
Featured games (91)
games approved by the League of Dukes
Games in Showcase (579)
games submitted by our members
Games in WIP (500)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  PNG - Not What You Need  (Read 2896 times)
0 Members and 1 Guest are viewing this topic.
Offline princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Posted 2003-02-24 08:35:39 »

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.

Cas Smiley


Offline cfmdobbie

Senior Member




Who, me?


« Reply #1 - Posted 2003-02-24 10:52:43 »

I have to say I dislike file formats that include compression systems, at least for lossless compression anyway.  I like my images to be good at being images, and leave the problem of making them smaller to the archive they're stored in or the protocol they are transferred across.  Why bother compressing an image internally these days; it only really affects the amount of disk space it uses - who's running out of that?

As for containing too much info, PNGs can be stripped down to just three chunks - IHDR, IDAT and IEND.  That should make them a bit smaller.  But you still have to implement your own LZ77 inflate/deflate algorithm.  After removing it from an already compressed archive...

I currently use SGI and TGA image formats for everything.  SGI's header contains a bit more than required, but most of it boils down to zeros.  It stores pixel data in the same form/order to OpenGL.  TGA stores pixel data in seperate channels, which compresses nicely with large blocks of colour.  Both formats provide optional (i.e. totally ignored) RLE encoding, and both formats (can) treat the image origin as bottom left.  Nice!

Hellomynameis Charlie Dobbie.
Offline princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #2 - Posted 2003-02-24 11:06:10 »

It's all about downloads. There's no magic you can do to the Wise self-installing .exe to get your images cleverly compressed... I mean, I really wouldn't bother if this were going on a CD, but it's primarily going to be digitally delivered. As are most people's demos. That's where it counts. It's as important to make a good demo as a great game.

Cas Smiley

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Captain-Goatse

Junior Member




I suck at teh 2D. XBOX IS BIG LOL!111


« Reply #3 - Posted 2003-02-24 17:14:36 »

I'm with this, as long as the images are easy to convert and they are capable of having 32 bit colors.
Offline princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #4 - Posted 2003-02-24 18:06:02 »

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 Smiley

Offline William

Junior Member




No Exit


« Reply #5 - Posted 2003-02-24 19:03:26 »

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).
Offline gregorypierce

Senior Member




I come upon thee like the blue screen of death....


« Reply #6 - Posted 2003-02-25 02:08:42 »

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.

http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Offline princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #7 - Posted 2003-02-25 08:52:49 »

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 Smiley 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 Smiley

Offline vrm

Junior Member




where I should sign ?


« Reply #8 - Posted 2003-02-25 11:12:47 »

Cas, your decoder is faster than the png one ?
Offline princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #9 - Posted 2003-02-25 12:12:21 »

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 Smiley

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline SpongeBob

Junior Member




Who lives in a pinnapple under the sea


« Reply #10 - Posted 2003-02-25 20:44:35 »

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.
Offline princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #11 - Posted 2003-02-25 22:18:39 »

Er, yes, exactly.

Cas Smiley

Offline ap_kelly

Junior Member




Java rocks!


« Reply #12 - Posted 2003-02-25 22:58:28 »

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.

Offline princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #13 - Posted 2003-02-25 23:15:47 »

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 Smiley

Offline SpongeBob

Junior Member




Who lives in a pinnapple under the sea


« Reply #14 - Posted 2003-02-26 02:40:18 »

Quote

Er, yes, exactly.


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:

1.  What bit formats does it support (4, 8, 16, 32, etc)?
2.  Transparency?
3.  Animation?
4.  Color palette?
5.  Render speed?
6.  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.
Offline princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #15 - Posted 2003-02-26 08:37:15 »

Quote

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.

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.

Quote

1.  What bit formats does it support (4, 8, 16, 32, etc)?
2.  Transparency?
3.  Animation?
4.  Color palette?
5.  Render speed?
6.  Size of compression?


I was shying away from outright demanding that people use my code Smiley 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).

Quote

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.

I think you've misread the whole post somewhere Grin 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 Smiley

Offline bedelf

Junior Member




Are you suggesting coconuts migrate?


« Reply #16 - Posted 2003-05-27 09:15:12 »

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. Tongue

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? Smiley

Edit: btw I like the new puppy logo, no offense, but the old one made me want to stab myself blind. Smiley
Offline princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #17 - Posted 2003-05-27 10:02:30 »

Grin

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 Smiley

Offline bedelf

Junior Member




Are you suggesting coconuts migrate?


« Reply #18 - Posted 2003-05-27 11:54:04 »

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. Tongue

Thanks Cas. Smiley

2nd edit: I just looked at the tools, yay. Mabey I'll get something going today.
Offline darcone

Junior Member




Size matters


« Reply #19 - Posted 2003-05-27 13:16:44 »

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? Wink
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #20 - Posted 2003-05-27 13:41:34 »

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.

Offline darcone

Junior Member




Size matters


« Reply #21 - Posted 2003-05-27 15:39:23 »

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?
Offline princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #22 - Posted 2003-05-27 16:47:37 »

(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 Smiley

Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #23 - Posted 2003-05-27 17:35:00 »

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?


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.

Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

xsi3rr4x (38 views)
2014-04-15 18:08:23

BurntPizza (34 views)
2014-04-15 03:46:01

UprightPath (50 views)
2014-04-14 17:39:50

UprightPath (32 views)
2014-04-14 17:35:47

Porlus (49 views)
2014-04-14 15:48:38

tom_mai78101 (71 views)
2014-04-10 04:04:31

BurntPizza (130 views)
2014-04-08 23:06:04

tom_mai78101 (230 views)
2014-04-05 13:34:39

trollwarrior1 (193 views)
2014-04-04 12:06:45

CJLetsGame (201 views)
2014-04-01 02:16:10
List of Learning Resources
by SHC
2014-04-18 03:17:39

List of Learning Resources
by Longarmx
2014-04-08 03:14:44

Good Examples
by matheus23
2014-04-05 13:51:37

Good Examples
by Grunnt
2014-04-03 15:48:46

Good Examples
by Grunnt
2014-04-03 15:48:37

Good Examples
by matheus23
2014-04-01 18:40:51

Good Examples
by matheus23
2014-04-01 18:40:34

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:22:30
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!