Hi. Say, for your 2d OpenGL game (which will be finished by 2010 or so) you've to load many 2d textures, stored as compressed PNGs on disc/Jar/whatever. This even applies to a single level, so you're very keen to use the fastest way to feed these PNGs to your OpenGL card. Which is a really fast way?

Currently I load them via ImageIO to a BufferedImage whose raster.getDataBuffer() I feed to the Ogl texture bind call o.glTexImage2D(...).However, this takes a long time.Maybe I could cache those PNGs when they've been uncompressed for the first time and write them to plain files (into a cache folder) and then at the next run the game would load them via (mapped) "new I/O" or such?However, maybe loading large uncompressed files from disc takes even longer than loading smaller compressed ones plus their cpu time needed to uncompress them...?

All the way through ImageIO, into Images, into rasters... is pretty slow. Loading TGAs is more than 10 times faster on my machine. Loading TGAs through a GZipInputStream should be still faster than PNGs through ImageIO (and you get about the same compression - with my test images it was actually a bit better in each case).

However, gzipping em isn't really necessary if you want to use webstart. You can gzip the whole thing there, it gets decompressed on the client side.

Well, yea decompressed... it's bigger. If you have a rather slow hdd which can read ~30mb/s, you would need 0.15 seconds for loading a six 512x512 images (eg a skybox).

All the way through ImageIO, into Images, into rasters... is pretty slow.

Yes. It matters when you start to load many images at once...

Quote

Loading TGAs is more than 10 times faster on my machine.

Uncompressed TGAs?How do you load them? Do you use a TGA loader (which one?), or do you load the bytes directly and examine its (mini) header for bpp, height, with, etc? (I guess so.)

Quote

Loading TGAs through a GZipInputStream should be still faster than PNGs through ImageIO (and you get about the same compression - with my test images it was actually a bit better in each case).

Using GZiped TGAs could be a good idea; we would have to do some tests. Indeeds, it's even slighty smaller.However why should they decompress faster compared to compressed PNGs? (Because Java's gunzip is faster than ImageIO's PNG decompressor?)

However, then I couldn't control the tons of images laying around on disc with a picture viewer anymore... which is nice when using PNG.Jedit supports GZip txt files, but Xnview doesn't show GZIped TGAs. :-|

Quote

However, gzipping em isn't really necessary if you want to use webstart. You can gzip the whole thing there, it gets decompressed on the client side.

You mean the usual Webstart JARs, so the TGAs inside it would be decompressed on the fly at loading time?

Only the first one get stored in compressed for on the client. However, 2+3 are smaller (through the net) and get decompressed by webstart once (and get stored decompressed in the cache).

So you wouldn't use compressed images at all. Just plain TGAs.

(* It's backward compatible to 1.4 etc. If the webstart client doesn't ask for gzip or p200-gzip compression it will get a jar instead)

Applying additional gzip compression on the TGAs would be slower without any benefits (Except saving space on the user's hdd - which is rather pointless nowadays. No one cares if your game takes 5 or 17mb on a 120gb hdd).

Well, the topic is a bit complicated... ok actually it's pretty simple, but you need to write quite alot of text for explaining it. For keeping it simple: just use plain TGAs right now... the packing is the very last step and by that time I'll have finished that article

I just adapted a TGA Loader I found on the net. It works fine now with 24bit and 32bit translucient textures. If someone needs the code, let me know.chris

I was about to point out that if you were writing TGAs out from photshop 7.0 then it loses the alpha channel enroute even if you have one in your image. You have to get a patch from the Adobe site which fixes it up. Looks like you're not having that problem but i figured i'd post this anyway incase anyone else gets the same problem. Took me a while to cotton on to it when i encountered it first.

On another PS TGA note though, Do you find that photoshop flips your image vertically (but not horizontally) when you save it ? Theres a flag in the TGA spec (forget which, haven't looked at my TGA loader in a while) which dictates whether the image is stored with the first pixel at the 'top left' position or the 'bottom right' position. Photoshop gets it half right :-) On the other hand maybe its a bug in my loader code ... I really must look at it again ...

It's the imageDescriptor byte. The one that comes after pixelDepth. Bit 4 is horizontal flipping (left/right), bit 5 is vertical flipping (top/bottom). Last time I checked Adope photoshop and paint shop pro stored the image differently with regards to vertical flipping. So checking the flag is a good idee

It's the imageDescriptor byte. The one that comes after pixelDepth. Bit 4 is horizontal flipping (left/right), bit 5 is vertical flipping (top/bottom). Last time I checked Adope photoshop and paint shop pro stored the image differently with regards to vertical flipping. So checking the flag is a good idee

well, sometimes I can only shake my head in despair, had a gander at my TGA loading code which I've had around for quite a while originally in C++ form before i ported it across, and what do i find :

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

loByte = inStream.readByte();//TODO sort out the flipping indicated by the above byte.// from the spec // Bits 3-0: These bits specify the number of attribute bits per pixel.// Bits 5 & 4:These bits are used to indicate the order in which// pixel data is transferred from the file to the screen.// Bit 4 is for left-to-right ordering and bit 5 is for top-to-// bottom ordering as shown below.// Table 2 - Image Origin// Bits 7 & 6:Must be zero to insure future compatibility.// Image Origin bit 5 bit 4// bottom left 0 0// bottom right 0 1// top left 1 0// top right 1 1

I suppose i'll have to get around to ACTUALLY TODO-ing it one of these days :-)

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