PNG images w/Alpha layer in a 2D game

[appel]

Hey,

I'm very new to game programming, and I am designing a my game graphically. I was thinking about using PNG images with Alpha channel support for my sprites, but I've been testing it and it seems very slow.

I'm using java.awt to render everything. What is the best way to get the optimal performance while using alpha layer in PNG images?

[oNyx]

a) use only bitmasked images
b) use some switches to make it accelerated (doesnt work that nice or even everywhere... therefore I cant recommend that)
c) use some opengl binding (lwjgl or jogl)

If it must run sandboxed use a) otherwise c).

[appel]

It will be run using Java WebStart.

So lwjgl is very quick at processing PNG-sprites w/Alpha?

Games published by our own members! Check 'em out!

[oNyx]

>It will be run using Java WebStart.

Needs to be signed then.

>So lwjgl is very quick at processing PNG-sprites w/Alpha?

Hm. Let me put it this way. Lwjgl (or opengl for that matter) is very fast at displaying texture data with alpha... about as fast as it can get actually. PNG is just one image format you could use. While png is in most cases a very good format it isnt really suited for this case.

PNG is a very advanced format. Its pretty complex... so writing your own loader isnt really an option. You can either load it through ImageIO (which is very slow) or with openil. The latter is faster, but still a bit slow compared to TGA, which is a very simple (usually) uncompressed format.

Now the thing is if you use webstart you need to put your stuff into jars anyways. That means it gets compressed either way and the interesting thing is that both (png and tga) are about the same size at this stage. The difference is that tga loads faster and that you dont need to use imageio or openil.

Btw you can batch convert pngs with alpha with imagemagick like this:
mogrify -format tga *.png

[Vorax]

I use PNG (with alpha) for many graphics in my game, as well as ImageIO to do the loading - I haven't seen any performance problems for loading.  Infact, my game loads pretty fast considering how much it's actually loading/processing.  Granted TGA would be faster, but I don't think the speed of loading a PNG is really much of a concern.

[oNyx]

The speed difference is *huge* whereas the file size difference is basically non existant.

Really. I mean it. On a 500mhz machine it takes more than 30 seconds to load a 512x512x6 skybox with imageio. With a custom tga loader it takes less than half a second (loading a 2048x2048 texture takes less than 2 seconds [from jar - 3 times faster from directory]). Loading tga needs almost no cpu at all.

Sure you could say that its almost the same speed on your hi-end 10ghz machine, but is that equal to the specs you're targetting? And why bother with png if you gain nothing? (With jpg you would at least get rid of some bytes.)

[swpalmer]

The speed difference is *huge* whereas the file size difference is basically non existant.

Really. I mean it. On a 500mhz machine it takes more than 30 seconds to load a 512x512x6 skybox with imageio. With a custom tga loader it takes less than half a second (loading a 2048x2048 texture takes less than 2 seconds [from jar - 3 times faster from directory]). Loading tga needs almost no cpu at all.

Sure you could say that its almost the same speed on your hi-end 10ghz machine, but is that equal to the specs you're targetting? And why bother with png if you gain nothing? (With jpg you would at least get rid of some bytes.)

PNG compression is sure to result in significantly smaller files than uncompressed TGA.  Are you referring to the file size AFTER packaging in a JAR?

[Anon666]

The speed difference is *huge* whereas the file size difference is basically non existant.

Really. I mean it. On a 500mhz machine it takes more than 30 seconds to load a 512x512x6 skybox with imageio. With a custom tga loader it takes less than half a second (loading a 2048x2048 texture takes less than 2 seconds [from jar - 3 times faster from directory]). Loading tga needs almost no cpu at all.

Sure you could say that its almost the same speed on your hi-end 10ghz machine, but is that equal to the specs you're targetting? And why bother with png if you gain nothing? (With jpg you would at least get rid of some bytes.)

The png format is not complicated at all, infact I would say it is one of the simplest advanced image formats.

Any differences in decoding speed bwteen png & tga should be solely down to zlib decompression Vs rle decompression.
(Obviously zlib compression will always obtain superior compression ratios, at the cost of increased decoding time)

Now it has never made sense to put compressed png's inside a compressed jar file, when both are using the same compression algoithm..... but you have to overlook that insane design error on Sun's part.

For a more meaningful comparison in codec efficiency,
try comparing the loading speed of a png with uncompressed IDAT chunk, against an equivalent uncompressed  tga.
I'd wager the speeds will be nearly identical. (if they arn't - its Sun's decoder thats shit, not the png format itself >_<)

[swpalmer]

For a more meaningful comparison in codec efficiency,
try comparing the loading speed of a png with uncompressed IDAT chunk, against an equivalent uncompressed  tga.
I'd wager the speeds will be nearly identical. (if they arn't - its Sun's decoder thats shit, not the png format itself >_<)

Last time I checked "uncompressed" was not even allowed in a PNG file, i.e. there was no way to specify uncompressed because only one "compression format" was defined for PNG files and it was zlib.   Has that changed?

[appel]

nm.  I discovered why my game was so slow...appearently I was reloading the image for each game-loop iteration 

Games published by our own members! Check 'em out!

[JAW]

On a test i found that a transparent GIF was far faster than the same Image ans PNG. But the GIF only suppoerts 1 or 0 transparency, while the PNG has full transparency from 0 to 100%.
This is what makes it slower, where a Gif needs only to be masked.

I had best performance when I first loaded the gif to a standard Image and then draw the Image on ARGB BufferedImage.
I used a new BufferedImage.TYPE_INT_ARGB, maybe a compatible BI with Alpha would be even better.
The performance was better than using an Image or loading directly into the BufferedImage with ImageIO.

My result was to avoid png and free transparancy whenever possible. You can do some transparency work with using AlphaComposite. Using ARGB Type BIs is far faster than using non Alpha Images. When I cant let transparency out, I draw the PNG to an BufferedImage with Alpha.

-JAW

[oNyx]

>Are you referring to the file size AFTER packaging in a JAR?

Of course. "Now the thing is if you use webstart you need to put your stuff into jars anyways. That means it gets compressed either way and the interesting thing is that both (png and tga) are about the same size at this stage."

And you can store pngs in uncompressed fashion, too. The problem is that most applications dont give you a choice there.

Ah well, feel free to make your own tests etc

[Anon666]

For a more meaningful comparison in codec efficiency,
try comparing the loading speed of a png with uncompressed IDAT chunk, against an equivalent uncompressed  tga.
I'd wager the speeds will be nearly identical. (if they arn't - its Sun's decoder thats shit, not the png format itself >_<)

Last time I checked "uncompressed" was not even allowed in a PNG file, i.e. there was no way to specify uncompressed because only one "compression format" was defined for PNG files and it was zlib.   Has that changed?

png has always supported no compression (as it relies on the zlib DEFLATE algorithm which has support for no compression)  - getting a graphics package to save them in such a form is often more of a challenge.

pngcrush or optipng are both good tools for (amongst other things) generating uncompressed pngs.

[g666]

I think i might make my own image format, it'l do just what i want it to do, and nobody will be able to steal my images as easily.

[Anon666]

I think i might make my own image format, it'l do just what i want it to do, and nobody will be able to steal my images as easily.

yes, reinvent the wheel to protect IP that has in all likelyhood negligable value.
Personally I would consider somebody stealing art work of mine as a compliament.

[g666]

I think i might make my own image format, it'l do just what i want it to do, and nobody will be able to steal my images as easily.

yes, reinvent the wheel to protect IP that has in all likelyhood negligable value.
Personally I would consider somebody stealing art work of mine as a compliament.

just a bit of fun....