Remember that Tengai Makyo Ziria translation project?

[SamIAm]

That's right, the old man does not say the original poem. He says うぐいすや・・　なくまでまとう　ホトトギス.

うぐいす means nightingale, and the や is basically just like "Oh". It's a very generic-sounding first line. I looked for a specific reference, but there are too many poems that start like this and not one that is particularly famous as far as I could see.

This is not a "scene", so much as a room full of guys at an inn that you can talk to one-by-one.

I think that what I do here will depend on how many more instances there are of Japanese references that Japanese people generally get and westerners generally don't. If it's only in this area, then I might twist in some English references (like "I will always love you") and be done with it. If it happens again, though, I might make some translators notes. I know that that's cumbersome and all, but this isn't some generic fantasy RPG that happens to have a Japanese reference because it was made in Japan. This is bloody Tengai Makyo. It's supposed to be full of Japanese stuff.

I mean, if there was film about Renaissance Europe that made a Shakespeare joke and it was being translated to Japanese, I would want to see the joke left in there. If it needs tweaking, fine, but there should be a Shakespeare joke there. There comes a point where if some audience members don't get it, it's their problem.

Plus, as a practical matter, we're not dealing with a general western audience; we're dealing with a small and dedicated hobbyist fanbase, of whom I think we can ask to come with us on these things. The choice that most translators seem to make with movies is actually just to toss the joke (have you ever watched a Hollywood movie with Japanese subtitles?), but this always seemed like a lowest-common-denominator choice to me.

Not to mention, throwing an original joke out completely and making up a new joke is how we got Bill Clinton references in Lunar 2.

[dshadoff]

That sounds like a fair idea.

One more thing to keep in mind is whether the information disseminated in this area is used later - especially to obtain a power-up.  But in most RPGs of that area, merely speaking to the right person would probably be the trigger.

[SamIAm]

My guess is that this is just a one-off kind of funny area in the game.

The next haiku actually contains a reference to the Man'yoshu. Oh boy.

EDIT: Ooh, the one after that is a reference to this one! A haiku classic!

古池や
蛙飛び込む
水の音

Donald Keene's translation:
The ancient pond
A frog leaps in
The sound of the water.

Also, Reginald Horace Blyth's translation:
The old pond.
A frog jumps in.
Plop!

[NightWolve]

Hey Sam, I think I should warn you about something. I've made great progress with Emerald Dragon so the project can go forward with now having a good handle on it and with David's recompression code from Ys IV working! But, in working on the first text block, I see that we will have problems fitting in your translated results. The LZSS text codec will not cut it for the amount of English text that you wrote...

When I started, the text block compressed ~4,000 bytes in excess of the space allocated (the allocated block is 4,175 bytes, and it needed ~8000 bytes initially!). This is 101 strings, and so the last 40 were blanked out to "T\pause\0" temporarily so that I could shrink it and recompress it to fit, just get something working and visible for testing/learning! The process since then has been editing your results down, examples as follow:

** Logical trimming with context. She's standing right in front of the town, next to the Town of Ulwan sign.

[07]Young Girl<\r>
No, I'm not Tamryn.<\p> If<\r>
you're looking for her, you<\r>
might try up in the Town of<\r>
Ulwan.<\p><\0>

[07]Young Girl<\r>
Ulwan is just right over<\r>
there.<\p> Just walk straight<\r>
north and you should<\r>
reach it.<\p><\0>

[07]Young Girl<\r>
No, I'm not Tamryn but you<\r>
might find her here.<\p><\0>

[07]Young Girl<\r>
This is the Town of Ulwan.<\r>
Just head north.<\p><\0>

** This idea we're definitely gonna have to do: Since you are talking to the character that's perfectly visible throughout the message boxes that appear, you only need to state their name or description on the first line once!

[07]<YELLOW>Lady<WHITE><brk><\r>
That Heretic <GREEN>Bagin<WHITE> is a<\r>
terrible man.<\p><\0>

[07]<YELLOW>Lady<WHITE><brk><\r>
10 years ago, he left his<\r>
own child somewhere and he<\r>
almost never visits her...<\p><\0>

[07]<YELLOW>Lady<WHITE><brk><\r>
In fact, he won't even let<\r>
her call him "father."<\p><\0>

[07]<YELLOW>Lady<WHITE><brk><\r>
"The Heretics Way" seems to<\r>
mean isolating yourself from<>
the rest of us.<\p><\0>

[07]<YELLOW>Lady<WHITE><brk><\r>
That Heretic <GREEN>Bagin<WHITE> is a<\r>
terrible man.<\p><\0>

[07]10 years ago, he left his<\r>
own child somewhere and he<\r>
almost never visits her...<\p><\0>

[07]In fact, he won't even let<\r>
her call him "father."<\p><\0>

[07]"The Heretics Way" seems to<\r>
mean isolating yourself from<>
the rest of us.<\p><\0>

** The other idea is something your programmer EsperKnight would probably have no problem implementing. It's a basic compression idea from David that can be accomplished with the hacking of the print routine. It's based on the fact that 20-30% of a script is space characters. So, take this example string:

Text Input: "TheBoyWentToTheStore."

With some recoding in the print routine, a simple algorithm is implemented to lowercase and interpret a space character need based on a previous letter being lowercase and the next one being uppercase.

1) Read character.
2) If uppercase, check if previous char is lowercase. If false, print normally. If true, print space character, lowercase the current char, then print it.
3) LOOP/REPEAT TILL CHAR = 0x00.

So, with that basic hack to the print routine, the previous ASCII input is outputted to this:

Display Output: "The boy went to the store."

The LZSS codec will have 20-30% less text to compress as a result of this! Now, I'm not saying for sure this would be needed, you might get away without it, but if you can't, I'm putting the idea out there so you can pass it along to him... I'm not 100% sure I'll need it for Emerald Dragon, I'll find out soon enough, but yeah. It's a good, simple idea and it's possible to implement if enough of the S-JIS processing code in the print routine is overwritten with new code to do it!

The bottomline of my warning here was you need to be thinking about how to say just about the same thing with less words... I dunno if you've ever gotten to the post-editing phase with any of your projects with him, and maybe you just wanted to cross that bridge when you get to it, but just FYI, I have A LOT of trimming to do for this first text block with Emerald Dragon! I don't know if I can implement that space compression idea, I might try when I track down the print routine. I can definitely get rid of the 0x07 font switch code for going to 8x12 mode, and not having to use the code with every string! That'll save me 101 bytes for this 1st text block (7,357 bytes considering the whole script), so that's a start! The biggest savings is of course not repeating the name/description of a character every time they speak! So yeah, things to consider for your other projects. Anyway, stay tuned for an upcoming progress update for ED in my thread!

[SamIAm]

You know, these days Bonknuts in particular has been talking seriously about making a new system card with expanded RAM for translations. You should get in touch with him.

This was just made public recently on krikzz's forums, but there is going to be a v2.0 Turbo Everdrive coming soon that uses RAM instead of flash memory. This just might do the trick. Even if it doesn't, it really shouldn't be too hard to make a new card with 512k of memory. That would make an enormous difference, needless to say.

http://krikzz.com/forum/index.php?topic=2670.0

Thanks for all your work! Editing down the wordcount is always a good idea regardless of how much space is available, and I would certainly be willing to look into that. Anyway, with a little luck, memory itself won't be a problem.

[NightWolve]

http://krikzz.com/forum/index.php?topic=2670.0

Ah man, now I gotta sell this thing... He says he already has a working sample:

http://krikzz.com/forum/index.php?topic=2670.msg26815#msg26815

$72 bucks down the tubes on the current version... Can't believe this, thought he was just done with the system and his flashcart for it...

Now nullity's laughing at our group buy of 20 for the current version is far more applicable.

http://www.pcenginefx.com/forums/index.php?topic=18127.msg382039#msg382039

Gotta sell it while it's still in good, new condition... What a drag...

[elmer]

The LZSS text codec will not cut it for the amount of English text that you wrote...

I've never done this kind of post-mortem translation, only with-source translation, so I may be way out of line here, but ... I've got to ask ... is the problem the lack of compressed space, or the decompressed space?

If it's the decompressed text that's too large, then it's time for the nasty stuff like you're mentioning ... or perhaps plain old packed-6-bit ASCII.

If it's the compressed space, then there are lots of better text compressors than plain-old-LZSS if that's what they're using ... and you could fit such a decompressor into a few hundred bytes.

The LZSS codec will have 20-30% less text to compress as a result of this!

Since LZSS is looking for common patterns ... that's not necessarily a win, and can possibly be a lose in the compressed data.

[spenoza]

As much as I love the idea of a new system card that expands the system's RAM, I would hate to see people start falling back on that as a solution, because it really limits how many can appreciate the work that goes into a translation. We have enough keen minds around here that I think we can come up with reasonable solutions without going that route in most cases.

[SamIAm]

I don't like it either, but honestly, some translations are never going to happen without a new system card. It's the way it's gotta be.

[elmer]

I don't like it either, but honestly, some translations are never going to happen without a new system card. It's the way it's gotta be.

If you are open to increasing the hardware requirements of the game ... is there some reason that you can't just make the existing Arcade Card a requirement instead of needing some never-been-seen-before-product?

Yes, I know that the Arcade Card isn't just regular-accessible  RAM ... but it is still RAM, and using it shouldn't require that much hacking. After all, string printing is pretty-much a one-character-follows-the-last kind of thing that's perfect for reading from the Arcade Card's auto-incrementing port.

Or just copy a string at a time from the Arcade Card's RAM to regular RAM before printing it.

What am I missing?

[SamIAm]

You'll have to talk to Bonknuts about that, since he's sort of the low-level hacking expert around here. I just do Japanese to English. What I remember is that he said he wants to be able to execute code directly from the RAM, not just retrieve text, but I could be off.

[NightWolve]

I've never done this kind of post-mortem translation, only with-source translation, so I may be way out of line here, but ... I've got to ask ... is the problem the lack of compressed space, or the decompressed space?

It's recompressing English text and overwriting the old Japanese text block. The first block I'm working with has 4,175 bytes allocated. When I compressed Sam's English text for that block, the result was ~8,000 bytes. Thus, it cannot fit, I must edit it down, trim where needed, come up with other ideas, maybe ask David to see if further improvement can be made to his recompression code, etc.

If it's the compressed space, then there are lots of better text compressors than plain-old-LZSS if that's what they're using ... and you could fit such a decompressor into a few hundred bytes.

That's a bad idea, not worth it and it's beyond the scope for someone of my experience to do. The same codec in the game is typically used for graphics blocks (e.g. Ys IV), so you would have to find all of them in the game, and recompress them with your new codec... Bad idea certain to introduce bugs and long work time on the project...

Since LZSS is looking for common patterns ... that's not necessarily a win, and can possibly be a lose in the compressed data.

I would agree if you were getting rid of random characters. But in this case you're always getting rid of the same 0x20 space character, so I think the vast majority of the times it would result in a smaller compressed size. Maybe not 30%, but even 5-10% would be worth it.

[elmer]

It's recompressing English text and overwriting the old Japanese text block. The first block I'm working with has 4,175 bytes allocated. When I compressed Sam's English text for that block, the result was ~8,000 bytes. Thus, it cannot fit, I must edit it down, trim where needed, come up with other ideas, maybe ask David to see if further improvement can be made to his recompression code, etc.

Thanks for the explanation, I appreciate you taking the time to help dispel my ignorance.

OK, so the original developers hard-allocated all the decompression space that they needed for the original text ... and you can't mess with that without making major changes to the code and introducing lots of bugs.

That's eminently sensible on your part, and a reasonable thing to do on their part (although a lot of Western developers that I know dynamically adjusted their runtime memory layout).

The same codec in the game is typically used for graphics blocks (e.g. Ys IV), so you would have to find all of them in the game, and recompress them with your new codec... Bad idea certain to introduce bugs and long work time on the project...

It would certainly be a lot of extra work ... and from what you say, pointless anyway since the issue that you are having is with the post-load decompressed space.

I would agree if you were getting rid of random characters. But in this case you're always getting rid of the same 0x20 space character, so I think the vast majority of the times it would result in a smaller compressed size. Maybe not 30%, but even 5-10% would be worth it.

It all depends upon the actual LZSS encoding and it's break-even point.

Changing a "<period><space><char>" into a "<period><char>" just changes a potential 3-byte repeat into a 2-byte repeat ... which may not actually have any effect at all on the resulting number of bits used by the LZSS offset-length encoding.

But that's beside the point anyway, since your limitation is actually decompressed space.

A really, really, really nasty hack would be to always put a new decompressor (or modified text-printing code) in at the start of the text when you LZSS compressed it, and then modify the original code to jump to that routine after the LZSS decompression when you needed to print something.

Then you could store the text in that area in whatever format you wished (such as 6-bit-with-escape-code, or 8-bit-with-a-192-entry-common-substring-table).

But it's still not going to magically fit 8000 bytes of uncompressed text into a 4175 byte space.

[SamIAm]

There's definitely some fat in my translation, and I think we could make some significant reductions without damaging any meaning. However, if the task is to cut the length in half, then losing some major detail will be inevitable.

Let's see what this 2.0 Everdrive can do.

[NightWolve]

Hm, just to be clear, the issue is the old compressed blocks of text, the space that was allocated for them. It's not an issue with the decompresion buffer or something. I do have compressed blocks that are contiguous to each other and David found the 16-bit pointers to them, so I do have an additional option of packing final recompressed blocks into each large contiguous block by recomputing the pointers. That'll be a last resort, we'll see how it goes.

Changing a "<period><space><char>" into a "<period><char>" just changes a potential 3-byte repeat into a 2-byte repeat ... which may not actually have any effect at all on the resulting number of bits used by the LZSS offset-length encoding.

Some cases yes, sure, some cases no. I have to run some tests. Compress the block with spaces, and do it again with this idea, and see what happens. It's easy enough to test out the theory and see how well it works beforehand.