Blog Index
< slashie.net

I’m Santiago Zapata, better known online as slashie, a Software Engineer and Independent Game Developer and from Medellín, Colombia.

You are in the devlog, a chronological collection of updates on my projects, alongside articles about software and game development. Subscribe to get these directly into your inbox.

Yolaru

Published by

slash

on

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 responses to “Yolaru”

  1. Vehek Avatar
    Vehek

    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.

    Reply
    1. Vehek Avatar
      Vehek

      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.

      Reply
      1. slashgravatar Avatar
        slashgravatar

        Thank you Vehek, and forgive me for going slowly into each detail, I just find these things amusing 🙂 I’ll continue delving into this tonight

Leave a Reply

Previous Post
Next Post

Discover more from Slashie's Gamedev Adventures

Subscribe now to keep reading and get access to the full archive.

Continue reading