Both of the public versions only support non-RLE, 24bit/32bit images. Thing can go astray if you pump anything else in. They also both create only POT sized buffers. So if you're passing in something like 1024x826, you'll get a buffer for 1024x1024.

I'll hold my breath on this, but I think my problem was that these weren't 24 or 32-bit TGA's to begin with. :/

I used ImageMagick, and apparently, it took my PNG's (which I think were 8-bit) and converted them over to 8-bit TGA's. That's my guess because your function's valiantly trying to load what it claims are 8-bit TGA's.

That worked for example (gives you a 32bit tga). But its quite crap like this. (Well, its not that bad... after compression its only about 25% bigger than it needs to be.)

TGA supports different 8bit modes. 15bit (5-5-5), 16bit (5-5-5-1), 24bit (8-8-8) and 32bit (8-8-8-8) afaict. However, I don't have a clue how to create anything else than those with a 24bit palette.

Well, I guess a semi logical step would be to create a java program, which can be used to convert 8bit gif/tga files to tga with 32bit palette. And adding some stuff to the loader to handle 24 and 32bit palettes (the other modes aren't any useful imo).

Or... create some custom format, which is easier to read/write.

Or... use dds and add the code for handling palletized stuff (in which case it would be cool if you share it).

Well, I got 24-bit TGA's loaded into Images, only after deciding to read all the documents (which are a bit poorly worded). It was just a matter of doing this:

1) Creating a Data Buffer and partitioning it correctly2) Choosing the right Sample Model and understanding what parameters to plug in3) Creating a writable raster and passing in the databuffer and sample model4) Making a color model5) Constructing a buffered image from raster and color model.

And this is the code that worked. I have yet to really be convinced that this is actually faster (in plain loading in, PNG wins by quite a bit still, which is not too great for the editor), but I'll see in-game. I suppose that for some of you, this is second nature, but I had absolutely no knowledge going into this, and there weren't any code samples online (that I could find). So not too bad for a few hours of work.

First, just for my own knowledge. What does the flipping mean? When I passed in "false" it created an upside down image AND one that had inverted colors like the following. Does it just mean that it turned the picture upside down and reversed all the color channels (RGB -> BGR)?

TGA images stores their color values in BGRA order and were flipped normally. The easiest would be to import them and save the RGBA an reflipped version as your own tga image. That would make it impossible for reading it with alternative software, but you don't have to go through the B<>R flipping and image flipping.

Hmm. While I haven't rewritten the routine for loading these into textures, just speaking for the editor part, it's loading in significantly slower than the PNG version, presumably because the files are now megabytes big. (Well, to be precise, they are stored in a JAR file but then streamed out which decompresses them).

While I didn't do some formal timing experiments, just plain reading them in was notably slower. When I read in all the PNG's, it read each one instantly where as each TGA had a tiny pause (0.3 seconds perhaps?).

I'll post up the full source of what I'm doing because I think there might be room for improvement. It should be noted that I did modify Kev's function to not load into POT.

Whereas before, it would take about 4-5 seconds to load it all in, it's more around 1.5 seconds to load in 16 24-bit or 32-bit TGA files all of the 1024x864 variant with file sizes of 2593 KB. That all said, PNG's still loaded in marginally faster at about 1 I'd estimate. I'll post up the code in case I goofed up somewhere, but I did about what you said. I actually tried a variant where it read the whole file in, and it came out slower than the solution I'm posting where I read in the header as normal, then bulk read the image data and then use arrays from there.

All in all, it's at least within the same order of magnitude now and more than acceptable for me, especially since the game won't ever load this many images of this size at once, usually 1 per level and occasionally several if they are animated or if there's a background and foreground image.

Is not very fast. First of all, why do you have that (alpha==0), it won't chnage anything, and when you were to mipmap your image, you'd get ugly dark edges in your scaled images. So I'd suggest you take that out.

The alpha == 0 check is bespoke for icon loading where only the rgb value is used but where black is used as transparent on some systems for bitmask only transparency. - a hack to apply some form of alpha in these cass as well.

The getByte() replacement sounds useful (I'll add soon) but PNG is still faster to just load data wise. As i mentioned at the top of the thread (I think) the percieved gain with TGA for most peope is the lack of data -> buffered image -> gl texture process when you've written a custom loader that can give you the data in the right fomat straight away.i.e. data -> texture.

The bottle neck with usng ImageIO is the conversion from buffered image to texture, not the data loading?

The alpha == 0 check is bespoke for icon loading where only the rgb value is used but where black is used as transparent on some systems for bitmask only transparency. - a hack to apply some form of alpha in these cass as well.

The getByte() replacement sounds useful (I'll add soon) but PNG is still faster to just load data wise. As i mentioned at the top of the thread (I think) the percieved gain with TGA for most peope is the lack of data -> buffered image -> gl texture process when you've written a custom loader that can give you the data in the right fomat straight away.i.e. data -> texture.

The bottle neck with usng ImageIO is the conversion from buffered image to texture, not the data loading?

Kev

Which is why... after all of this, I think I'll go with storing the image both as a PNG and a TGA. PNG for the editor and non-game related tasks and TGA for the game itself. Since I already stick everything in a JAR, the TGA's took up practically no space anyways (<< less than the space the PNG's took in the JAR).

Is not very fast. First of all, why do you have that (alpha==0), it won't chnage anything, and when you were to mipmap your image, you'd get ugly dark edges in your scaled images. So I'd suggest you take that out.

wait a second, what works? Can you write a small conclusion?I was quickly going through this thread, not fully reading everything and I noticed you guys talk about TGA as fastest for loading. Now in test PNG is better. I guess I could read everything (and I will) but still you could write a conclusion in few sentences, I like that

In lwjgl there is no awt fiddling... therefore its a lot faster there.

>TGA as fastest for loading

DXTn is the fastest. Its directly loaded (unless a software decoding fallback for ancient cards is used), its 1/4th or 1/6th of the size (compared to raw stuff like tga) and its also quite compressible on top (zip/lzma/whatever).

edit: But DXTn isn't suitable for all kinds of images. There has to be some catch, right?

In lwjgl there is no awt fiddling... therefore its a lot faster there.

>TGA as fastest for loading

DXTn is the fastest. Its directly loaded (unless a software decoding fallback for ancient cards is used), its 1/4th or 1/6th of the size (compared to raw stuff like tga) and its also quite compressible on top (zip/lzma/whatever).

edit: But DXTn isn't suitable for all kinds of images. There has to be some catch, right?

DXTn's that lossy compression format, isn't it? I'm done with this image loading stuff for the moment, but I might look into that down the line if I'm greedy about performance.

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