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

Author Topic: Trying to translate Endonesia (PS2)  (Read 878 times)

loukas808

  • Newbie
  • *
  • Posts: 1
    • View Profile
Trying to translate Endonesia (PS2)
« on: July 14, 2020, 11:16:42 am »
Hello everyone,
I am a complete beginner who has decided to try and see how difficult it would be to translate the game dialog text for Endonesia.
After extracting all the files from the cd image, i quickly discovered that the text is encoded in EUC-JP, inside a "exo.bin" file.
altough i'm able to edit and in-game display text using the 2 bytes latin characters,

the game doesn't display the standard ASCII 1 byte set (except for the whitespace, hex value 20).

After digging further in the hex code, i found the pointers table after every "block" of strings:

Those bytes give the (reversed) distance from a fixed point before the block.
I succesfully played around with those pointers and this gives some freedom for space management.
Not being able to type in standard ascii text imposes a heavy limitation, making any translation attempt impossible.
I don't have any experience in ASM hacking and can't really find any documentation that would lead me to anything useful for this purpose.
So, before giving up completely, i decided to ask here for any kind of help/guidance.

Risae

  • Jr. Member
  • **
  • Posts: 73
    • View Profile
Re: Trying to translate Endonesia (PS2)
« Reply #1 on: July 16, 2020, 01:37:53 pm »
Hi loukas808,

a dirty solution would be to

1. Find and edit the font file and overwrite the japanese characters with latin ones
2. dump the script with the pointers using Cartographer/abcde
3. use a modified table file that uses the japanese hex codes and translates those to the latin characters
4. reimport the translated strings into the game using Atlas/abcde

But this still wouldn't fix the width issue.
If you want to make the text look really good, you probably need to write assembly code to include the 1 byte characters and a variable width, if a variable width code doesn't already exist.

Since you are working with a PS2 game, here is some programs i can recommend for you to reverse engineer the ELF file (SPLM...:

Ghidra + Emotion Engine processor:
https://github.com/NationalSecurityAgency/ghidra
https://github.com/beardypig/ghidra-emotionengine

TIM2 viewer to view tm2 files:
https://www.romhacking.net/utilities/1069/
« Last Edit: July 16, 2020, 03:40:39 pm by Risae »

FAST6191

  • Hero Member
  • *****
  • Posts: 2966
    • View Profile
Re: Trying to translate Endonesia (PS2)
« Reply #2 on: July 16, 2020, 03:10:11 pm »
Yeah I rarely see games support the 8 bit side of things when they have a known/common 16 bit encoding -- it does add a bit of complexity to whole deal that has no real payoff.

As you have pointers sorted by the looks of things I assume when you say "Not being able to type in standard ascii text imposes a heavy limitation, making any translation attempt impossible." it means you run into memory issues (while DVD as far as text is concerned is basically infinite if it all has to be in memory on the console itself then that makes life harder) as English tends to be that little bit more wordy that you can't fit. Even if you cut down the text complexity a bit; as rich as it is coming from me you can usually simplify things and get things across still.

16 bit to 8 bit text encoding conversions do happen and have happened on many things. However it is a step up in difficulty most of the time (most games not having the option to simply edit a font like you might do for some PC stuff and some DS stuff) which will see you having to fiddle with the code handling the text. Said handler will generally fetch a character from the text, check it against its list, fetch the attendant graphics and go from there, add in a bit more for points and screen handling and you have the whole deal. Your job would be to change the fetch a character part to be 8 bits, change its list to be 8 bits and then have it fetch whatever you need accordingly as well as sort any fallout with punctuation, line breaks and whatever else. While you are at it then you could also do a variable font width conversion if that is something you want, though that might add a bit more complexity still.

VicVergil

  • Hero Member
  • *****
  • Posts: 725
    • View Profile
Re: Trying to translate Endonesia (PS2)
« Reply #3 on: July 18, 2020, 12:53:01 pm »
Hi.
You have two problems to solve, assuming the game has no inherent support for half width characters.

1- Make the game read 1 byte and display 1 character, instead of read 2 bytes and display 1 character.
Often, this is handled by changing the read operation to only account for 1 byte, add an instruction to overwrite the "ghost" second byte with what the original programming is expecting, and send that to the original programming.

For example you'd redraw the font so that the characters in Shift-JIS area 0x8520-0x857F have the English ASCII set glyph graphics from 0x20-0x7F ... then, the game reads 2 bytes as usual, you're interested in the first so you tamper with the read (only keep first byte, then add 85) and then pass it over to the original code.

However... Some control codes would be something like FFFF or FEFF or whatever, and would be broken by this solution. You'll need to account for them. Either make it so that your hotfix mentioned above only happens when a "text mode" is on (through another control code perhaps?) or change the code after the hotfix to assign your control codes to single byte values. (I think the Summon Night Hajimari no Ishi project is struggling on this particular issue)

End result: Your text can be 2 times shorter.
It might still not be enough (look into adding a simple DTE/dictionary compression, while you're modifying the relevant programming?)
It will still appear double width and you'd run out of screen estate.

2- Make the individual letters appear half width.
Some PC-98 translators recommended making diffs of memory states between each frame of text displaying, to find the relevant addresses for the individual character positions and the advance value.
Some PS1 romhackers recommend a graphical debugger that gives the coordinate of each individual texture and instructions drawing it. I'm not sure an equivalent tool exists for PS2 or GameCube.

That's one of the higher barriers in such modifications. Maybe the Tear Ring Saga / Berwirk Saga translators have some expertise in that? They did do that, and then add variable width on top (changing that static value add, to a read from a table depending on the character then add that)



Looking at your screenshots, I noticed something peculiar with your half width experiment.
If you wrote "test" in ASCII for the first one, then considering JP-EUC has compatibility with ASCII (behaves exactly the same until 0x7F, then uses 2 bytes for other characters), it might be that the game actually does have the two options mentioned working correctly in fact, but there's a problem with the display, either:
- the individual character texture is stretched incorrectly
- the font data is pulled from garbage data instead of valid graphical memory
I think the width at the very least is correct. You might want to look into fixing the programming (font start offset) or texture (encoding it with a different width value?), considering you did your homework for the pointers?

« Last Edit: July 18, 2020, 12:58:31 pm by VicVergil »