- July 4, 2013 at 7:58 am #31331
Steps to reproduce:
* Create a new texture
* Use edit individual channels to fill all channels with 0, except red which you fill with 255
* Encode the current texture using BGRA 5551, DirectX 11 (9_3)
* Save texture as Direct Draw Surface (*.dds)
* Inspect the outputed file using your favourite tool
* Repeat the procedure to test the color mask of the remaining channels
* Notice the DDS_HEADER_DXT10 dxgiFormat specifies DXGI_FORMAT_B5G5R5A1_UNORM
* Notice the value of the first pixel is: 0x003e for red, 0x07c0 (green), 0xf800 (blue), 0x0001 (alpha)
According to Microsoft’s documentation of the DDS file format the color mask for DXGI_FORMAT_B5G5R5A1_UNORM should be: 0x7c00 for red, 0x3e0 (green), 0x1f (blue), 0x8000 (alpha)
PVRTexTool 4.04 (SDK build 3.1@2308999)
Windows 8, (64bit)July 4, 2013 at 5:04 pm #37602
So in the tests I have been doing (granted I’m using using 4.05 – the next release), there are no values output into the channel masks, which is actually correct behaviour. It’s important to note that DXGI_FORMAT_B5G5R5A1_UNORM != D3DFMT_A1R5G5B5 – the order of the channels is reversed. The DXGI format is supported only as a DX10 format, and not actually specified by microsoft’s DDS specification for D3DFORMATs. Subsequently, the d3dpixelformat’s “FOURCC” variable is set to “DX10” to specify such, along with appropriate flags. In DX10 only formats, a mask is unnecessary and generally ignored. Microsoft’s own DirectX texture library behaves in this manner.
The flags for the rgb and alpha masks are also not set for DX10 style textures, signifying that these mask values are not valid.
I couldn’t see any documentation stating otherwise on the page you’ve linked me to. If you still believe there is an error here, could you highlight the passage which you believe states so?
TobiasJuly 4, 2013 at 6:31 pm #37603
Hi Tobias – Thank you for you help.
I am not referring to the mask part of the DDS_PIXELFORMAT structure. I am aware that these values will be zero for DDS files that use the DDS_HEADER_DXT10 🙂
The problem is that the color encoding PVRTexTool outputs for pixel values (the image data) for DXGI_FORMAT_B5G5R5A1_UNORM is incorrect. You may find the correct encoding of image data expected for DXGI_FORMAT_B5G5R5A1_UNORM on the following page under the subheader “Common DDS File Resource Formats and Associated Header Content”. This page also specifies that DXGI_FORMAT_B5G5R5A1_UNORM == D3DFMT_A1R5G5B5.
You could also try to load up a DDS image exported from PVRTexTool using BGRA 5551, DirectX 11 (9_3) and render it straight without any conversion with Direct3D 11 to view the incorrect color encoding 🙂
Ask me any questions if you should have trouble reproducing the bug.