Metroid Prime .pak format?
- Thread starter Elpenguino
- Start date
thakis
New member
Hmm, that won't be easy.
You could compare compressed and uncompressed files of the same file type (for example, "ELSC" in Metroid1). You know that the compressed file has a fixed header, so try to make up a decompression scheme that yields this known header. The compression method could even be some public compression format (zlib, ...).
Another approach would be to disassemble the .dol (dol is a gamecube .exe), step through it in an emulator (dolwin is open source, I don't know if dolphin comes with a debugger) until you find the piece of code that does the decompression and copy it. (yagcd has documentation on the .dol file format).
Good luck ;-)
You could compare compressed and uncompressed files of the same file type (for example, "ELSC" in Metroid1). You know that the compressed file has a fixed header, so try to make up a decompression scheme that yields this known header. The compression method could even be some public compression format (zlib, ...).
Another approach would be to disassemble the .dol (dol is a gamecube .exe), step through it in an emulator (dolwin is open source, I don't know if dolphin comes with a debugger) until you find the piece of code that does the decompression and copy it. (yagcd has documentation on the .dol file format).
Good luck ;-)
BlueFalcon7
New member
i read somewhere recently about file extensions that windows uses a 3 letter file extension and mac uses a 4 letter file extensions (with exceptions like .dmg and .mp3) so i wonder if metroid prime was made with a mac and then archived for purposes of reducing header clutter, and so it can go into an iso and also for file type help, theres filext.com
thakis
New member
Metroid itself doesn't use any file extensions, they are added by mpakdump. And it's not true that windows uses 3 letter extensions - back in the DOS days, only three letters were supported. Nowadays, three letters are the most common, but there are four or more letters as well (.html, .class, .manifest, ...). And .png files have the extension .png on Macs as well.
BlueFalcon7
New member
thats sort of what i meant, i was not clear that windows also uses 4 letters but i read in the index of the windows XP help and support center and it says "In the Macintosh environment, a four-character sequence that identifies the type of a Macintosh file. The Macintosh Finder uses the file type and file creator to determine the appropriate desktop icon for that file."
thakis
New member
Hey,
I had a some spare time today, and I managed to write a decompressor for the compressed files. It was rather easy, the files are simply compressed with zlib. I attached it to my post which has the other two programs (mpakdump, mtexdump) attached as well (8th post in this thread).
The .CMDL format doesn't look to hard to reverse once it's uncompressed, so give it a shot...if you are interested in computer game file formats, this is a really good opportunity to get started :flowers:
EDIT: if you see a file which has 0x78da near the beginning, it's pretty certainly a zlib file (with maximal compression).
I had a some spare time today, and I managed to write a decompressor for the compressed files. It was rather easy, the files are simply compressed with zlib. I attached it to my post which has the other two programs (mpakdump, mtexdump) attached as well (8th post in this thread).
The .CMDL format doesn't look to hard to reverse once it's uncompressed, so give it a shot...if you are interested in computer game file formats, this is a really good opportunity to get started :flowers:
EDIT: if you see a file which has 0x78da near the beginning, it's pretty certainly a zlib file (with maximal compression).
Last edited:
OP
Elpenguino
New member
- Thread Starter
- #28
...and there was much rejoicing. good work, thakis.
I don't have any MP1 files for testing but I do have MP2. The mpakdump tool still works. But the 1_***.txtr files are no longer compressed the same way it seems. The first 4 bytes are still the decompression size but it's like there's no other header info. Any ideas? Or a single MP1 1_***.txtr file for comparision that I could use to see the differences?
OP
Elpenguino
New member
- Thread Starter
- #35
mdecomp works with metroid prime, but not metroid prime 2...
SarahHarp
New member
That's correct. They seem to have used a differnt decompression algorithm. However I'm mainly concerned with the first MP so you'll just have to wait till I make it there : ) (Even if you did uncompress mp2 stuff, I'm dont think there's much you can do with it, as everything (assuming cmdl's are differnt aswell) is in a differnt format (think of the TXTRs... ) You could always try to decompress it yourself ; )
Oh and no, the sound effect area hasn't been touched. I looked into the matter for a quick bit, and I noticed they are basicly arranged by type (all Thardus sounds are in one file, all Flaahgra sounds are in another, etc).. I'm pretty sure sound files use the AGSC file type.)
Oh and no, the sound effect area hasn't been touched. I looked into the matter for a quick bit, and I noticed they are basicly arranged by type (all Thardus sounds are in one file, all Flaahgra sounds are in another, etc).. I'm pretty sure sound files use the AGSC file type.)
Last edited:
Hey,
So I started playing with MP1 data with the tools in this thread. Cool stuff. I'm mostly interested in the textures right now.
mpackdump -> mdecomp 1_* -> mtexdump -> btidump
I've found that all the textures with no mipmaps come out incorrectly swizzled. The colors look correct but the 8x8 tile arrangement is not.
Example.
Incorrect
Metroid2.pak -> 01_1a40e64a.TXTR is 256x256 with 1 MipMap, 32,780 bytes
Correct
Metroid2.pak -> 01_1a4a2d1a.TXTR is 256x256 with 6 MipMaps, 43,692 bytes
I've played with the code and I'm not sure at which step is the problem. My *guess* is it's the bti->dds step since there's some liberties taken assuming mipmips and flags.
Thakis? Have a chance to have a look?
Cheers
So I started playing with MP1 data with the tools in this thread. Cool stuff. I'm mostly interested in the textures right now.
mpackdump -> mdecomp 1_* -> mtexdump -> btidump
I've found that all the textures with no mipmaps come out incorrectly swizzled. The colors look correct but the 8x8 tile arrangement is not.
Example.
Incorrect
Metroid2.pak -> 01_1a40e64a.TXTR is 256x256 with 1 MipMap, 32,780 bytes
Correct
Metroid2.pak -> 01_1a4a2d1a.TXTR is 256x256 with 6 MipMaps, 43,692 bytes
I've played with the code and I'm not sure at which step is the problem. My *guess* is it's the bti->dds step since there's some liberties taken assuming mipmips and flags.
Thakis? Have a chance to have a look?
Cheers
thakis
New member
Some textures are in a different format than dxt1. I added support for all formats I found to mtexdump, I'm going to post an updated version soon. I found a small bug in btidump during the process as well. I am now able to convert _all_ .TXTR files found in mp1 to dds without a crash 
dxt1 compressed files without mipmaps still don't work, though.
edit: if someone cares, here's a table of mp1's image formats:
//0 - i4
//1 - i8
//2 - i4a4
//3 - i8a8
//4 - idx4
//5 - idx8
//(there's no file with format 6)
//7 - r5g6b5
//8 - rgb5a3
//9 - r8g8b8a8
//10 - dxt1
Format 4 doesn't completely work atm, though (the rest works). Also, it seems as if all mp1 textures are stored upside down.
dxt1 compressed files without mipmaps still don't work, though.
edit: if someone cares, here's a table of mp1's image formats:
//0 - i4
//1 - i8
//2 - i4a4
//3 - i8a8
//4 - idx4
//5 - idx8
//(there's no file with format 6)
//7 - r5g6b5
//8 - rgb5a3
//9 - r8g8b8a8
//10 - dxt1
Format 4 doesn't completely work atm, though (the rest works). Also, it seems as if all mp1 textures are stored upside down.