Far East of Eden Zero Translation

[LostTemplar]

First note that I have started a small homepage with an introduction to my project here: http://www.au-ro-ra.net/index.php?page=feoeztrans&lang=en

I have been playing around with Far East of Eden Zero on and off for a few years now. After byuu had dropped the game, I thought about translating this game myself as I wanted it to receive a quality translation. Then, a few months ago, I documented my results so far and started working on it seriously. My philosophy is: After translation, the game should still be playable on the real hardware (that means e.g. no fancy ROM expanding), but nevertheless as few compromises as possible should be made. We will see how this will work out; I think if there are compromises to be made, it will be with the script size.

The German translation will be done by myself, but only after all hacking is finished. Any capable translators into other languages willing to translate the script are welcome; but be aware that it is huge.

I already finished the following tasks:
- 16x16 dialog VWF
- 8x8 menu VWF
- complete script dump
- some menu hacking
- inserter/dumper for the compressed graphics

Obvious things still missing:
- implementation of text compression (I consider arithmetic coding)
- ideas of how to localize the strategy naming

I am by no means an expert on compression, so if anybody knows a good (de)compression algorithm for text that can be implemented on SNES hardware, let me know (LZSS won't work - there's no RAM space left).

Here are a few screenshots of my results so far. These show a work in progress; everything is still subject to change. I'll start with a few before-after screenshots:

This one shows the equip menu where you can see the new 8x8 VWF in action.


Here I changed the line spacing in order to allow for longer sub-menu names.


I replaced the kanji with some symbols to demonstrate the insertion of compressed graphics (the right one is a bit darker because I made the screenshot with bsnes - Snes9x, which I use for debugging, still uses the graphics pack...)

These show the new 16x16 VWF implementation (the font will be changed for the actual translation):

[Pennywise]

I wish you luck with your translation. This is one of those games that just needs to be translated and you look like you're off to a pretty good start.

From what I remember, Tomato was going to be translating for Byuu. I guess the only question is whether or not he has the time to tackle the script.

[Gideon Zhi]

That's really impressive. 8x8 VWF is one of those things I could prooooobably do if I really put my mind to it, but am generally scared off by all the weird vblank stuff I'd have to do.

Good luck with this!

[LostTemplar]

Thanks, you two!

From what I remember, Tomato was going to be translating for Byuu. I guess the only question is whether or not he has the time to tackle the script.

I actually contacted Tomato about this, but he said he didn't have the time at the moment.

That's really impressive. 8x8 VWF is one of those things I could prooooobably do if I really put my mind to it, but am generally scared off by all the weird vblank stuff I'd have to do.

For this game it just had to be done because a lot would have had to be abbreviated. That would have been a total waste considering that there's no inherent limit to item name length (they're stored like any other string in the script). Luckily for me, FEoEZ made it comparatively easy. There's still much to be considered though; you especially have to be careful that new strings don't override old ones, for example when the user scrolls the item list.

[KingMike]

In a game I've been working on, I reserved part of the available tiles for a scrollable buffer, and the other part for "fixed" text, which I could only access through control codes that set which tile is used to store a particular string onscreen. When it reaches the end of the "scrollable" part of the tileset, it would reset to the beginning of the "scrollable" part.

Nice-looking menus, but one nitpick is that it looks really inconsistent for "HP" and "TP" to be printed after the value, when all other variables have the label printed first.

[locolol]

Your work looks great   good luck with this!

[LostTemplar]

In a game I've been working on, I reserved part of the available tiles for a scrollable buffer, and the other part for "fixed" text, which I could only access through control codes that set which tile is used to store a particular string onscreen. When it reaches the end of the "scrollable" part of the tileset, it would reset to the beginning of the "scrollable" part.

Yeah, I did it quite similarly. It's still tricky, though.

Nice-looking menus, but one nitpick is that it looks really inconsistent for "HP" and "TP" to be printed after the value, when all other variables have the label printed first.

As I said, nothing is set in stone. It's easily changed:

I first want to implement everything robustly such that it works well without glitches or slowdowns. Then come the details like positions and alignment :) But thanks for pointing it out anyway.

[DarknessSavior]

I know this is slightly nitpicking, but why not include the calender from the Japanese menu? I actually think that's relatively neat.

~DS

[LostTemplar]

I'm not sure I know what you mean as I didn't ditch anything but the current day of the week, which I'll include in the future. The current date/time I just moved to the bottom right and converted it to German date format (dd.mm.yyyy) and 24-hour notation. For each other release it could easily be changed to the corresponding date and time format.

[Rhys]

For text compression would RLE be suitable? It's pretty easy to do and wouldn't really require much more than the use of a register for decompression.

[LostTemplar]

For text compression would RLE be suitable? It's pretty easy to do and wouldn't really require much more than the use of a register for decompression.

Unfortunately not. In natural language, there aren't many instances where the same character is repeated multiple times, so it wouldn't be very effective.

[Auryn]

Well it's looking like there is no other option as DTE/MTE. Save the dictionary somewhere in the rom and use that.
There are even programs that check the script and tell you what the best DTE/MTE are.

Auf jeden fall, sieht es geil aus :p

[LostTemplar]

For the record, I think these are the available options for text compression:
  (a) Huffman coding
  (b) Range coding (resp. arithmetic coding)
  (c) dictionary compression (can be combined with a or b)

Range coding, at least in theory, nets better results than Huffman but also needs more resources. Dictionary methods can always be thrown in. The Japanese version actually uses its dictionary quite a bit. I said I was no expert, but I still did a little research ;)

@ Auryn
Danke, ich habe mich ja auch angestrengt ;)

[Nightcrawler]

You mentioned you didn't have any RAM left. Remember, a game never needs all of the RAM all of the time. So, even if the entire RAM seems used, the trick is deciphering what areas you can get away with temporarily overwriting when you need them. I'd bet my lunch there is RAM to be found.

[DarknessSavior]

I'm not sure I know what you mean as I didn't ditch anything but the current day of the week, which I'll include in the future. The current date/time I just moved to the bottom right and converted it to German date format (dd.mm.yyyy) and 24-hour notation. For each other release it could easily be changed to the corresponding date and time format.

Oh, hehe. Sorry about that. The screenshots you showed before your last menu change didn't have that, so I wasn't used to looking for it. T_T;

Glad to see it there.

~DS

[LostTemplar]

The problem is that with RAM space, one can't be so sure if it is really unused. It would probably be compulsary to create a usage map while playing through the whole game. For LZSS, it's also advisory to apply it to sufficiently large blocks of text which then must be decompressed in advance and kept in RAM for good performance (Star Ocean for example does that). That means it really has to be persistent, unoccupied space. I don't think acceptable speeds could be achieved when an LZSS block would have to be decompressed each time the player talks to a person. But I'll look out for it as LZSS would really be nice to have.

Oh, hehe. Sorry about that. The screenshots you showed before your last menu change didn't have that, so I wasn't used to looking for it. T_T;

Glad to see it there. :D

~DS

I'm quite a purist, so I wouldn't just ditch anything that was in the original ;)

[Nightcrawler]

I don't think acceptable speeds could be achieved when an LZSS block would have to be decompressed each time the player talks to a person. But I'll look out for it as LZSS would really be nice to have.

It can. I have worked on several games that do this. It's not the most efficient thing to do with your processing time, but it can work. Dialog is not usually processor intensive. In my opinion, I believe Huffman would probably give you a better ratio than LZSS w/ dictionary would. Of course one could conceivably layer with LZ first and then Huffman on this. I believe the DEFLATE algorithm does this. That would probably be pushing it processing wise though. The quality of your compressor comes into play here as to the ratio. How well you decode also has much to do with the speed.

Probably the best thing to do is start establishing some baselines and try some scenarios out. Without much effort, you can use Script Crunch to start giving yourself a good idea of what you can save with some basic algorithms. See how close that gets you and you can determine feasibility of getting where you need to go using more advanced means. I'm fairly certain somebody released a Huffman compressor somewhere, but I'm at a loss for when/where.

[LostTemplar]

I would have combined some LZ-variant with Huffman.

But I just gave it a thought; as the script isn't variable and known at the time of compression, a plain Huffman/Range coding+Dictionary might do the trick. The advantage of LZSS of course is that the dictionary does not need to be stored explicitly. I will definitely try out several variations before I implement anything. Script Crunch looks interesting, I will give it a try for experimentation. Huffman is pretty simple, I wrote a compressor (x86)/decompressor(SNES) pair a long time ago.

[Tom]

I would be MORE than willing to do the English translation. It would go to the top of my priority list. I can work on it immediately. I fully translated Oriental Blue: Ao no Tengai for Kingcom (it's still not fully hacked, but it's entirely translated). I would be extremely delighted to work on the English translation of Tengai Makyou Zero.

[LostTemplar]

I sent you an E-Mail.