Author
|
Topic: Making table file (Read 1 times)
|
Rappa
Guest
|
 |
« on: October 31, 2010, 08:03:03 am » |
|
I know this is a basic. You must do a relative search to find out which hex value stands for which character in the game. But I encountered several Snes games that relative search went to all big Vain! Maybe the text is compressed :banghead:
I just want to ask that, is there any effective way to make table file than relative search?
Suppose that I don't know Asm at all.
Can you use debugger to do this?
|
|
|
|
|
KaioShin
Guest
|
|
« Reply #1 on: October 31, 2010, 08:29:23 am » |
|
Of course, a debugger can find any information. But it requires some basic ASM knowledge to make any sense of the information it gives you.
Have you found the font yet? Often one can directly glance the table values from the font, assuming it starts at 00. Also try relative searching RAM (= a savestate when text is used). Even if the text is compressed it might appear uncompressed in RAM unless the game is actually decompressing each character individually.
|
|
|
|
|
Rappa
Guest
|
|
« Reply #2 on: October 31, 2010, 12:45:38 pm » |
|
Well, I know the relationship between the font and the text. I usually look at the order of the characters in the font to do relative search in said order. Also try relative searching RAM (= a savestate when text is used). I've tried this method for some games that I already have the table files. I played them in Zsnes, disable all layers except the one which the text is being displayed, then make a save state. Then I open the save state files in Yy-chr and see the text there. But when I do a relative search in the save state file, the result came nothing. I open then in Windhex then load the table (which I already have) and can't locate any text there. So this means there's no text in the save state files? Or where I get wrong :banghead: |
|
|
|
|
Tauwasser
Guest
|
|
« Reply #3 on: October 31, 2010, 12:52:56 pm » |
|
Going out on a limb here, but you are searching for one set of letters at a time only, right? Don't mix uppercase and lowercase for relative searches.
cYa,
Tauwasser
|
|
|
|
|
Rappa
Guest
|
|
« Reply #4 on: October 31, 2010, 06:49:26 pm » |
|
Yes, I just searched one set of letters, the Hiragana at a time only.
It's strange that this varies on games. I tried again with the FF IV Snes and there's text in the save state file.
|
|
|
|
|
Ryusui
Guest
|
|
« Reply #5 on: October 31, 2010, 07:04:25 pm » |
|
Not strange at all. Encoding varies wildly between different games. This is less the case now that games have the storage space to just cram in a proper Shift-JIS character set and call it a day.
Gotta ask: is this one of those games where the dakuten print on a separate line? Because that might be what's throwing you off. In those games, dakuten are usually indicated with an extra byte after the character.
Worst-case scenario, you can try ASM tracing. The simplest text printing method involves reading bytes from the ROM and writing them directly to the tilemap. Set a write breakpoint for the VRAM location where the tilemap is being updated and find out where the data that gets written there is coming from. (Note that I'm assuming you're working on either an NES game or an older SNES title. Please correct me if I'm wrong.)
|
|
|
|
|
Spikeman
Guest
|
|
« Reply #6 on: October 31, 2010, 10:49:32 pm » |
|
If you are able to find a string of text, you can just change the string to a sequence of values that you want to know, eg. 00 01 02 03 04 05 06 07. This is a harder to do if the game uses double byte values, but the principal is the same: FF 00 FF 01 FF 02 FF 03, etc.
As far as finding the string of text I usually set a breakpoint on the tiles or graphics and follow the code backwards, but you could also use ROM corruption.
|
|
|
|
|
Rappa
Guest
|
|
« Reply #7 on: November 01, 2010, 08:12:52 am » |
|
Gotta ask: is this one of those games where the dakuten print on a separate line? Because that might be what's throwing you off. In those games, dakuten are usually indicated with an extra byte after the character. No, this is not the case. The dakuten and handakuten on the same tile with the kana. If you are able to find a string of text, you can just change the string to a sequence of values that you want to know, eg. 00 01 02 03 04 05 06 07. This is a harder to do if the game uses double byte values, but the principal is the same: FF 00 FF 01 FF 02 FF 03, etc.
As far as finding the string of text I usually set a breakpoint on the tiles or graphics and follow the code backwards, but you could also use ROM corruption. If I am able to find a string of text, the rest would be time. If I already know a string of text, I can build a whole table easily. By the way, could you please explain to me what Rom corruption is? This is the first time I heard of it.  |
|
|
|
|
Ryusui
Guest
|
|
« Reply #8 on: November 01, 2010, 06:41:27 pm » |
|
Rom corruption means tweaking values in order to find data. If the thing you're looking for in the ROM screws up in the game, then you've found the data. :3
|
|
|
|
|
Rappa
Guest
|
|
« Reply #9 on: November 02, 2010, 07:59:53 am » |
|
I also thought this before, but since you don't know where the text is so you have to test hundred times for the result.
And I don't see why there are Rom corrupter utlities out there. You can do this by hand with a hex editor, and randomly :banghead:
|
|
|
|
|
KingMike
Guest
|
|
« Reply #10 on: November 02, 2010, 10:06:46 am » |
|
Yes, but ROM corrupters allow you to do corruption in patterns, and faster than if you manually typed in the values.
(or so I'd guess, I've never actually used one before)
|
|
|
|
|
Ryusui
Guest
|
|
« Reply #11 on: November 02, 2010, 02:29:14 pm » |
|
Ditto here. It's not romhacking, it's Battleship.
|
|
|
|
|
|
RHDN Forum Archive
