- Format Type : Archive
- Endian Order : Little Endian (for PC variant) or Big Endian (XBOX or PS3 variants); the platform type is specified in the header
SDS is an archive format used in the game Mafia II developed by 2K Czech. The page describes the SDS files as seen on the Windows version of the game. Other platform ports might use the same variant.
The overall structure of an SDS file is:
signature preamble archive header resource type table block table (actual data) XML descriptions
Preamble and Header
An SDS file begins with the following 8-byte preamble:
bytes 0-3 file signature string: 'SDS\0' bytes 4-7 0x00000013 (either a version number of a length value specified in 32-bit words)
The header has the following 60-byte structure:
bytes 0-3 platform string/endian-ness indicator bytes 4-7 0x5FFB74F3 bytes 8-11 resource type table offset bytes 12-15 block table offset bytes 16-19 XML offset bytes 20-23 slot RAM required bytes 24-27 slot VRAM required bytes 28-31 other RAM required bytes 32-35 other VRAM required bytes 36-39 unknown bytes 40-55 array of 16 bytes; purpose unknown bytes 56-59 file count
There are 3 known values for the platform string, and the endian-ness of multi-byte numbers keys off of this value:
- 'PC\0\0' for the PC version of Mafia II; multi-byte numbers are little-endian
- 'XBOX' or 'PS3\0': multi-byte numbers are big-endian
Resource Type Table
Following the header is the resource type table offset (the absolute offset of this table is also referenced by the "resource type table offset" field in the file header). The table begins with the count of resources in the table.
Following the count, there is an entry for each resource in the archive. Each entry has the following format:
bytes 0-3 ID bytes 4-7 length of name field in bytes bytes 8..n resource type bytes 8-11 parent
Presumably, the ID and parent fields help to link resources together. Known resource types include:
Following the resource table is the block table. The absolute offset of the block table is indicated by the "Block table offset" field of the archive header. The blocks in the block table carry the payload data of the archive.
Texture Resource Type
A texture resource contains a DDS texture file. While DDS already describes a lossy, constant bit-rate image compression algorithm, SDS files typically compress this data further using standard, lossless zlib compression.
The header of a texture resource payload has the following format:
bytes 0-3 signature: 'UEzl' bytes 4-7 unknown byte 8 unknown, but should be 4
Following this is a sequence of blocks which have the following header:
bytes 0-3 size byte 4 compression flag
If the compression flag is set, then this block is compressed. The header for a compressed block has the following header:
bytes 0-3 uncompressed size bytes 4-7 unknown bytes 8-11 unknown bytes 12-15 unknown bytes 16-19 compressed size bytes 20-23 unknown bytes 24-27 unknown bytes 28-31 unknown
Following the header is a data compressed using standard zlib.
To decompress the data, iterate over blocks until encountering a block with a size of 0.
The end of an SDS file contains XML data. The absolute offset of the start of this data is indicated by the "XML offset" field of the header. The XML contains a textual description of some of resource's parameters. For example:
<xml> <ResourceInfo> <CustomDebugInfo/> <TypeName>Texture</TypeName> <SourceDataDescription>wanted021_ps.dds</SourceDataDescription> <SlotRamRequired __type='Int'>0</SlotRamRequired> <SlotVramRequired __type='Int'>2097152</SlotVramRequired> <OtherRamRequired __type='Int'>0</OtherRamRequired> <OtherVramRequired __type='Int'>0</OtherVramRequired> </ResourceInfo> </xml>
Some SDS files are encrypted using the Tiny Encryption Algorithm (TEA) cipher.