More R-Type

Right so I went and did some work on the P6T format. It goes like this.

0x00 - P6T*0002
0x08 - word width
0x0c - word height
0c10 - offset to palette data
0x14 - offset to pixel data

Palette data is 32-bit, looks like ARGB and contains up to 1024 colors. Pixel data is 8-bit and I'm not sure how the pixels are associated with the CLUT. With a little bit of fudging around you can get stuff like the above picture. Presumably a background image and the in-game onscreen display.

I also did a bunch of work on the IMD format(just some notes):

almost the whole thing seems to be qword aligned

0x00 header,
'IMD '
0x05 file version always 0002
0x0c number of offsets
0x30 begin offsets, first offset points to bounding box


~0x40
0x40 bounding box
~0xbf

0xc0 followed by dword number of meshes+1
offsets to data offset tables
~ ends with FFFFFFFF

vertex data is 3 floats followed by 803f or 80bf or 01000000
3f/bf appear to be flags, difference is only one bit
10000000:80
00111111:3F
10111111:BF
there are 6 verts between each BF, there are always a multiple of 3 verts from
01000000 to next when present

different pieces of the model are sperated by a small unidentified data section

there dont appear to be any vert order tables so I'll assume that these are
linear vert data describing primitives

each mesh gets a 68h byte header containing up to 3 verts and other unknown data.

mesh data offset tables appear to reuse data. number of offset tables may not
match number of total mesh offsets used nor will the number of mesh offsets
necessarily match the number of actual meshes. maybe there is both a translation
and a rotation in the mesh offset and some meshes are simply reused in this
fashion.

it appears we must traverse the mesh offset tables until we hit the beginning
offset of the mesh offsets. load the mesh offsets as we go and load them into a
table. check meshes upon request so as to not duplicate.

meshes also appear to contain multiple data. maybe this is how the mesh offset
tables keep track of what mesh(mesh count and mesh offset table count match?
further, do the number of self contained meshes match the number of offsets used
in each mesh offset table? are there opcodes in the mesh offset tables?)

R-Type Final

So I've been taking a break from Metal Gear Solid before I do some in depth reverse engineering to finalize the KMD format.

In the meantime I started work on R-Type Final and Wipeout Fusion. From R-Type I have all of the data ripped and Wipeout I am in the process of writing the ripper still. Some minor issues in the Wipeout archive format that I haven't worked out yet.

The data in R Type is something like this. Initially everything is stored in a few pairs of DAT/FAT files. Inside these DAT's are a bunch of P6T files, presumably textures or other still images, some more DAT files, and the audio for the game stored as BD/HQ/SQ files(presumably samples and sequences). There is another DAT/FAT that I haven't extracted but appears to contain MPEG2 streams and some other FMV related odds and ends.

The stored DAT files are the same format as the DAT/FAT pairs except the FAT prepends the DAT instead of existing in a separate file. These sub-DAT's appear to contain all the mesh(IMD) and texture(P6T) files for the entire game.

It appears that the enemies, player, maps and all other 3D models share the IMD format and all images are P6T format with the exception of a few that have DAT extensions and don't share any of the charactersistics of DAT/FAT or P6T.

After a brief examination of the code, P6T files look like they are probably compressed. After some other investigation I am assuming that IMD's are also in a compressed format but I have not yet verified.

First post

This blog is for me to talk about hacking and exploiting console and PC video games for two of my hobbies. Data extraction and interpretation for papercrafting and game modification. Currently my main project is Metal Gear Solid Integral for PC.

I discovered right away that the game stores almost all of its data in files with a .MGZ extension. These files are actually standard ZIP files, rename and extract.

Inside the STAGE.MGZ file are many files relating to NPC and player mesh data, textures, stages and other supporting data. Mesh and texture data are stored in .DAR files, which I'll say stands for Data ARchive.

The DAR format is simple, starting with a short int describing the number of files contained in it followed by the first filename. All data is DWORD aligned.
I am able to extract all the data from the DAR format and am working on a repacker for modified game data.

DAR files contain a few different file formats: PCX, KMD, and OAR are what I'm most interested in right now. PCX format is used for the games low-res textures. They have power of two width and height, 8-bit color and do not appear to be compressed. KMD format stores the mesh data. NPC, player and stage data are all stored in the same KMD structure. OAR data looks like it is probably animation and/or bone data and is always associated with a KMD file. For example SNAKE.KMD has a corresponding SNAKE.OAR file. KMD data is not compressed and I have not yet looked into OAR files in depth.

I'll be posting my current ripping/packing tools later and will be updating with a GUI in the future.