This Technical specifiction is Incomplete and still under construction

Mario Kart Wii SZS Files

Mario Kart Wii's SZS files differ greatly to the SZS files of all other Nintendo games I have encountered. Normally an SZS file contains the data of several other files which can be extracted back out into a file tree. While this may be the case with MKW's SZSs, they are of a different format. They appear to contain mainly model, animation and texture data, although they do contain more data beyond that, as entire courses are contained within these files.

In their raw format, they are compressed with YAZ0 compression, which reduces their file sizes significantly. Once decoded, they contain the same 32 byte header structure:

The contents list comes next starting at 0x38 (the section before this is unkown data), and for each entry in the contents there are 0x0C bytes. The first 4 represent the start of the name data relative to the start of the name list. The next 4 represent the offset to the start of the date from the start of the file, and the final 4 represent the length of that data. This continues until 00 2E 00 is reached at which point the names of the files, delimited by 00s appears and the name offsets mentioned before are relative to the start of 00 2E 00.

The file offsets lead to various chunks of data. The most noteworthy are the brres files. Brres chunks work as follows:

• Always begins with BRES in ascii
• At 0x08 there is a UInt represeting the total length of the brres data.
• At 0x10 there is the word ROOT in ascii
• After ROOT there is a UInt representing the length of the root element (starting from before ROOT).
• The ROOT element then consists of data of the following pattern:
  • Uint representing length.
  • Unknowns up till 0x18 into the section
  • 0x10 byte repeating section 0x00-0x07: unknown; 0x08: Uint - contents offset, relative to start of block; 0x0C: Uint - File offset, relative to start of block
• Following the root data's pointers leads either to elsewhere in the root data (obviously for building a file tree) or to an assorement of different types of data. Each of which can be distinguished by the first 4 bytes, which spell out a word.

Tex0

As you might expect, texture data I am most familiar with. The headers are 0x40 bytes in length, the first 4 of which spelling out TEX0 in ascii. The next 4 tell the length of the texture in bytes (including the header). The bext bytes which I have interpreted are at 0x14, at which give the offset to the name of the contents from the start of the tex0 block. The next bytes of interest are at 0x0C which equate to two bytes for the width and two bytes for the height.