Support for D3DFMT_A8L8

May 10, 2013 at 12:01 AM
I noticed that the DDS loader converts D3DFMT_A8L8 files to DXGI_FORMAT_R8G8_UNORM. This will cause the alpha to be lost, and instead be used as green. I made some changes to instead convert it to DXGI_FORMAT_R8G8B8A8_UNORM. This does involve expansion, but at least the alpha is properly preserved, without requiring shader changes.

I am mentioning this here in case anyone encounters the same issue. The changes are in DirectXTexDDS.cpp. Let me know if you are interested in this.

— Mauricio
May 10, 2013 at 12:45 AM
The general assumption is that you are trying to preserve the 2-channel nature of the data. I could add an optional flag to the DDS loader to convert like this. Can you come up with a complete list of 'alternative' conversions and post it here?
May 10, 2013 at 12:49 AM
So far I would think:

'standard' (non-expanding)


'alternative' (expanding)

DDSPF_L8 -> DXGI_FORMAT_R8G8B8A8_UNORM (r,g,b replicated)
DDSPF_L16 -> DXGI_FORMAT_R16G16B16A16_UNORM (r,b,g replicated)
DDSPF_A8L8 -> DXGI_FORMAT_R8G8B8A8_UNORM (r,g,b replicated)

Are there others?
May 10, 2013 at 1:13 AM
I guess I wouldn't consider these as expanding or not. What is more important (at least for our purposes) is that alpha from the source ends up in alpha in the destination, and that luminance is replicated to RGB if expansion is required. In this case, DX11 simply doesn't support A8L8, and while R8G8 can store the data, the result is interpreted differently by default.

In other words, if I have a legacy DDS file (like A8L8) and I load it with DirectXTex to a supported format, and then save it again to DDS, will the two DDS files look the same in a DDS viewer? With the existing DirectXTex code, a grayscale A8L8 DDS file turns into a red/green R8G8 file.

That being said, more options wouldn't hurt here. If I were trying to be totally complete, I would use the following list...

... and make sure each "Not Available" entry has a reasonable story.

— Mauricio
May 10, 2013 at 1:46 AM
Note: The DDSTextureLoader uses the same mappings because it does no conversions or expansions at all...
May 15, 2013 at 8:31 PM
I actually wrote that table with a co-worker, so some of the mappings are already captured. The key issue is that you want no conversions in the shader, which means you'd rather have the texture get 'bigger' to avoid this.

There are a number of "Not Available" options that don't really come up in DDS files (Depth, VB, IB) or simply don't apply to Direct3D 10.x/11.x (bumpmap). The three I listed above really do seem to be the only cases where this applies.
May 15, 2013 at 8:40 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
May 16, 2013 at 7:09 AM
Great, thanks for following up on this!

— Mauricio
Jun 15, 2013 at 8:18 PM
This has been fixed for the June 2013 release