+  RHDN Forum Archive
|-+  Romhacking
| |-+  ROM Hacking Discussion
| | |-+  Text/Script Dumping Methodology
Pages: [1]
Author Topic: Text/Script Dumping Methodology  (Read 2 times)
KrakenSoup
Guest
« on: December 27, 2009, 06:04:28 am »

Hey all, I'm fairly new here but I have been lurking for awhile. Just a (hopefully) simple question this morning:

How does one go about dumping the script of a Japanese game?

I have read up on a lot of romhacking, but this evades me. I read about people "dumping" scripts and handing them off to be translated, but I have know idea how one would go about that process; only the hacking afterwards.

Thank you for your help!
Azkadellia
Guest
« Reply #1 on: December 27, 2009, 06:11:42 am »

Dumping a script requires you to make a table file and using it and a hex editor that supports table files. Then once both are loaded, you look through the ROM and find text used in the game (unless it's compressed. In that case, debugging to find the compression routine is required.) and document it. Once that's done, you you can either code your own dumping utility (preferable because you can control what you dump), or use a ready made generic dumper.
KrakenSoup
Guest
« Reply #2 on: December 28, 2009, 03:35:05 pm »

Hmm, thank you! I know it is a really basic question but it seems a lot of documentation that I have found is outdated.

The only issue I can think of now is how to represent kana in a table file. I'm not sure if that is even possible, so I guess I will just do some relative searching to find what is needed.
Kagemusha
Guest
« Reply #3 on: December 28, 2009, 04:00:11 pm »

I generally build my hiragana/katana tables using Windhex's Table Maker function that let's me easily select my japanese characters. I assume this feature is present in other hex editors as well.
DarknessSavior
Guest
« Reply #4 on: December 28, 2009, 04:07:33 pm »

Quote from: Pennywise on December 28, 2009, 04:00:11 pm
I generally build my hiragana/katana tables
Man, wish I could find a way to build a katana table. 

~DS
Gideon Zhi
Guest
« Reply #5 on: December 28, 2009, 04:49:06 pm »

I shall set out to war with a katakana in each hand.
KrakenSoup
Guest
« Reply #6 on: January 04, 2010, 01:23:17 am »

Quote from: Pennywise on December 28, 2009, 04:00:11 pm
I generally build my hiragana/katana tables using Windhex's Table Maker function that let's me easily select my japanese characters. I assume this feature is present in other hex editors as well.

Thank you! I'll do that. For a bit there I was thinking hex couldn't possibly represent kana, but then I remembered we're not dealing with ASCII..
Gil Galad
Guest
« Reply #7 on: January 05, 2010, 05:57:47 pm »

Sometimes it's easier to build a table, based on what game your hacking and what gaming console it's for.

For older tile based systems, in some emulators, you can find a tile viewer and look up the tile number. Then add the character to the particular number to the table file. You do need Japanese text display support in order to add and see the characters in a table file. (I use NJstar or EditPad Lite to edit my table files manually)

There are also table file editors that you can use, like Table Manager or Tabular. Those make it easier to make a table file. I use these to set up the basic set of Japanese characters and then use NJStar to add the rest of the characters manually. After you make your table file, double check to make sure your characters are right.

After you have your table file, you can use WindHex32 as a viewer mostly (to locate text blocks and any other data). You can use WindHex32 to dump the text if you wish. However, I don't use WindHex32 as a dumper.

I use Cartographer as a dumper, so that the output file is compatible with Atlas (script inserter). You have to change the end line, end section, end block, etc characters in the table file to use with Cartographer. Reading the documentation for each program will help you.

This is the basic method that I use and sometimes I have to be inventive and figure out a way to make a table file for any game.



KrakenSoup
Guest
« Reply #8 on: January 05, 2010, 10:01:05 pm »

Thank you! It is a pretty *simple* process, but I have already had issues finding the hex values for characters. You know, not being able to find them using an emulator or tile editor for various reasons.. I think I found away that now though.
Klarth
Guest
« Reply #9 on: January 05, 2010, 10:16:58 pm »

If you're unable to find the hex values for a table using an emulator/tile editor (which is fairly unlikely)...then do the following:

1. Use a relative search program.  You may have to be a bit creative to use it with Japanese text, but it still works.
2. If that fails, do the same, except on a savestate (while the text is being displayed).

2 should "always" succeed (unless the text string is overwritten immediately after processing, which'd be very strange).  From there, you'd have to work backwards (with debuggers / assembly) to see how the text got "transformed" from state 1 to state 2, with compression being the most likely culprit, but there are other common cases too.  If it's not compression, you can see where the string is loaded from and check the input (original) against the output (in RAM) and figure it out that way.
Gideon Zhi
Guest
« Reply #10 on: January 05, 2010, 11:33:12 pm »

Quote from: Klarth on January 05, 2010, 10:16:58 pm
2. If that fails, do the same, except on a savestate (while the text is being displayed).

2 should "always" succeed (unless the text string is overwritten immediately after processing, which'd be very strange).

2 will frequently NOT succeed where huffman encoding is concerned. I've only worked on a few games that feature huffman, but all of them drop a single character into RAM, paint it to the output text bitmap, then overwrite it with the next character.
Gemini
Guest
« Reply #11 on: January 06, 2010, 11:41:20 am »

Then write-break on the bitmap.
KrakenSoup
Guest
« Reply #12 on: January 09, 2010, 01:28:15 am »

Quote from: Klarth on January 05, 2010, 10:16:58 pm
If you're unable to find the hex values for a table using an emulator/tile editor (which is fairly unlikely)...
It was a problem with the FCEUX not running the ROM I was working on. Also I had not found a tile editor that would appropriately give me hex values for location in PPU when loaded (If one even exists).

Quote from: Azkadellia on December 27, 2009, 06:11:42 am
Dumping a script requires you to make a table file and using it and a hex editor that supports table files. Then once both are loaded, you look through the ROM and find text used in the game (unless it's compressed. In that case, debugging to find the compression routine is required.) and document it. Once that's done, you you can either code your own dumping utility (preferable because you can control what you dump), or use a ready made generic dumper.
I'm guessing that a dumper basically finds hex at offsets (or other specified locations) and runs it through a table file you created to spit out text? Have you ever coded such a tool? What methods would you use to get said text when writing a program? Other than complete control of what is dumped, why go this route instead of Cartographer/Atlas? I only ask because I am not opposed to coding something like this! Cool

Quote from: Gideon Zhi on December 28, 2009, 04:49:06 pm
I shall set out to war with a katakana in each hand.
Not to be all kiss-ass but I want you to know that you are my hero and you led me into romhacking... I am honored to have your first post in my thread and I wouldn't have it any less entertaining. :laugh:



Thanks everyone! I have made some definite progress and I plan on opening my own project thread soon when I get to a showoff point.
Pages: [1]  


Powered by SMF 1.1.4 | SMF © 2006-2007, Simple Machines LLC