Back when trying relative search, I marked the kana characters with roman letters to find sequences, since characters are 4 sprites big, I began the first sequence changing the first tile of the character, and the next sequence changing the second tile and so on.

When the first dialog is shown, the following tiles are loaded into VRAM (at offset 21504):

2U 1D 1H (Kanji) (Kanji) 4G 4I 4M 2z 2f 4R

(2U is the Kana which has an “U” on its second sprite)

Following Vehek’s input, I’m hoping to find a relative sequence for this somewhere in the ROM; what I’m thinking now is that there should be some sort of table which indicates what sprites to load for each dialog, and another one which says what actual sprites to use based on the ones that were loaded already.

If this is true and I manage to find both, I’ll be able to make a program to extract the script.


3 thoughts on “Yolaru

  1. A relsearch tool would have to look in intervals of 3. That’s how far apart the values of consecutive characters are in the loading-table. As I mentioned at RHDN, there’s a big pointer table pointing to every font character. Rather than using a pointer index, it uses offsets into this pointer table. 24-bit pointers, therefore 3 bytes apart each.

    Here’s something about that pointer table. The pointer table at 0x110100 for the font characters has blank, invalid pointers. These blank spaces correspond to invalid SJIS combinations. Makes it easy to convert the number directly into a SJIS character (except for where the character is not the same in the kana/roman section). Well, the gap between the kana/roman section and the kanji section isn’t large enough to correspond to all the SJIS characters between them, but this works well enough for the two sections individually.

    For Intanya:
    The table for selecting the font characters to load is at 0x1095FE. The data for his introductory line is at 0x160D4E. But this seems to be part of scripting data for him, so I don’t think a complete dump can be done just yet.

    1. I’m amending that last statement a bit. Actually, the data could be said to start a byte earlier at 0x160D4D. The previous offset was where the first character-usage value for that dialog was. I thought the byte before was some text block display command and the text data alternated between character-usage values and some repeating value. It turns out the byte before served the same purpose as the repeating value. It looks like the text-displaying command only adds one text character at a time; the text-displaying command appears over and over for each individual character.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s