Xanadu II Translation Development Blog

[seieienbu]

There are a lot of different text messages that go into that "Attack +12" string area ... and the number itself can be up to 6 digits long.

I think that I'm going to need that 6x12 font in order to keep any abbreviated text messages understandable. 

I think I speak for everyone when I say that abbreviating Defense to Def is nowhere nearly as gross as abbreviating Dragon Slayer to Dragn Slyr.  It's been a while since I've played, but I seem to recall the stats being referred to as Def and Atk on your character status sheet thing-y.  Assuming this is the case, if you leave it as Atk and Def then you have symmetry that actually works pretty nicely, in fact.....

Also, I'm of the opinion that the shop menu looks better with the item name up at the top than down below anyway.  Hurray for problem solving!

[elmer]

The new trick is actually pretty neat ... in Xanadu 2, all of the item descriptions are stored in the script chunk for the "Pause Menu", and not in the Game Code like in Xanadu 1.

Each Weapon Shop is contained in it's own script chunk, just as you'd expect, and this is decompressed and copied into $A000-$BFFF for execution just like all the other script chunks.

But in order to print out the item descriptions, the Weapon Shop itself decompresses the Pause Menu's script chunk into the temporary decompression buffer and maps that buffer into $C000-$DFFF, just so that it can access the table of item descriptions (which is located $2000 higher than normal).

When Falcom decided to put the item names/descriptions into the Pause Menu script chunk and keep them compressed most of the time, this had an interesting side-effect that recently caused some trouble for the Xanadu 2 translation process.

While the Weapon Shops get access to all of those item name strings by decompressing Pause Menu into temporarily-unused space ... that option isn't available to the regular script chunks.

Now most script chunks don't ever need to use those item names ... but some do, and those are the ones that contain a Treasure Chest.

When you open the Treasure Chest, you receive an item, or some gems, or just nothing ... but if it's an item, then the name of that item needs to be displayed.

So Falcom decided to make copies of the name strings for those items in each script chunk that contains a Treasure Chest.

In order to save memory, they only store the names of the small subset of items that you might potentially get from that particular Treasure Chest ... but the method that they use to store/access those strings is unique, and so they weren't being extracted for translation.

Well, now they are. 

[SamIAm]

Beautiful!   

[elmer]

Another thing that Falcom added to Xanadu 2 that wasn't in Xanadu 1, are the popup text boxes.

Just like text that's displayed in the Weapon Shops, these  popup boxes use some custom text printing code.

Once that was fixed, we go from ...



To ...




The last thing to deal with, is actually centering the text so that it all looks nice.

This is accomplished by passing an x-offset parameter to the routine that draws the text box.

Now, our text is obviously a very different width to the original Japanese text, and there are 168 of these popup text boxes in the extracted script, so we really don't want to have to adjust each one manually.

The solution is just to tell the script compiler where each of the popup text boxes is located in the extracted scripts, and then, when the compiler processes each of the translations, it can calculate the width of the new English string and hack in the correct x-offset parameter into the script chunk's code to get passed into the drawing code.


Here is the result ...

[IvanBeavkov]

Elmer,
I just want to say I love this thread so much. It is just so interesting to see these details and clever solutions to problems.

This thread should also be required reading for anyone who complains how long translations take. It is these little details that take a translation from "Well it is in English." To something truly special.

I also have a humble question to ask. Would it be possible, after you have completed this project, to be able to see the code of your tools to see how it works?

I am a software developer, custom business software not games, and I would like to contribute to the translation scene but I am having a hard time getting started. I have read some of the articles over on Romhacking.net, but for me I learn much better by example. So to be able to look at your tool next to the game iso would be very enlightening.

If you are not comfortable sharing your code that is fine I understand, I am just some random guy on the internet. If you do though I would be very grateful.

[elmer]

I just want to say I love this thread so much.

Thanks!   

Would it be possible, after you have completed this project, to be able to see the code of your tools to see how it works?

Certainly, but it's still going to be many months before we're finished with everything.

Then I'll wait another few months to let things settle.

But I fully intend to release everything ... in the same way that I intend to release everything for Zeroigar, too.

In fact, we're nearly at the 6-month mark since the Zeroigar release, so I need to start gathering things together for that.

Except that I have very little free time just at the moment. 

[NightWolve]

This is kind of motivating me to resume with the Emerald Dragon project which has been asleep for some time now.

Funny thing, elmer and SamIAm actually instead motivated me to put in time on advancing TurboRip which I worked on the other day actually due to MNKyDeth being in possession of another previously unknown pressing of Dungeon Master that wasn't in TurboRip's internal PCE TOC database. Heh. I'm much happier where it's at, although I still wish I had invested time in building a future GUI version. I could've whipped something up with Visual Basic long ago, but I just don't wanna take the easy way out with a RAD development package like that.

Anyway, I still wanna wrap up some things with TurboRip first, and then resume with Emerald Dragon. I'll have much more free time coming up.

[Bonknuts]

This is kind of motivating me to resume with the Emerald Dragon project which has been asleep for some time now.

Funny thing, elmer and SamIAm actually instead motivated me to put in time on advancing TurboRip which I worked on the other day actually due to MNKyDeth being in possession of another previously unknown pressing of Dungeon Master that wasn't in TurboRip's internal PCE TOC database. Heh. I'm much happier where it's at, although I still wish I had invested time in building a future GUI version. I could've whipped something up with Visual Basic long ago, but I just don't wanna take the easy way out with a RAD development package like that.

Anyway, I still wanna wrap up some things with TurboRip first, and then resume with Emerald Dragon. I'll have much more free time coming up.

 Speaking of which, how are your gui app making skills? The PCE community could really use a PCE map making utility. *Hint-hint*. None of the ones out there offer tile editing along subpalette association, etc or the capability of the PCE (16 subpalettes). Pro Motion had something, but that was like a $100 and not sure if they worked on it in the past few years (it had a bug in the tile/tilemap section).

[NightWolve]

I tried to make a Font Editor once, but I gave up... Not good enough, I admit... lol

I'm too much of a slow poke and there's gotta be a lot of motivation to get something done.

But on the subject, making a GUI really is kind of an art. If you look at my TOC Fixer, you won't be impressed, but it's a lightweight executable built on barebone use of WinAPI so it'll work all the way back to Windows 95! It takes a lot longer to build with just a Visual C++ IDE, but it's more satisfying and more bug free.

On the other hand, my Translation Station app built with Access XP (recent Emerald Dragon version) shows what you can accomplish if you're persistent and motivated. But, I don't like the cost of VB or VBA RAD software development packages/environments which is what enabled me to build it... There's quite a bit of a pro/con thing.

Later, I made a cheap Internet Explorer version of Translation Station so that any of my translators (most of which were criminals so I never even should've bothered, but I digress, heh) didn't have to pirate Microsoft Access. That's mostly what DeuceBag used for our fan patches, and he also used it one last time (in commercial gain) to port the scripts out and secretly hand off to XXXSEED Games (you know the rest of the story).

Conclusion: Eh, I mostly suck with some exceptions and I'm too slow/tied up/burned out to be of much help to others.

[elmer]

Elmer's Xanadu II dump is finally in my hands, and it looks great. We're exploring options for merging the old translation as it exists in Esperknight's dump with this new one. Elmer has so far gotten the old lines to sit at the top of each file where they exist in the new dump (and there are 300+ files). If I have to copy/paste everything manually, that saves me a big couple of steps. Next is to see whether the old lines can be placed exactly where they're supposed to go throughout the new dump without too many errors.

Done! 

Where the Japanese text in the new extraction matches the Japanese text in the old extraction, I've copied the old English translation into the new location in the script file.

That seems to have caught 80-90% of the translations.

All of the old translations are still dumped at the top of the new script files so that SamIAm can refer to them when he goes through each file and fixes things.

I've given SamIAm the insertion toolchain for Xanadu 2 ... so now it's all up to him! 

FYI ... all the translations fit into memory with no problem (at the moment), so I think that we're going to be OK with having the game still run on a regular Super System Card.

From my POV, barring any bugs, I'm done with the main hacking on the games.

What's left are all the small graphical changes that need to be made (like the initial menu option in Xanadu 2), and then implementing a full variable-width-font (since I'm pretty confident, finally, that there should be enough memory left in code space to do that).

[elmer]

This is kind of motivating me to resume with the Emerald Dragon project which has been asleep for some time now.
...
Anyway, I still wanna wrap up some things with TurboRip first, and then resume with Emerald Dragon.

Excellent news! 

Speaking of which, how are your gui app making skills? The PCE community could really use a PCE map making utility. *Hint-hint*. None of the ones out there offer tile editing along subpalette association, etc or the capability of the PCE (16 subpalettes). Pro Motion had something, but that was like a $100 and not sure if they worked on it in the past few years (it had a bug in the tile/tilemap section).

ProMotion (http://www.cosmigo.com/promotion) is a great app and I'd highly recommend it to anyone ... it gets a lot of commercial use.

A new version was released in December, and the price was dropped to $60.

There's also a "free" edition that people can use.

IMHO ... writing major GUI tools requires a huge investment in time. It's usually better to use existing tools with a custom export/processing stage.

Even during the actual time of the 4th-gen machines, most development was done with 256-color editors (like dpaint) with the teams following the convention that the 256-colors represent 16-palettes of 16-colors.

Most decent editors offer "grid" movement of the cursor that you can set to something like 8x8 so that you can simulate tiles.

I tried to make a Font Editor once, but I gave up... Not good enough, I admit... lol

I gave up writing GUI editors years ago ... but still have my custom "converter" that supports a lots of different inputs and outputs, and a crazy amount of "options".

IMHO colored fonts are best-done in photoshop so that you can use the huge supply of true-type fonts as a starting-point.

It's easy to reduce them down to 16-colors-or-less when they're done, and then you can remap them into specific palette indexes with grafx or promotion.

For single-color fonts, I just use "fony" (http://hukka.ncn.fi/?fony).

[poponon]

But, I don't like the cost of VB or VBA RAD software development packages/environments which is what enabled me to build it... There's quite a bit of a pro/con thing.

I had an issue with this recently as well and switched over to Lazarus IDE as a result. Very similar to VB or VB6 but far better in nearly every way so far. It's a free Delphi clone. Just though I should add incase you want to give it a shot.

[TheOldMan]

Congratulations.

Now the boring stuff starts

[Gredler]

ProMotion (http://www.cosmigo.com/promotion) is a great app and I'd highly recommend it to anyone ... it gets a lot of commercial use.

A new version was released in December, and the price was dropped to $60.

There's also a "free" edition that people can use.

Wow this looks awesome! Thanks for sharing! Is this something that I can wrangle into HuC?

IMHO ... writing major GUI tools requires a huge investment in time. It's usually better to use existing tools with a custom export/processing stage.

Even during the actual time of the 4th-gen machines, most development was done with 256-color editors (like dpaint) with the teams following the convention that the 256-colors represent 16-palettes of 16-colors.

Most decent editors offer "grid" movement of the cursor that you can set to something like 8x8 so that you can simulate tiles.

Danm, I know it's potentially viable to create a script combining image magic and photoshop batch actions to automate this somehow, but my coding skills are far inferior to the requirements to set it up.

Best I could try and manage is to create a good exporting tool for a single pcx with correct color indexes.

Tile assignment and subdivision is a whole other beast, but it should be possible in photoshop (esp considering the slice tool export options for web development)

IMHO colored fonts are best-done in photoshop so that you can use the huge supply of true-type fonts as a starting-point.

It's easy to reduce them down to 16-colors-or-less when they're done, and then you can remap them into specific palette indexes with grafx or promotion.

For single-color fonts, I just use "fony" (http://hukka.ncn.fi/?fony).

In the past we used tools such as this http://www.bmglyph.com/ to create font atlas's, but that was just what the office used, and there are a ton of similar tools out there to get a base atlas made, that can then be painted in photoshop once generated. Tools like this allow unique fonts to be generated across multiple type faces which is obviously very helpful for creating fonts for various languages, but also has a great application for creating a base for low res sprite fonts.

[NightWolve]

But, I don't like the cost of VB or VBA RAD software development packages/environments which is what enabled me to build it... There's quite a bit of a pro/con thing.

I had an issue with this recently as well and switched over to Lazarus IDE as a result. Very similar to VB or VB6 but far better in nearly every way so far. It's a free Delphi clone. Just though I should add incase you want to give it a shot.

Thanks man, I will! I was googling for alternative IDEs to Microsoft VC++ Express the other day with form building VB-style aspects. Probably you gotta pay for something good like that. The freeware route I guess just seems using resource hackers to lay out the form objects and then connect it up with your code to handle input manually and what not. How I built TOCFixer.

For single-color fonts, I just use "fony" (http://hukka.ncn.fi/?fony).

Dang, that is nice! Heck, that is what I was trying to build and wanted (way back when), pretty much.