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).
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
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.
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."
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 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?
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.)
Yup all 1 mipmap textures are broken. The 8x8 data blocks look correct but the arrangement of them doesn't seem proper. I hope it's the same fix as you mentioned. It would be nice to keep playing today!
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.