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?
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.
As per the other thread, I’ll redocument this and change the mappings so that “ARGB1555” is the correct format to use for this, rather than the other way around.