PAK files for SRW GC

* The following notes have been taken after opening PAK files from the iso of Super Robot Wars GC with a free hex editor and some careful observation. There's no warranty of any of this being correct.

Let's start opening map.pak:

The map.pak file is sort of special, because the header contains an index to several PAK files put together in it. Think of it as a folder. Not every pak file starts with this, thankfully, But I'll explain how this special type of PAK works first.

First word is the length of the index (00 00 00 b9) - indicates there's 185 "pointers" to the .pak files inside.

Every "pointer" starts with 23 filler bytes (all set to '20'), followed by 9 bytes with the name of the file it's pointing at (mXXXX.pak). That is, 32 bytes for the name of file we're pointing at. Then, 4 bytes with the offset of said file (the exact address) and finally other 4 bytes with the length of the file.

Once you jump to the offset of a file, it follows the same rules as the other 'normal' pak files.

There's other PAK files that start with the same kind of index, namely: bmes.pak and bpilot.pak.

--------------------------------------

What's inside a PAK file:

Surprise, PAK files contain MORE pak files.

The first word indicates the number of pak files inside. For example, dmgparts.pak starts with '08 00 00 00' (that's 8 paks) and both font.pak and beff_sp_list.pak start with '01 00 00 00' (that's 1 pak)

The second word indicates the length of the filename.

* Thanks to Zoinkity for correcting me on this.

After that, comes the name of the PAK file inside the pak and its contents. All files inside a PAK start with the type. It doesn't seem to be more than two levels of "subfolders". Why some files have an index and others don't is unclear.

----------------------------------------------------

Let's open r001.pak and see what it has inside.

The first 4 bytes indicate there's only 1 file inside this PAK.

The next 4 bytes tells us the length of the filename (including the ending delimiter), which is 9.

The following 8 bytes are the name of the file itself (r0001.pak). It's followed by a '5f' byte that supposedly indicates the end of the name, which most probably has variable length. All rXXXX.pak files have the same name length, so this part is very similar for all of them.

The next 3 bytes ('da 4b 07') are equal to the size of the file minus 25, but reversed (it would be '74bda', which amounts to 478170 bytes). That would mean the header is 25 bytes long. These most probably indicate the size of the compressed data, and seems to be variable (could be more or less than 3 bytes in other files).

The next 4 bytes are most probably the size of the uncompressed data.

And the supposedly last byte of the header is always 0. Actually bytes 24 to 27 are always 0, so probably the real text starts at 28?

Anyway, the rest of data seems to be compressed. Or maybe my hex editor simply doesn't recognize the Japanese characters. There's a chance this is LZO compression.

* Again, thanks to Zoinkity for correcting me on this.

---------------------------------------------------------

Now, there are some PAK files that don't contain other paks.

Open bmes.pak and you'll find an index like the one in map.pak, but pointing at 4 sp files (/sprite/pwaku01.sp, /sprite/pwaku02.sp, /sprite/pnz01.sp and /sprite/pnz02.sp). These files are for graphics.

An SP file contains these sections:

- Palettes: Comes with a header and the palette data itself. You can get several palettes.

 * Header: Starts with PAL_ and takes 128 bytes. The 4 bytes right after PAL_ seems to indicate the size of the palette (read it in reverse, '80 04' would be '480' in hex). A few bytes after that, you can see the name of the file followed by PALxx (like PAL00). I'm not exactly sure about the next 4 bytes after PALxx, but the first 2 *might* be the bit-depth and the last 2 of those seem to indicate the number of palettes.

 * Palette(s): Colour data. There doesn't seem to be any separation between these palettes (it should all be in the header).

- Textures: Same deal as with the palettes. You can get several textures in the same file (layers?). Check pnz02.sp inside bmes.pak, it has 4 textures.

 * Header: Starts with TEX_ and takes 128 bytes. The 4 bytes right after TEX_ seems to indicate the size of the texture (read it in reverse, '80 08' would be '880' in hex). A few bytes after that, you can see the name of the file (like pwaku01.sp) followed by TEXxx (like TEX00). The 4 bytes right after TEXxx indicate the dimensions of the texture (for example '00 40 00 40' is 64x64)

 * Texture: The image data. Can be copied into a BMP format. You'll get all sorts of weird colours, though (since you're not using the palettes). Yes, you can edit this.

- CEL section: Probably information for screen positioning of the texture? Starts with CEL_, and you only get one of these for sp file.

- END: Not sure if it's the end of the file or the end of the CEL, but there's always 16 bytes at the end of each SP file that are always the same: END_ ('45 4e 44 5f') followed by zeroes.

-------------------------------------------------

Now, if you want to start pulling hair from your head, open bpilot.pak, which most probably contains pilot data. The index is enormous, listing 553 pilots. Each one has at least one .hed file, one .bin file and one .sp file.

I have no idea about the HED files (which I'm assuming are headers for the pilots), but all BIN files in there start with ATMB, and don't ask me what that is.