Identify remaining unknown file formats

[descawed]

Most files in the game have been decoded at this point, but there are some that I still haven't figured out:

• MOT.CDB - I'm almost certain these are 3D animations for characters, but I haven't decoded the format yet.
• DISPLAY.CDB[4] in the Japanese version and [22] in the US version - this is the largest file in the archive by far. The header looks like a TIM DB but with the most significant byte of the size used as some kind of flag (observed values are 0, 2, and 3). I have no idea what the first three entries are; they're small (< 100 bytes each) and look like they could maybe be series of 16-bit integers. The remaining entries look like compressed data but they don't match the format of the compressed TIMs found elsewhere in the game. They all seem to start with b'\x88\x40'.
• DISPLAY.CDB[3] and MENU.CDB[55] in the US version - look like headerless TIMs. In a hex editor, the DISPLAY one appears to be a picture of the PlayStation controller (so maybe used on the options menu), but I don't see a CLUT to know what the correct pixel values are. Should check the game code to see if it ever loads this and where it gets the CLUT from.
• CHK.CDB - Japanese version only. Contains a single entry. I think the game uses this to tell which disc it's on (DISC.INF seems to serve a similar purpose in other versions), but there's a lot of extra bytes here for that to be all it does.
• GE.CDB - Western versions only. Contains a single entry. Another headerless TIM? I don't believe this file is actually used.

[descawed]

I misunderstood what CHK.CDB is - it actually contains two files which are just simple strings. The first is "GALERIANS DISCn" where n is the disc number. The second is "GENTEI". I was confused by the presence of a bunch of garbage data, including generic debug strings, in the first sector of the database after the end of the header.

The file in GE.CDB, on the other hand, is actually a Japanese string database of debug strings that don't appear in the Japanese version of the game. I had to copy it into a Japan-version project to be able to view them.

[descawed]

I've done a little work on MOT.CDB. The files in this archive appear to be archives themselves which contain all animations for a specific character. Character animation indexes appear to be standardized; there can be gaps (zeroes) at certain indexes in the header if a particular character doesn't have that animation. Known indexes are:

• 0: breathing/standing
• 2: shorted breathing/standing
• 3: walking
• 6: walking backwards
• 9: running
• 19: consuming item

Indexes in MOT.CDB of particular characters' animation archives:

• Lilia: 49
• Rion: 63

The format of the animations themselves is still not understood.

[descawed]

DISPLAY.CDB[3] and MENU.CDB[55] are menu files containing images and layout information for the option menu and the inventory, respectively. By extracting some positioning information from the exe, the option menu can be reproduced very close to how it appears in game. The inventory menu seems much more hard-coded, but it's still possible to extract icons and labels. Interestingly, the rotating G A L E R I A N S text that appears on loading screens is stored in the option menu file. Also, the Yes/No prompt in the option menu file seems to be used for all Yes/No prompts in the game.

There are still a few fields in these files whose purpose I'm not completely sure about, but I feel they've been decoded well enough to check them off the list.

[descawed]

Animations have been decoded. They consist of a series of frames each consisting of a model-level translation, rotations for the first 15 segments of the model, and a flag word. There are still a couple remaining issues (see issue #6 ), but I think they're related to hard-coded game logic and not the format of the animation files, so I'm checking MOT.CDB off the list.

[descawed]

I've looked into the last undecoded file in DISPLAY.CDB a bit more. It contains a total of 66 entries. The size values in the header are strange because they leave gaps between entries, and the data doesn't look like it stops at the size boundaries. I decided to split the file apart ignoring the sizes and treating each entry as if it spanned from its offset to the next offset.

For the first three entries, which are different from all the others, the first two are very similar, differing only by a few bits in a handful of bytes. The third one is a bit shorter and more different.

The rest of the entries all start with the 88 40 magic number and range in size from 1-26 KB. There seems to be a header of some sort including the magic number; the first 8 bytes seem formulaic in all the files I've looked at. Some files also have similarly structured values through the first ~18 bytes. After that it's just dense binary data with no structure that I've been able to discern, so it's possibly compressed. Given that all the other files in DISPLAY.CDB are images (at least in the Japanese version), I would expect these to be images as well.

Unfortunately, I wasn't able to find anywhere in the game that loads this file. If the game does use it, it's either loaded in an unusual way or loaded by a module.

[descawed]

By chance, I discovered that module 128 (in the US version) loads this last file. It turns out it's graphics for the credits screen (and I believe module 128 runs the credits screen). The images are compressed using some compression scheme that identifies common substrings in the data. With that, all files in the US and Japanese retail versions of the game have been decoded.