DDS file for DXGI_FORMAT ...

I'm porting a DDS file reader/saver to DX10 and found something like that D3DFMT_A8R8G8B8 has no direct enum maping to DXGO_FORMAT's.

Should I do the pixel swizzle/conversion stuff for DX10, or there will be a new DDS file format which takes DX10 DXGI_FORMAT enum directly (or analogous revise)? Thanks ...

[321 byte] By [AiSorcerer] at [2008-3-7]
# 1

I've not seen any discussion about revisions to (or replacements of) the DDS file format. It's an interesting question - I'd like to know whats happening with this

Cheers,
Jack

JackHoxley at 2007-9-4 > top of Msdn Tech,Game Technologies: DirectX, XNA, XACT, etc.,Direct3D 10...
# 2

The major problem I met is that the pixels stored in the DDS file are with the DX9 compatible binary format.

For example, a A8R8G8B8 DDS file stores pixels like this, 0xAARRGGBB, with alpah bits in the DWORD's MSB. However, after DX10, new pixel format design unifies the channel ordering so there are no formats with alpha bits in the DWORD's MSB (I'd like to know this design story, too... ^^).

So when I read or save the DDS file, I has to do some channel swizzling and conversion tasks. For example, ARGB8888 to R8G8B8A8_UINT or R32G32B32A32_FLOAT. I believe the Effects API has to do this either and it already do it. I just don't want to use Effect interfaces.

Thanks~ ^^

AiSorcerer at 2007-9-4 > top of Msdn Tech,Game Technologies: DirectX, XNA, XACT, etc.,Direct3D 10...
# 3

As you need to be compatible with current programs that handle DDS you should do the swizzle.

RalfKornmann at 2007-9-4 > top of Msdn Tech,Game Technologies: DirectX, XNA, XACT, etc.,Direct3D 10...
# 4

Correct what I described ...

DXGI_R8G8B8A8 memory layout is (byte order, low-to-high) 0xRR 0xGG 0xBB 0xAA

D3DFMT_A8G8G8B8 memory layout is (byte order, low-to-high) 0xBB 0xGG 0xRR 0xAA

So swizzling is still needed~

AiSorcerer at 2007-9-4 > top of Msdn Tech,Game Technologies: DirectX, XNA, XACT, etc.,Direct3D 10...