The compression scheme in Mario Party is amazingly simple, like a bastardized version of the three big N64 ones, but I can't seem to figure out how the final piece of this puzzle works. My examples will be from the Japanese ROM.
This file at 0x31BDCC, and all of the others pointed to from various tables, has a header consisting of two words:
00000558 00000001
The first word is the decompressed size of the file. The second word is a flag that is either set to zero or one. 00000001 means that the file is compressed.
Since this file is compressed, it's laid out the following way:
Everything immediately past the 8-byte header will first be a "control byte." If it's set to 0xFF, it means that there will be 8 bytes of raw data immediately after that can be copied to the output file. This happens twice in a row right after the header in the example file:
[FF] 46 4F 52 4D 00 00 05 50
[FF] 48 42 49 4E 4D 4F 44 45
But if it's anything less than 0xFF, you have to look at the binary representation of it, which is the case for the next "control byte" in this file:
[AE] (10101110)
The bits are read from right-to-left and dictate the format of the data immediately after the control byte. If a bit is set to 0, there will be a pair of bytes that tell how to manipulate the output file for repeating values. If a bit is set to 1, it represents a single byte of raw data for the output file.
So, 10101110 is read right-to-left. It means that the data after the control byte should be grouped like so:
[bB C0] 20 00 02 [b9 C2] 01 [b6 C5] 16
0 1 1 1 0 1 0 1
(Immediately after this data will be another control byte, and this cycle repeats until the end of the file.)
Enclosed in brackets are the byte pairs for manipulating the output file. Outside of brackets are the bytes of raw data. So, obviously the bytes of raw data get copied in order as they appear, but I'm stumped on exactly how the byte pairs in brackets should be interpreted. That's what I need help with. Anybody have an idea?
Something to keep in mind: I've seen another file that's already decompressed in the ROM that contains data that can be seen in this compressed file, so I have reason to believe that the next 4 bytes in the output file should be 00 00 00 20. (20 from the raw data bytes above.) So the byte pair BB C0 should produce three 00 bytes before the 20 byte in the output file. Also, I think that the file header should be copied over to the output file.
Question
Twili
The compression scheme in Mario Party is amazingly simple, like a bastardized version of the three big N64 ones, but I can't seem to figure out how the final piece of this puzzle works. My examples will be from the Japanese ROM.
This file at 0x31BDCC, and all of the others pointed to from various tables, has a header consisting of two words:
00000558 00000001
The first word is the decompressed size of the file. The second word is a flag that is either set to zero or one. 00000001 means that the file is compressed.
Since this file is compressed, it's laid out the following way:
Everything immediately past the 8-byte header will first be a "control byte." If it's set to 0xFF, it means that there will be 8 bytes of raw data immediately after that can be copied to the output file. This happens twice in a row right after the header in the example file:
[FF] 46 4F 52 4D 00 00 05 50
[FF] 48 42 49 4E 4D 4F 44 45
But if it's anything less than 0xFF, you have to look at the binary representation of it, which is the case for the next "control byte" in this file:
[AE] (10101110)
The bits are read from right-to-left and dictate the format of the data immediately after the control byte. If a bit is set to 0, there will be a pair of bytes that tell how to manipulate the output file for repeating values. If a bit is set to 1, it represents a single byte of raw data for the output file.
So, 10101110 is read right-to-left. It means that the data after the control byte should be grouped like so:
[bB C0] 20 00 02 [b9 C2] 01 [b6 C5] 16
0 1 1 1 0 1 0 1
(Immediately after this data will be another control byte, and this cycle repeats until the end of the file.)
Enclosed in brackets are the byte pairs for manipulating the output file. Outside of brackets are the bytes of raw data. So, obviously the bytes of raw data get copied in order as they appear, but I'm stumped on exactly how the byte pairs in brackets should be interpreted. That's what I need help with. Anybody have an idea?
Something to keep in mind: I've seen another file that's already decompressed in the ROM that contains data that can be seen in this compressed file, so I have reason to believe that the next 4 bytes in the output file should be 00 00 00 20. (20 from the raw data bytes above.) So the byte pair BB C0 should produce three 00 bytes before the 20 byte in the output file. Also, I think that the file header should be copied over to the output file.
Link to comment
Share on other sites
0 answers to this question
Recommended Posts