TGA images are percieved as loading faster because developers produce their own custom loaders rather than using ImageIO - which tends to be poor in performance for the formats it supports. This perception normally comes from creating textures rather than BufferedImages and writing a custom loader allows you to skip the BufferedImage creation steps.

The uncompressed version of TGA has the potential to be faster to load than PNG/GIF in the general case because you there is no decompression to perform - however, I would think this effect would be minimal.

If its in a jar there is decompression involved. However, thats only one decompression step and not two. Also if you use raw formats, which are packed into jars you end up with about the same size as gif/png anyways.

So, gif or png don't make much sense in java. The exception are applets where you load em directly from the server (one by one).

The speed difference is indeed minimal. Unless imageio is used.

BTW pre compressed (DXTn) textures are even faster to load. Simply because its less to load and there is also no decompression (unless you have to use the software decompression fallback in which case it would be still *very* fast).

>Are there any good pre-written examples of TGA readers and writers out there?

Sure. But what are you exactly looking for? Java2d, lwjgl, jogl... something else?

Thats a little unfair. A compression method specialised for a particular type of content is always going to have the advantage over a general purpose one.

PNG is usually smaller than GIF. PNGOUT uses the same compression algo as kzip. LZMA is superior to deflate (zip/png).

A raw format with lzma compression is way smaller than the same with png/gif. With zip you only get about the same file size (raw->deflate vs deflate->deflate).

Only lossy formats can be smaller... so it seems (I tested this stuff a lot). So... use jpeg, wavelet, DXTn if possible and otherwise something raw (or gif/png for java2d stuff if you're feeling lazy... wont make much of a difference there either way... bout the same size... loads slightly slower).

I think that a call like this would be part of the problem. I also wrap it in a MediaTracker (ick) to show the whole thing in one shot rather than gradually. Toolkit.getDefaultToolkit().createImage(imageBytes);

IIRC, Toolkit is marginally better than using ImageIO but still within the same order of magnitude in terms of performance.

Perhaps switching that over to something more efficient would solve the problem.

Loading times are trivial whichever format you use and it would make more sense in my mind (just a feeling) to use a more "advanced" format like PNG. For some reason, to me, a project feels more "robust" and "mature" when it uses PNGs instead of TGAs. silly ofcourse... oh well.. just my 2ct's

30sec+ vs <1sec on slower machines if ImageIO is used. And that for a single 512x512 skybox.

Longer loading times increase the upfront commitment, which decreases the replay rate.

>For some reason, to me, a project feels more "robust" and "mature" when it uses PNGs instead of TGAs.

How so? Because no space is saved and it loads slower? (If an installer is used, you would actually waste quite a lot of space.)

The average player wont look into your jars, but everyone will have to sit through the loading screens.

Amen. My low end users currently have to put up with 5-10 second loading times using PNG's and Toolkit.createImage while the high end users still have to sit through a second or two. If the format my engine uses is completely transparent to the end user unless they snoop through my JAR's, does it really matter what I use?

Well, I have to admit my projects usually involve lots of small files as opposed to large files. But 30 sec vs <1sec ... it sounds unbelievable... does ImageIO suck that bad?

I think that's a little bit of an overstatement, but yes, it is quite bad if you are loading large files. When I use kev's TGA loader, I will give you some actual numbers reported by end users for comparison.

forget about TGA or PNG...DDS is the way to go for OpenGL games. Its simplish to parse and it includes mipmaps inside the format, so you dont need to calculate them. The reason I said DDS and not DXTn is because DDS is alot like TGA in the sense that DDS also supports raw, uncompressed data. However, when you use DXTn compression, its really rather neat.

The 2nd reason why I like DDS and a proprietary format is because there are plenty of importers/exporters for DDS already. But I have to admit, its not all rosy, it doesn't support floating point texture formats for use in HDR and things like that, but that should be remedied in DX10 i think..

Well, dds also covers everything what tga can do (apart from that RLE crap, which no one needs). What dds lacks is something jpg/jp2 like. But the DXTn modes are a very appealing compromise, because it also saves vram.

Speaking of which... a rather complete dds loader would be nice to have.

That loader suckz, as i can say. I used the loader in the first attempt and was very frustrated that much stuff had'nt worked. The easiest way to do your own DDS Loader is to stick into MSDN and NVidia documents. I preferered later one and found some good informations.

For some time i posted a small DDS loader at the lwjgl forums, since that i still not finished the loader due the lack of time.It misses mipmaps and all the other advance stuff. Only basic loading is supported.Anyway, to get a closer look take a look

Last question - I need to be able to load in TGA's into actual Java Images for use in say... the editor.

What's the easiest way to do this given that Kev's code returns a ByteBuffer? I tried transforming it into an IntBuffer, then an int[] to create a BufferedImage, but it seems that I can't do that because of the way the ByteBuffer was created.

I actually tried that one last night, and it flopped on the images with transparency. That and... I didn't really think it was all that fast in loading in. Does that have something to do again with it being a plugin for ImageIO?

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