Difference between revisions of "MREA (Metroid Prime 2)"
m (→Header) |
(→Compressed Blocks) |
||
Line 103: | Line 103: | ||
=== Compressed Blocks === | === Compressed Blocks === | ||
− | The MREA format contains compressed blocks that can each contain a number of regular file sections within them. These blocks are compressed using segmented LZO1X-999. | + | The MREA format contains compressed blocks that can each contain a number of regular file sections within them. These blocks are compressed using segmented LZO1X-999. The data defining these blocks is at the end of the MREA header; the beginning and end of the compressed block list is padded to 32 bytes. The decompressed size of a block is capped at 0x20000 bytes; each section contains as many MREA sections as it can fit under that size limit. There are two exceptions: |
− | + | * If a single section's uncompressed size is larger than 0x20000, then its corresponding compressed block can exceed the size limit. | |
+ | * Each SCLY and SCGN layer is always in its own block, regardless of how close to the limit it is. | ||
+ | |||
+ | This is the structure of each block definition: | ||
{| class="wikitable" | {| class="wikitable" | ||
Line 132: | Line 135: | ||
|} | |} | ||
+ | The actual data contained in these blocks is padded to 32 bytes, but their padding is located at the beginning of the block rather than the end, so it's required to account for the padding before you start decompressing. The compressed data is segmented, which means there's multiple segments of data that are compressed/decompressed separately. Each segment starts with a 16-bit size value. The size value is signed; a negative value indicates the segment is not compressed (this is done when compressing a segment doesn't reduce its size). Each segment is 0x4000 bytes large when decompressed (except the last one). | ||
[[Category:File Formats]] | [[Category:File Formats]] | ||
[[Category:Metroid Prime 2: Echoes]] | [[Category:Metroid Prime 2: Echoes]] |
Revision as of 02:51, 21 February 2016
See MREA (File Format) for the other revisions of this format.
The MREA format defines areas (rooms) in Metroid Prime 2. It serves the same purpose as the MREA files from Prime 1, but in Echoes it was updated with new features, including some new data sections and the ability to compress most of the data in the file.
To do: Rest of the article needs to be written. There's a lot known about this format that should be documented. |
Contents
Format
Like CMDL, MREA files are split up into a number of 32-byte aligned sections. Every section both starts and ends on a 32-byte boundary. These are used to separate different parts of the file; different types of sections typically indicate different sets of data. The header declares the section count and the size of each one; using these is the only way to navigate the file.
Header
Offset | Size | Description |
---|---|---|
0x0 | 4 | Magic; always 0xDEADBEEF |
0x4 | 4 | Version; see hub article |
0x8 | 4 × 12 | Transform matrix |
0x38 | 4 | Mesh count |
0x3C | 4 | SCLY layer count |
0x40 | 4 | Section count (SC) |
0x44 | 4 | Geometry section number (starts on materials) |
0x48 | 4 | SCLY section number |
0x4C | 4 | SCGN section number |
0x50 | 4 | Collision section number |
0x54 | 4 | Unknown section number |
0x58 | 4 | Lights section number |
0x5C | 4 | VISI section number |
0x60 | 4 | PATH section number |
0x64 | 4 | FFFFFFFF section number |
0x68 | 4 | PTLA section number |
0x6C | 4 | EGMC section number |
0x70 | 4 | Compressed block count |
0x74 | 0xC | Padding |
0x80 | 4 × SC | Section sizes |
Pad to 32 bytes before compressed cluster definitions begins |
Compressed Blocks
The MREA format contains compressed blocks that can each contain a number of regular file sections within them. These blocks are compressed using segmented LZO1X-999. The data defining these blocks is at the end of the MREA header; the beginning and end of the compressed block list is padded to 32 bytes. The decompressed size of a block is capped at 0x20000 bytes; each section contains as many MREA sections as it can fit under that size limit. There are two exceptions:
- If a single section's uncompressed size is larger than 0x20000, then its corresponding compressed block can exceed the size limit.
- Each SCLY and SCGN layer is always in its own block, regardless of how close to the limit it is.
This is the structure of each block definition:
Offset | Size | Description |
---|---|---|
0x0 | 4 | Buffer size (0x120 bytes larger than uncompressed size - same as uncompressed size for uncompressed blocks) |
0x4 | 4 | Uncompressed size |
0x8 | 4 | Compressed size (if 0, that indicates an uncompressed block) |
0xC | 4 | Section count (the number of regular sections contained in this block) |
0x10 | Block definition end |
The actual data contained in these blocks is padded to 32 bytes, but their padding is located at the beginning of the block rather than the end, so it's required to account for the padding before you start decompressing. The compressed data is segmented, which means there's multiple segments of data that are compressed/decompressed separately. Each segment starts with a 16-bit size value. The size value is signed; a negative value indicates the segment is not compressed (this is done when compressing a segment doesn't reduce its size). Each segment is 0x4000 bytes large when decompressed (except the last one).