DDS Texture Flip problem

Troubleshooting graphics
1

DDS didn't respond whether flip option is ture or false.

After research JME, I realized that it doesn't flip automatically.

So, after I read JME.DDSLoader, I found that there's no flip code.



< DDSLoader.java >

// !! Does not have flip code!!

public ByteBuffer readData(boolean flip) throws IOException {
   int totalSize = 0;

   for ( int i = 0; i < sizes_.length; i++ ) {
      totalSize += sizes_[i];
   }

   byte[] data = new byte[totalSize];
   in_.readFully( data );

   ByteBuffer buffer = ByteBuffer.allocateDirect( totalSize );
   buffer.put(data);
   buffer.rewind();

   return buffer;
}



In my present project, DDS format is used occationally. So if it doesn't support flip, it will be a big problem.
I really need your help.

2

DDS flipping would be very good to have (it would standardize functionality of our image loading code), however it is a bit more complex than other image formats so it has taken a back seat to other tasks.  If you want to donate some code for this, or know someone who can, that would be great.

3

DDS flipping is pretty easy. The format is blocked in 4x4 pixel blocks. Each pixel block has the following format:



DXT1:

16 bits palette[2]

8 bits data[4]



So, to flip a single block upside down, you byte-swap the 4 bytes named "data". You leave the "palette" alone. Each data block is four pixels wide of two bits per pixel.



In DXT2/3, each 4x4 color data block (which is the same as for DXT1) is preceded by alpha in the form:

16 bits data[4]



So, you can word-reverse that data. Each scanline of pixels is 4 4-bit values, where 0 means transparent and 15 means opaque.



Finally, in DXT4/5, each 4x4 block is preceded by alpha in a different format:

8 bits palette[2]

12 bits data[4]



This gets slightly tricky, because you need to do bit shift operations to move those 12-bit chunks around. The exact bit layout is documented on MSDN in the Direct3D documentation section (look for the DDS file format and DXT compression).



Once you have your 4x4 pixel blocks (64 or 128 bits per 4x4-pixel block), the blocks go from left to right, from bottom to top, just like TGA or BMP. This is why DXT compressed images need to be a multiple of 4x4 pixels in size. Further, the final (small) MIP levels are each rounded up to a multiple of 4 pixels, so a 16x16 texture will have the following sizes in pixels for the different MIP levels:



16x16

8x8

4x4

4x4 (not 2x2)

4x4 (not 1x1)

4

You could do it the 'nub' way and flip the image with a texture matrix…

5

Or you could define that the texture V coordinate goes from first image byte towards last image byte, like it is in OpenGL and Direct3D and most other tools, and not have to flip at all :slight_smile: