The only way relative searching with kana is going to work is if your game happens to use the exact same kana ordering as the utility (and while there seems to be a standard order when I see kana tables in books and such, it certainly isn't used very often in games) or the utility allows you to use a custom kana table (and I'm not sure such a utility exists.) You can, however, use the relative values, as explained in my document, to do a Value Scan Relative search in Translhextion.


You can't find the values, only the relative values. However, if you can find the values of an English word using the first couple of lines of the font, the values will continue in order from there. (For instance, if your relative search determined that the value of A was 0A then the value of ン is going to be BC under normal conditions.) Also, note that if you are doing a relative search for English words using that font, you won't successfully find any words that contain a W, X, Y or Z in a normal relative searcher because  of the 0-10 and the box between the V and the W. Relative searchers that allow you to simply type an English word will assume the the relative difference between V and W is +1, but in this font it is +13. So to find a word using W-Z, you would have to use the aforementioned Value Scan Relative search which is currently only available in Translhextion. (I'm not entirely clear on what you're asking about in terms of anomalies, though.)

Don't get too hung up on control codes. I'm not sure that I've seen a game where a control code has a value in the middle of a font table value range, so it shouldn't matter as far as figuring out the values for your table. Basically, once you've built the initial table, you'll have to poke around in the ROM and see what you can find. Once you've found some text, you'll likely see a few bytes before, after and/or in between the lines. These will be your control codes and you'll just have to experiment with them to see what they do.


Now that I've went back and read what I wrote about anomalies, you would be right. That would be a non-linear font.


Hexadecimal is a Base 16 numerical system. It isn't a coincidence that Tile Layer Pro's default view is 16 tiles wide by 16 tiles high. Imagine a row of hex values across the top and along the left side of your tiles, with a 0 over the 0 in your font, on down to an F over the F in your font, then a 0 to the left of your 0 and an F to the left of what looks to be the upper quarter of a smiley face (the first column of the bottom row.) Take the left value, then the top value and you have the hex value for that particular character. Hence, 00=0 and 0A=A, as you've already determined. 11=H and 14=K on down to D9=?.

Also, remember that you've already determined that the value of 0 is 00. If it was something else, say 01, you would have to shift the view in TLP so that 0 was in the slot for 01. (In other words, just because you have a particular tile in the first slot doesn't give it a value of 00.)

And a minor tip for making your table: If I were building a table for that font, I would type the second set of numbers as (0) (1) (2), etc. That way, when you're viewing it in a hex editor, you won't be confused as to whether you're seeing the 0 from the first row or the 0 from the third row.

I've seen games that use a control code with the same value as a font character, but I've never seen a game that had something like 2A=C, 2B=some control code, 2C=D. But, yes, I've only hacked a couple of dozen games and only 2 of them were RPGs (and pretty basic ones at that) so I'm sure there are thousands of anomalies I haven't encountered. But vx is translating a sports game, so odds are good that it doesn't use a bizarre text routine.

You need to learn about pointers, my friend.

You should also familiarize yourself with this. Applies to Vista, too.

cYa,

Tauwasser

The "Pointer Hacking" document category is a good place start your search.

I'm not sure that there *is* a good pointer hacking document. Mad Hacker's document is solid as far as information goes but the organization is absolute shit. Xcalibur's document seems to be organized nicely but doesn't appear to contain any examples. And the Gameboy document seem to be geared towards someone who already knows how to hack pointers on other systems.

I've mentioned in the past that a new pointer document needs to be written and seeing as how the official release of my relative search document should occur by the weekend, I guess I know what my next project is. In the meantime, I would recommend The Mad Hacker's document. As I said, it looks like shit, but the information in it is good. It's how I learned to hack pointers.

Interesting way to look at it like that. Not entirely right though. The text values are the offsets to the font pointer. There is one pointer that tells the game where the font is stored. The text values are offset values (multiplied by the amount of bytes per character in the font) that are then added to that pointer.
For example on the GBA, say you have a font stored at 0x08001000 and one character is 0x20 bytes of data. Let's also say you have the following fragment of a table file:
10=a
11=b
12=c
If you'd then want to write 'abc', the game would load the font pointer (08001000), look for the table value of the first character (10) and multiplay that by the amount of bytes per character (20) to get an offset value of 0x200. That's added to the original pointer then. 0x08001200 would be the pointer to the character "a" in the font. Accordingly, you'd get 08001220 for "b" and so on. You wouldn't find that pointer to the character in the ROM anywhere, since it's calculated from a base pointer with an offset.

Pointers to text usually work differently. They don't point to any graphics, they point to individual strings of text. There are usually no offsets involved here, although there can be, depending on the game.