MREA (Metroid Prime 2): Difference between revisions

From Retro Modding Wiki
Jump to navigation Jump to search
>Aruki
(some data has to be repeated between articles with this setup but it's probably worth it for the clean separation of differences between versions of the format.)
 
>Aruki
m (→‎Format: whoops)
Line 8: Line 8:


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.
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 ===


{| class="wikitable"
{| class="wikitable"
Line 99: Line 101:
Following the section sizes comes an array defining the file's compressed cluster. Each definition is 0x10 bytes and is formatted like this:
Following the section sizes comes an array defining the file's compressed cluster. Each definition is 0x10 bytes and is formatted like this:


{{ class="wikitable"
{| class="wikitable"
! Offset
! Offset
! Size
! Size

Revision as of 14:59, 28 January 2015

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.

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 Empty section number
0x60 4 PATH section number
0x64 4 FFFFFFFF section number
0x68 4 Unknown section 2 number
0x6C 4 EGMC section number
0x70 4 Compressed cluster count
0x74 0xC Padding
0x80 4 × SC Section sizes
Pad to 32 bytes before compressed cluster definitions begins

Following the section sizes comes an array defining the file's compressed cluster. Each definition is 0x10 bytes and is formatted like this:

Offset Size Description
0x0 4 Buffer size (usually 0x120 bytes bigger than uncompressed size)
0x4 4 Uncompressed size
0x8 4 Compressed size (if 0, that indicates an uncompressed cluster)
0xC 4 Section count (the number of regular sections contained in this cluster)
0x10 Cluster definition end