Difference between revisions of "BREFF and BREFT (File Format)"
m |
(9+ different breff/breft pairs will cause a crash) |
||
Line 1: | Line 1: | ||
− | [[BREFF]] and [[BREFT]] appears always as pair and always in a subdirectory of <tt>./effect/</tt>. BREFF contains the control information and BREFT the graphic and texture data. | + | [[BREFF]] and [[BREFT]] appears always as pair and always in a subdirectory of <tt>./effect/</tt>. BREFF contains the control information and BREFT the graphic and texture data. A track can have up to 8 different effects, adding more will cause the game to crash. |
= File Format = | = File Format = |
Revision as of 14:50, 5 August 2020
BREFF and BREFT appears always as pair and always in a subdirectory of ./effect/. BREFF contains the control information and BREFT the graphic and texture data. A track can have up to 8 different effects, adding more will cause the game to crash.
File Format
File Header
The file begins with the header of 0x10 bytes. The structure is the same as for BRRES files:
Offset | Size | Type | Description |
---|---|---|---|
0x00 | 0x04 | String | File identifier: String "REFF" for BREFF or "REFT" for BREFT in ASCII. |
0x04 | 0x02 | UInt16 | Byte order mark (BOM): The value is always 0xFEFF. If value 0xFFFE is read, then the false endian is used. Mario Kart Wii uses nearly always big endian (bytes 0xFE,0xFF). |
0x06 | 0x02 | UInt16 | Version number of file format. Value 9 for all files in MKW. |
0x08 | 0x04 | UInt32 | Length of the file in bytes. |
0x0C | 0x02 | UInt16 | Offset to root section relative to start (usually 0x10). |
0x0E | 0x02 | UInt16 | Number of sections. 1 for all files in MKW. |
0x10 | End of file header |
Section Header
All Mario Kart Wii files have only one section. Therefore it is nor clear how multiple sections are combined.
Offset | Size | Type | Description |
---|---|---|---|
0x00 | 0x04 | String | File identifier: String REFF for BREFF or REFT for BREFT in ASCII. |
0x04 | 0x04 | UInt32 | Length of section in bytes. The magic and this value are not included. |
0x08 | 0x04 | UInt32 | O = Offset of subfile list header. The offset is relative to this value. |
0x0C | 0x04 | UInt32 | Unknown. Value 0 for all files in MKW. |
0x10 | 0x04 | UInt32 | Unknown. Value 0 for all files in MKW. |
0x14 | 0x02 | UInt16 | L = Length of name including the terminating NULL byte. |
0x16 | 0x02 | UInt16 | Unknown. Value 0 for all files in MKW. |
0x18 | L | String | ASCII name of object, terminated with a NULL byte. |
0x18 + L | O - L - 0x10 | Byte[] | Padding, mostly NULL bytes. |
0x08 + O | End of section header |
Subfile List
Offset | Size | Type | Description |
---|---|---|---|
0x00 | 0x04 | UInt32 | Size of subfile list and all subfile items. |
0x04 | 0x02 | UInt16 | Number of subfiles (= number of subfile headers). |
0x06 | 0x02 | UInt16 | Unknown. |
0x08 | Start of first subfile item |
Subfile Item
The list of subfile items begins direct behind the subfile list (see above). The length of a record depends on the name length and is not aligned. If accessing one of the numeric values (namelength, offset or size), it is important to read and write byte by byte, because some CPUs do not support accessing UInt16/UInt32 values on not aligned addresses.
Offset | Size | Type | Description |
---|---|---|---|
0x00 | 0x02 | UInt16 | L = Length of name including the terminating NULL byte. |
0x02 | L | String | ASCII name of object, terminated with a NULL byte. |
0x02 + L | 0x04 | UInt32 | Offset of data, relative to the beginning of the subfile list. |
0x06 + L | 0x04 | UInt32 | Size of data in bytes. Add 0x20 for BREFT files. |
0x0A + L | Start of next subfile item or END OF LIST (not aligned) |
Content
The Subfile Item List points to the specific data for BREFF or BREFT. Continue reading BREFF (File Format) or BREFT (File Format).
Example Listings
The first example listing shows the content of the steam object of Toad's Factory:
* Files of BREFF:rk_steam.breff idx offset/hex size/hex size/dec magic vers file or directory ------------------------------------------------------------------------------- 0: 0.. 10 10 16 REFF - header.bin 1: 10.. 34 24 36 REFF - root.bin 2: 34.. ac 78 120 ...x - file-list.bin 3: 0< - 0> - - - files/ 4: ac.. 3ec 340 832 .... - files/rk_steam 5: 3ec.. 784 398 920 .... - files/rk_steamBAK 6: 784.. ac4 340 832 .... - files/rk_steam0 7: ac4.. e64 3a0 928 .... - files/rk_steam_Copy_1 8: e64.. 11a4 340 832 .... - files/rk_steam0_Copy * Files of BREFT:rk_steam.breft idx offset/hex size/hex size/dec magic vers file or directory ------------------------------------------------------------------------------- 0: 0.. 10 10 16 REFT - header.bin 1: 10.. 60 50 80 REFT - root.bin 2: 60.. a0 40 64 ...@ - file-list.bin 3: 0< - 0> - - - files/ 4: a0.. 8c0 820 2080 .... - files/rk_smoke2 5: 8c0.. 10e0 820 2080 .... - files/rk_steam
The second example listing shows the content of the flame pole object of different Bowser Castle tracks:
* Files of BREFF:rk_flamePole.breff idx offset/hex size/hex size/dec magic vers file or directory ------------------------------------------------------------------------------- 0: 0.. 10 10 16 REFF - header.bin 1: 10.. 38 28 40 REFF - root.bin 2: 38.. dc a4 164 .... - file-list.bin 3: 0< - 0> - - - files/ 4: dc.. 920 844 2116 .... - files/rk_flamePole 5: 920.. 1058 738 1848 .... - files/rk_flamePole0 6: 1058.. 16b8 660 1632 .... - files/rk_flamePoleS 7: 16b8.. 1d20 668 1640 .... - files/rk_flamePoleFoot 8: 1d20.. 223c 51c 1308 .... - files/rk_flamePoleFoot0 9: 223c.. 2758 51c 1308 .... - files/rk_flamePoleFootS * Files of BREFT:rk_flamePole.breft idx offset/hex size/hex size/dec magic vers file or directory ------------------------------------------------------------------------------- 0: 0.. 10 10 16 REFT - header.bin 1: 10.. 60 50 80 REFT - root.bin 2: 60.. a0 40 64 ...@ - file-list.bin 3: 0< - 0> - - - files/ 4: a0.. 10c0 1020 4128 .... - files/yoganTest 5: 10c0.. 30e0 2020 8224 .... - files/yogan4