Just decided to post some notes I made for a few games for those interested.
First game I'm going to cover is Langrisser: DE(mostly because d-boy asked about it a while back).
BG.DAT holds all the beautiful background images that you see throughout the game. It comprises of both 8BPP tiled images as well as linear 15BPP images. In order to figure out which is which, you basically have to jump to the proper position of the file(using the pointer table at the begining) and grab the first word. If it's 0x0010, it's 8BPP, etc. Then basically go from there.
IMG.DAT holds what appears to be most of the other graphics. But here's the most interesting part: It's compressed. I'm not exactly sure what kind of compression it's using(almost appears to be some kind of RLE) , but I can definitely confirm that it -is- compression after looking through an asm dump.
MAP.DAT and FACE.DAT also appear to use the same thing.
FONT.DAT is a 1BPP byte-swapped 16x16 font.
And SCEN.DAT is basically the scenario text(stored in shift-jis format) as well as other scenario-based data.
Lastly I'm going explain a wee bit about Grandia and a discovery a made this week. First of all, the 8x8 text is in ASCII format(so you can basically cut and paste from the psx version if one so desired). Of course there's probably pointers to be adjusted, but I don't feel like covering them. The font is 4BPP and can be found in BIN\FDATA.BIN
The 16x16 text is a little more trickier. It uses a byte-word scheme similiar to Langrisser 1&2(for psx). Basically If the first byte is >= 0x20 and not equal to 0x00, 0x01, or 0x02 then it's 1 byte. Otherwise it appears to be treated as a word. Except for about 5 kanji, the single byte characters consists of just numbers, regular alphabet, hiragana, katakana, and symbols(in that order). Now about the font. The 16x16 font is stored in FDATA.BIN(starting at 0x00000A00) along with the 8x8 font. The evil part about this font however is that it's compressed.
I haven't completely figured out the compression, but I'll explain what I know. Using a pointer table(located at the begining - 0x00000A00) you jump that many bytes after 0x00000A00 to the start of the compressed character(so for instance for the second character you jump 0xBC4 bytes to 0x000015C4). Then you read off 4 bytes from this address. The 4 bytes are basically a type of table. Each bit represents whether another byte needs be grabbed to decode the next 8 pixels of the current character. If the bit is set, you grab the next byte. If not, it appears you have to reuse the last one picked up(unless there was none, in which case the pixels are blank). That's about as far as I've gotten. Oh, the data is also decoded the left 8x16 side first, then the right 8x16.
That should be about it. If there's any questions, just ask.
Cyber Warrior X
First game I'm going to cover is Langrisser: DE(mostly because d-boy asked about it a while back).
BG.DAT holds all the beautiful background images that you see throughout the game. It comprises of both 8BPP tiled images as well as linear 15BPP images. In order to figure out which is which, you basically have to jump to the proper position of the file(using the pointer table at the begining) and grab the first word. If it's 0x0010, it's 8BPP, etc. Then basically go from there.
IMG.DAT holds what appears to be most of the other graphics. But here's the most interesting part: It's compressed. I'm not exactly sure what kind of compression it's using(almost appears to be some kind of RLE) , but I can definitely confirm that it -is- compression after looking through an asm dump.
MAP.DAT and FACE.DAT also appear to use the same thing.
FONT.DAT is a 1BPP byte-swapped 16x16 font.
And SCEN.DAT is basically the scenario text(stored in shift-jis format) as well as other scenario-based data.
Lastly I'm going explain a wee bit about Grandia and a discovery a made this week. First of all, the 8x8 text is in ASCII format(so you can basically cut and paste from the psx version if one so desired). Of course there's probably pointers to be adjusted, but I don't feel like covering them. The font is 4BPP and can be found in BIN\FDATA.BIN
The 16x16 text is a little more trickier. It uses a byte-word scheme similiar to Langrisser 1&2(for psx). Basically If the first byte is >= 0x20 and not equal to 0x00, 0x01, or 0x02 then it's 1 byte. Otherwise it appears to be treated as a word. Except for about 5 kanji, the single byte characters consists of just numbers, regular alphabet, hiragana, katakana, and symbols(in that order). Now about the font. The 16x16 font is stored in FDATA.BIN(starting at 0x00000A00) along with the 8x8 font. The evil part about this font however is that it's compressed.
I haven't completely figured out the compression, but I'll explain what I know. Using a pointer table(located at the begining - 0x00000A00) you jump that many bytes after 0x00000A00 to the start of the compressed character(so for instance for the second character you jump 0xBC4 bytes to 0x000015C4). Then you read off 4 bytes from this address. The 4 bytes are basically a type of table. Each bit represents whether another byte needs be grabbed to decode the next 8 pixels of the current character. If the bit is set, you grab the next byte. If not, it appears you have to reuse the last one picked up(unless there was none, in which case the pixels are blank). That's about as far as I've gotten. Oh, the data is also decoded the left 8x16 side first, then the right 8x16.
That should be about it. If there's any questions, just ask.
Cyber Warrior X
