ATF format issue

[bboltz]

Hello,

I'm using the dds2atf source code to reac a ATF file, but I'm having some problems.

The ATFFileFormat.pdf docs don't accurately describe the format of the LZMA compressed data sections.

We need to know:

• starting offset of LZMA props data (first 5 bytes?)
• starting offset of LZMA uncompressed size (3 or 4 bytes?) (stored as big-endian or little-endian?)
• starting offset of LZMA compressed data

I tried many variations, but I always receive errors when trying to decode the LZMA sections.

Thanks

[tinic]

Say you want to decode DXT1Data (see ATFFileFormat.pdf):

• starting offset of LZMA props data (first 5 bytes?) Yes, first 5 bytes of DXT1Data

• starting offset of LZMA uncompressed size

  uncompressed size is not stored. It's is determined by the width and height of the current mip level.

  For DXT1 (DXT1Data): var w4 = max(1,mipLevelWidth/4); var h4 = max(1,mipLevelHeight/4); var uncompressedSize = w4 * h4 * 4; // sizeof(uint32_t)

  For DXT5 (DXT5Data): var w4 = max(1,mipLevelWidth/4); var h4 = max(1,mipLevelHeight/4); var uncompressedSize = w4 * h4 * 6; // sizeof(uint32_t) + sizeof(uint16_t)

  For ETC1 (ETC1TopData): var w4 = max(1,mipLevelWidth/4); var h4 = max(1,mipLevelHeight/4); var uncompressedSize = w4 * h4; // sizeof(uint8_t)

  For ETC1 (ETC1BottomData) var w4 = max(1,mipLevelWidth/4); var h4 = max(1,mipLevelHeight/4); var uncompressedSize = w4 * h4 * 4; // sizeof(uint32_t)

  For PVRTC (PVRTCTopData): var w4 = max(1,mipLevelWidth/4); var h4 = max(1,mipLevelHeight/4); var uncompressedSize = w4 * h4; // sizeof(uint8_t)

  For PVRTC (PVRTCBottomData): var w4 = max(1,mipLevelWidth/4); var h4 = max(1,mipLevelHeight/4); var uncompressedSize = w4 * h4 * 4; // sizeof(uint32_t)

• starting offset of LZMA compressed data 5 bytes into DXT1Data.

[bboltz]

Thanks for the reply.

The data seems to be decompressing without errors now, but decoding the DXT1/DXT5 data gives me garbage pixels. Trying to decode DXT5 data crashes on me. My decoders work correctly on the raw DXT1/DXT5 sections that haven't been compressed with LZMA, so something is still not correct here.

Well, I think I'll ignore it for now and read in JXR data instead. Thanks.