In the nvidia texture tool 2024.1 photoshop plugin, I can’t find 8.8.8.8 ARGB format when saving a dds file. Dose that mean it won’t support this format any longer?
Hi @xiaohuli0925! Thank you for the question. It’s there under “8.8.8.8 BGRA”.
The new plugin reversed the names of ARGB and ABGR relative to the legacy plugin. This is ultimately because the 2006 release of Direct3D 10 changed from D3DFMT_A8R8G8B8 to DXGI_FORMAT_B8G8R8A8_UNORM and from D3DFMT_A8B8G8R8 to DXGI_FORMAT_R8G8B8A8_UNORM. Today, DirectX, Vulkan, and OpenGL all list the components of this format as BGRA instead of ARGB, so the new plugin changed its name as well.
I think that should answer your question, but here’s some more technical detail in case it’s interesting!
The new name matches the order in which bytes are stored in the texture. For example, here’s an image filled with a color of B=200/255, G=150/255, R=0/255, and A=255/255:
If I save this to a DDS file using the BGRA format (previously named ARGB), then within the first mip, it’ll store B in byte 0, G in byte 1, R in byte 2, A in byte 3, and so on for each of the pixels.
In Direct3D 9 (where the ARGB name came from), the byte layout depended on the endianness of the system – whether it stored the least significant byte of integers first (little-endian) or the most significant byte of integers first (big-endian). Most computers today are little-endian, but the XBox 360 and PS3 were big-endian. So D3DFMT_A8R8G8B8 would store in BGRA order on little-endian systems and ARGB order on big-endian systems. I wasn’t doing graphics programming back then, but I figure this must have caused problems at least once – imagine copying a DDS file from one system to another but having it display incorrectly due to endianness!
D3D10 and DXGI_FORMAT_B8G8R8A8_UNORM resolved this issue by always specifying the order in which bytes are stored.
Hope this helps!