Discussion on SWBF2 Textures and Models (FAQ)

[Riley75]

I can help with the color information in textures... Are you having trouble reading the pixels from the game textures, or writing them to TGA?

I imagine the game uses different formats as a trade-off between texture quality and speed. Textures that are going to be used to cover a large area need to be as detailed as possible; while others can be compressed.

The format to use is determined by the *.option files. Your program could probably generate those *.option files as well, in order to keep it consistent when the texture goes back in the game.

[Nimlot]

First, exactly, I was planning on also exporting the .option files with each of the formats it needs to be remunged into.

And for my problem, lol, well, as I was writing this response I remembered an idea I had earlier today. I just tried it, and yes, that fixes the problem.

Basically, lets use format 23 for example. It only had 5, 6, 5 bits of data for RGB, or 31, 63, 31 possible values. I realized this was leaving out much of the possible 0-255 values, so I multiplied each value by 255/31(or 63), and now it works great. I'll post an update later after I try more formats.

[Riley75]

The most accurate (and computationally fastest) way to deal with that is to shift-left by (8 - BitsPerChannel).
For 5 bits, shift left by 3 ( same as multiply by 8 ).
For 6 bits, shift left by 2 ( same as multiply by 4 ).
etc.

How are you doing with the DXT formats?

[Nimlot]

Havn't touched the DXT formats yet, as I was hoping I wouldn't have to deal with them (use other "formats" to get the TGA). I really dont know where to begin with its "compressed" format, not even sure what the "means".

[Riley75]

Hmm, good point... I'm even thinking there may be a way to use DirectX API calls to load in the texture, get it in some common form (32 bits per pixel), and then output to TGA from there... If so, you could avoid having to make a dozen (or more) different pixel format readers.