News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Author Topic: [GC] Dokapon DX's, How to properly find where the text pointer values come from?  (Read 639 times)

EternalYoshi

  • Newbie
  • *
  • Posts: 2
    • View Profile
I am very close to being able to implement a translation for Dokapon DX: Wataru Sekai wa Oni Darake, but this last obstacle stands in the way. The question I ask has context behind it and I'm not 100% sure on how to ask it succinctly since it requires a bit of background.

Dokapon DX has a full English Alphabet, both upper and lower case characters.

I've been learning the text format in the archives and which files have them with the help of Dolphin's Debug mode. I also made a table for the text format and have dumped the text with a small quick and dirty program I made too.

The problem comes with the text pointers. When a text box gets created there's text pointers that points to the start of the text entry.
I'm going to use the Title Screen menu as an example.



On the first frame the game produces the text boxes, 3 pointers are set in specific places in memory which control which offset the text starts being read from. The second text box in that image(Which translates to Battle Mode), for example, has the pointer at offset 8027d2d4 which has a value of 8096f024. Changing this value allows me to move it to where I need to so it can display the translated name properly and not overlap. Overall, the translated English text on this screen would have more characters than the Japanese ones so I need to be able to move the values for the pointers as needed so there's no overlap or problems. Also, I learned I can append the archives where the text is stored safely, so I want to move these pointers to the appended data. By editing the value at offset 8027d2d4 and 8027d3a4 for the 3rd one, I'm able to edit the title screen and point to the appended data like so:



To my knowledge, these pointers only exist as long as the text boxes do; once the text boxes are terminated so are the pointers. The above image was done by editing the values in real time while the game is running. Leaving the menu means those values are set back to their original values. The values don't seem to exist in Dolphin's memory when the text boxes don't exist.

So then I tried using Dolphin's Registers, Memory, and Code windows to find out where they are coming from. From what I've seen the values for these pointers are held in register 30/r30 and written to the respective addresses
by instruction 8001bdcc.

After several minutes looking back to see where the values originated I noticed that Dolphin doesn't seem to have an option to trace such things back to their origin and trying to look at the assembly to track it myself feels like finding a needle in the haystack.

I recently learned there was an older build with tracing and such included. I've been steadily getting a little more information with it (is 802e0578 where r30 is located?), but it seems to have stability problems which may be because of that build is over a year older than the Dolphin I'm using now and I'm getting sudden crashes trying to trace things at times.

I'm not familiar with Assembly, specifically PPC ASM but I am determined to try and get this resolved so I can translate and play this game with others. Is there a more efficient or sensible way to find the origin of these pointer values?

FAST6191

  • Hero Member
  • *****
  • Posts: 3129
    • View Profile
Is there nothing in the files the text corresponds to that might be pointers?

For filesystem based stuff then I would expect them to be generated at runtime (saves having to recompile the whole game when one of the script editors changes something and instead can generate a pointer from data elsewhere).

The "properly" way is actually the way you describe. Find what stashes it on screen and work backwards from there, and if indeed the debugger options for dolphin are weak then you are in for a less than pleasant time. Can be a bit more tedious still on newer devices that have to formulate a CD read command* (if it knows the file is at location Y on the CD, and the section it wants within the file is at X it will do X+Y and then send out a grab this much data at this location and stash it here in memory), though do bear in mind X+Y could be something a bit more involved if it is relative pointers, offset pointers, sector based or something).
The usually quicker way that works on most occasions is find the pointers within the archive file, helper file (usually same directory, named similar to the files it contains but probably smaller), binary or whatever else. When the game runs the game will probably grab the header/helper/have the locations in binary and use that to generate the reads.

*that can actually be a shortcut for some. If there is only one way to read a CD/dvd/... then any command that reads something will inherently be worth looking at.

http://hitmen.c02.at/files/yagcd/yagcd/frames.html chapter 4 covers memory. The region you describe just appears to be normal RAM. Fairly expected when things have to bounce from disc to RAM (things with cartridges often can be read directly in system memory and operate from that, rather harder when you potentially have to spin up the disc and get to a point and then read it speeds usefully measured in kilobytes a second).

vree

  • Newbie
  • *
  • Posts: 1
    • View Profile
I am very close to being able to implement a translation for Dokapon DX: Wataru Sekai wa Oni Darake, but this last obstacle stands in the way. The question I ask has context behind it and I'm not 100% sure on how to ask it succinctly since it requires a bit of background.

Dokapon DX has a full English Alphabet, both upper and lower case characters.

I've been learning the text format in the archives and which files have them with the help of Dolphin's Debug mode. I also made a table for the text format and have dumped the text with a small quick and dirty program I made too.

The problem comes with the text pointers. When a text box gets created there's text pointers that points to the start of the text entry.
I'm going to use the Title Screen menu as an example.



On the first frame the game produces the text boxes, 3 pointers are set in specific places in memory which control which offset the text starts being read from. The second text box in that image(Which translates to Battle Mode), for example, has the pointer at offset 8027d2d4 which has a value of 8096f024. Changing this value allows me to move it to where I need to so it can display the translated name properly and not overlap. Overall, the translated English text on this screen would have more characters than the Japanese ones so I need to be able to move the values for the pointers as needed so there's no overlap or problems. Also, I learned I can append the archives where the text is stored safely, so I want to move these pointers to the appended data. By editing the value at offset 8027d2d4 and 8027d3a4 for the 3rd one, I'm able to edit the title screen and point to the appended data like so:



To my knowledge, these pointers only exist as long as the text boxes do; once the text boxes are terminated so are the pointers. The above image was done by editing the values in real time while the game is running. Leaving the menu means those values are set back to their original values. The values don't seem to exist in Dolphin's memory when the text boxes don't exist.

So then I tried using Dolphin's Registers, Memory, and Code windows to find out where they are coming from. From what I've seen the values for these pointers are held in register 30/r30 and written to the respective addresses
by instruction 8001bdcc.

After several minutes looking back to see where the values originated I noticed that Dolphin doesn't seem to have an option to trace such things back to their origin and trying to look at the assembly to track it myself feels like finding a needle in the haystack.

I recently learned there was an older build with tracing and such included. I've been steadily getting a little more information with it (is 802e0578 where r30 is located?), but it seems to have stability problems which may be because of that build is over a year older than the Dolphin I'm using now and I'm getting sudden crashes trying to trace things at times.

I'm not familiar with Assembly, specifically PPC ASM but I am determined to try and get this resolved so I can translate and play this game with others. Is there a more efficient or sensible way to find the origin of these pointer values?

So any progress? Would really love to play this game in english.