OMG! ZIRIA! ZIRIA!! ZIRIA!!! IT ACTUALLY HAPPENED!! 34 YEARS LATER!! The epic/legendary Tengai Makyou/Far East of Eden: Ziria JRPG has finally been localized! Supper the Subtitler struck again! Simply unstoppable, NOTHING can prevent him from TOTAL PCECD localization domination!!!! WHACHA GONNA DO BROTHER?!?!
Main Menu

Xanadu II Translation Development Blog

Started by elmer, 08/31/2015, 11:50 AM

Previous topic - Next topic

0 Members and 7 Guests are viewing this topic.

elmer

From the "System Card Dreams" thread ...

Quote from: elmer on 10/25/2015, 09:51 PMI could make the Xanadu translations require extra memory in order to create a market ... and it would definitely make my job easier. But that doesn't seem like a nice thing to do, even if it might slightly lower the chance of a PCEWorks boxed-set.
For anyone that's reading through both these threads, I though that I'd explain how this would make things easier ...

If I had another 256KB RAM on a "Translation Card", then I'd just load Xanadu's META_BLOCKs directly into the extra RAM.

That would avoid the need to change the game's compressor to a new one, and SamIAm's translations could be as-big-as-they-need with little effort on my part.

The extra RAM would also make it easy to solve the space-in-the-game problem for the decompressed English scripts, and also give me plenty of room for English fonts and a new VFW font routine.

These are things that would save me a fair amount of time-and-effort in getting the translation done.

The downside would be that then the META_BLOCKs wouldn't fit onto the CD anymore.

That can be solved by increasing the size of the ISO ... but it does show that there's no quick-fix that doesn't have consequences, and we're just moving programmer-effort from one problem into a different one.

Now ... if I wasn't able save memory by switching the compressor, then having this extra memory would be the only way that you'd get a decent translation.

Food-for-thought.  :-k

OldMan

Quotethere's no quick-fix that doesn't have consequences,
There never is <lol>. It's always a trade-off :)

A very silly question: Would it be possible to load the meta-blocks 'on the fly' from the cd? Or are they dependant on each other? (ie, block A calls block B such that both have to be in memory at once)

TurboXray

There's lot of free space in the ISO track - you don't need to expand it. It might look full, but there are lots of segments of left over 16bit PCM data in there. If you open the ISO track into a view than can interpret all data as PCE sprite format, you'll see that 16bit wave files have a very unmistakably unique signature to them. I usually run TMOD2 under dosbox (runs in XP too, but not on my win7 setup), with Dshadoffs PCE plugins for it.

elmer

#103
Quote from: TheOldMan on 10/26/2015, 01:14 PMThere never is <lol>. It's always a trade-off :)
Haha .. "yep", such is the life of a programmer ... or an electrical engineer, or most "design" jobs for that matter.   :wink:


QuoteA very silly question: Would it be possible to load the meta-blocks 'on the fly' from the cd? Or are they dependant on each other? (ie, block A calls block B such that both have to be in memory at once)
AFAIK Xanadu 1 just loads a single large META_BLOCK (176KB max size) for each game level.

That's a mix of graphics and code and script.

For instance, the 1st level's META_BLOCK is 160KB large and contains 71 individual DATA_CHUNKs, only 13 of which actually contain Falcom's script-language data.

In order to "split" that into 2 META_BLOCKs and dynamically swith between them, I'd have to totally understand exactly what's going on inside each of the 71 DATA_CHUNKs, and to then copy the ones that are needed for each of the 2 new META_BLOCKs, and also fix up the code/script in each to use the new DATA_CHUNK indexes.

Then I'd also need to understand the game well enough to hack in this dynamic-loading system, and to trigger it in places that won't break anything.

I suspect that it would just be easier to rewrite the game from scratch!

Now Xanadu 2 already implements a dynamic loading system ... that's it's big improvement, and it's why it can afford to use much prettier graphics.

So it's somewhat more possible to split it's META_BLOCKs into 2, but it would still be a major nightmare that would IMHO mean completely reverse-engineering the entire game.

So "possible"? Probably so with enough time and will, but not even slightly "practical" in any sane definition of the word.

Nope ... IMHO in order to get this actually done and not have it die-on-the-vine like the previous attempt, we're going to have to keep the basic structure of the game unaltered, and just change the details (such as the language of the text).

It's going to be the same when it comes to the font code.

While it would be "nice" to change things to use a full VWF ... the structure of the code is going to make that a little awkward.

The first step will be to use the 12x12 English SJIS glyphs in the ROM font, just like EsperKnight did.

It'll be ugly ... but it's just going to be a stop-gap measure to make sure that things don't break.

Then it'll be time to see what's the best way to make it all look nice, and to give SamIAm plenty of room on the screen for his translated text.

But that's really a problem that will get more serious attention when the English scripts are inserting correctly.

elmer

Quote from: TurboXray on 10/26/2015, 01:43 PMThere's lot of free space in the ISO track - you don't need to expand it. ... I usually run TMOD2 under dosbox (runs in XP too, but not on my win7 setup), with Dshadoffs PCE plugins for it.
Thanks for the suggestion!

I've never heard of those tools, and will have to check them out.  :D

It looks like the CD is pretty full on Xanadu 2, so that's great to hear.

They're definitely using fixed intervals for the data in the ISO track, and they didn't clean out all the old stuff in there ... so it'll be good to have some help in identifying what data is just left-over junk.

Xanadu 1 looks to have plenty of space left to just expand the ISO ... but then they could have hard-coded the CD audio locations, which would be annoying.

Either way ... I'm really hoping to avoid having to change any of the data locations at this point.

TurboXray

Here's pic of what 16bit wave files look like in PCE sprite format:
IMG

It's very distinct.


About 99.99999% of PCE game have junk interleaved between the data in the ISO tracks. Sometimes it's other games, or wave files, or even dev stuff (one game has the full source code to it in there along with developers notes, etc). Basically, whatever was on the harddrive at the time got copied into the ISO track.

TurboXray

Here's the link: http://pcedev.net/utils/tmod2_pce_support.zip
If you run it under dosbox, you'll need to set the memory to 64megs. Under XP, I was able to open files as well as 500megs. Under dosbox though, I think my limit was 200-300 megs before the app reported that it ran out of memory. It can have up to 7 files open at once. There's not readme file, so you have to click the "?" icon for how to use the features.

 At some point, I'm going to remake this util in windows (using SDL, with my own internal GUI support). Once you get to know your way around it, it has some really useful functionality.  I'll add more view features though (and control of bitplane orders).

elmer

Quote from: TurboXray on 10/27/2015, 12:09 PMHere's the link: http://pcedev.net/utils/tmod2_pce_support.zip
Thanks for the instructions and the link to the plugins ... I was just going to ask you for that!  :D

TurboXray

Hmm. I think I'm missing the DM files in the module folder of that zip file. I'll re-upload a new zip later. Dave Shadoff's site might have the full version as well.

NightWolve

#109
They're all there, unless you added 'em by the time I looked at it. So tmod with David's PCE plugin is still useful after all these years, huh ? Would've thought something more powerful and Windows-based would've come along by now.

Well, actually, in that vain, FYI, but I found the YYCHR apps are pretty good replacements, though they're developed by Japanese fans. You can still work 'em pretty good as the menus are all English. See if any of these can work for you:

http://www45.atwiki.jp/yychr/
http://www45.atwiki.jp/yychr/pages/23.html
http://www.geocities.jp/yy_6502/yychr/yy-chr20120407.zip

And:

http://www.geocities.jp/yy_6502/
http://www.geocities.jp/yy_6502/yychr/yychr_net.zip

elmer

Time for another update!

The script-assembler is coming along nicely, with around 2,500 lines of C code written so far.

At this point the scripts for both Xanadu 2 and Xanadu 1 are assembling, and the assembler's output is being verified as identical to the original contents of the scripts in the DATA_CHUNKs.

It's not all being tested, yet ... there's still a lot left to do!

But it's all working well enough to do a simple test (using the ugly 12x12 System Card font) and to hack in some SJIS-encoded English text into both games.

That means ...
  • Decompressing the original META_BLOCK from the CD into it's dozens of DATA_CHUNKS.
  • Assembling each of the script files for that META_BLOCK and overwriting the original script data.
  • Recompressing all the DATA_CHUNKSs (FALCOM2 format for Xanadu2, FALCOM1 format for Xanadu 1).
  • Writing the new META_BLOCK out to the CD image.

Here are the modified scripts for each of the games, the translator just adds the new English text underneath the original Japanese text.

When SamIAm gets these, he'll just do the same and then add/remove any extra "_eol()" end-of-line commands to make things look pretty on the screen.

For Xanadu 1 ...

[tt].scriptB35F:
  _set_pen6_then_call_then_eol( .scriptBA2F )
  {うおーっ、船だあっ!!}
  [Xanadu]
  _eol()
  {商人が来たーッ!!}
  [1 Test]
  _wait_for_keypress_then_clear()
  _set_pen6_then_call_then_eol( .scriptBA38 )
  {ポルダ村なんかに負けるか!}
  [Hello,]
  _eol()
  {こっちが先に取り引きするぞっ!!}
  [World! OK]
  _wait_for_keypress_then_end()[/tt]

IMG
IMG


For Xanadu 2 ...

[tt].scriptAB88:
  _modify_script_variable( $01, $10 )
  _enable_8x12_font()
  _set_pen_then_call_then_eol( orange, .scriptAE05 )
  _disable_8x12_font()
  {アリオスさま。いよいよですな。}
  [Xanadu2]
  _wait_for_keypress_then_clear()
  _modify_script_variable( $00, $11 )
  _enable_8x12_font()
  _set_pen_then_call_then_eol( orange, .script9EB7 )
  _disable_8x12_font()
  {うん。}
  _eol()
  {もうすぐリュコスの向かった新大陸か。}
  [Test String]
  _wait_for_keypress_then_clear()[/tt]

IMG
IMG

seieienbu

I love seeing English words in those text boxes.
Current want list:  Bomberman 93

Dicer


elmer

Quote from: Dicer on 11/04/2015, 08:19 PM
Quote from: seieienbu on 11/04/2015, 04:03 AMI love seeing English words in those text boxes.
Ditto!
Sorry, guys, I know that it's pretty underwhelming after nearly 3 months, but this is one complex swine of a game to hack!

I was going nuts, doing all this work with nothing visible to see ... and so felt the need to get something on the screen, even if it's only a "nasty" hack.  :oops:

The whole issue of "motivation" when the task is seeming really, really tough is definitely something to "blog" about at some point.

I only recently read the whole thread from SamIAm & EsperKnight's original attempt to get the game translated, and it was heartbreaking to see how happy everyone was ... and then how it just fizzled out and died.

It's easy (for me, now) to see why poor EsperKnight ran into problems, and why his approach was doomed; and it's taken a long time to do it all "properly" so that I can have some confidence that the technical issues are solved.

I can only imagine just how frustrated and de-motivated EsperKnight must have felt, to have put in all the hard work that he did, only to see everything start to break when SamIAm's translated scripts were first being re-inserted into Xanadu 2.  :(

***********************

As for this hack ... I'm happy to say that the script-assembler is now approx 3,000 lines of C code, and is verified to be compiling the original scripts with 100% accuracy, including all the script parameters and address fix-ups.  :)

I'm confident enough that I've passed the first set of Xanadu 1 scripts on to SamIAm for translation.

TurboXray

Nice! Also, my condolences to your free time and sanity ;)

elmer

OK, continued on from the main Xanadu translation thread ...


IMG


Quote from: elmer on 11/09/2015, 07:39 PMI'm guessing that the outlined font was their "default" because dynamically making the ROM font "bold" and giving it an outline is a pretty-damned-clever programming effect (IMHO).

Does anyone know of another PCE CD game that does that with the ROM font?
Quote from: TurboXray on 11/09/2015, 07:53 PMI seem to recall a couple of other late gen games that might have done that.
I'd love to know what the games are so that I can check them out.

I've really not seen Xanadu 1's "bold" font effect done this well before.

It's not a simple pixel-doubling, because it actually keeps some of the details in the font that that would overwrite.

It's almost like they specifically detecting on-off-on pixel patterns and making sure that the "off" is preserved.

It's cool (IMHO). I was amazed at how well their algorithm coped with the narrower English font.

The programmer screwed-up the black outline pass after that ... but that should be easy to fix.

NightWolve

Quote from: elmer on 11/09/2015, 08:27 PMOK, continued on from the main Xanadu translation thread ...
IMG
Oh wow, you got a font hack going already! MUCH BETTER! :)

Reminds me, Nulltard once made a post that SamIAm+Bonknuts=:
this/forum/index.php?topic=9456.msg36877

But, he was wrong, not the first time either! ;)

SamIAm + elmer = IMG

TurboXray

Finally! I can't retire from all things translations. I've waited so long... ;_; ... . . :mrgreen:


f(x)=SamIam^3 + 2^elmer...

f'(xanadu)=3SamIam^2 + (2^elmer)*ln(2)..IMG

NightWolve


dshadoff

Quote from: elmer on 11/09/2015, 08:27 PM
Quote from: elmer on 11/09/2015, 07:39 PMI'm guessing that the outlined font was their "default" because dynamically making the ROM font "bold" and giving it an outline is a pretty-damned-clever programming effect (IMHO).

Does anyone know of another PCE CD game that does that with the ROM font?
Quote from: TurboXray on 11/09/2015, 07:53 PMI seem to recall a couple of other late gen games that might have done that.
I'd love to know what the games are so that I can check them out.

I've really not seen Xanadu 1's "bold" font effect done this well before.
Well, later games did a bunch of things with fonts:

- Koei (and others) made their own font instead of using system font

- lots of games started using multiple different fonts in different spots

- hang-shadows were used in lots of games, but not necessarily on all text (Tokimeki Memorial seems to have this).  This is done by taking the orginal font, shifting it right one pix and down one pix, and printing it in black. Then white (or whatever color) on top of that, without shift.  All on transparent background, so both the black and foreground colors are apparent.

- I think Riverhill (Gunbuster) might have just doen a bold effect on some text by shifting right and blending.

- several companies all added large amounts of text as graphics splashes instead of font/text.

elmer

Quote from: elmer on 11/04/2015, 09:33 PMAs for this hack ... I'm happy to say that the script-assembler is now approx 3,000 lines of C code, and is verified to be compiling the original scripts with 100% accuracy, including all the script parameters and address fix-ups.  :)
Now that it's basically "done", and relocating scripts as the English translations make them overflow their original space, it's approx 3,500 lines of C code. Phew!  ](*,)


Quote from: NightWolve on 11/09/2015, 10:29 PMSamIAm + elmer = IMG
Hahaha!   8)

I think that SamIAm is the metal dude ... and I'm just full of the "hot air" in the background.  :wink:


Quote from: NightWolve on 11/09/2015, 10:29 PMOh wow, you got a font hack going already! MUCH BETTER! :)
I'm happy with the results ... but it's an embarrassingly small hack, just like Team Innocent.

It's really just filling the game's glyph buffer with my font data instead of the ROM font data, and then modifying the cursor increment.


[tt]; ***************************************************************************
;
; Get the 8x12 ASCII glyph data (replaces call to EX_GETFNT).

bank_font equ $84

get_acsii_glyph:
        lda   <_al
        sec
        sbc   #$20

        stz   <_bl
        asl   a
        rol   <_bl
        asl   a
        rol   <_bl
        sta   (.smod + 1)
        ldy   <_bl
        asl   a
        rol   <_bl
.smod:  adc   #$00
        sta   (.loop + 1)
        tya
        adc   <_bl
        adc   #high($a000)    ; Font is 256-byte aligned, at $a000.
        sta   (.loop + 2)

        tma   #$05
        pha
        lda   #bank_font
        tam   #$05

        ldy   #11             ; Font data is 12-bytes (0-11).
        ldx   #22             ; Copy it as 16-bit wide.
.loop:  lda   $0000,y
        sta   $280a,x
        stz   $280b,x
        dex
        dex
        dey
        bpl   .loop

        pla
        tam   #$05

        rts


; ***************************************************************************
;
; Increment the text cursor by one or two 4-pixel steps.

inc_text_cursor:
        lda   <_ah            ; Hi-byte of glyph code from EX_GETFNT.
        bne   .double
        lda   <_al            ; Lo-byte of glyph code from EX_GETFNT.
        bmi   .double
        sec
        sbc   #$20
        bcc   .double

        tax
        lsr   a
        lsr   a
        lsr   a
        sax
        and   #$07
        tay
        lda   idx2msk,y
        and   tbl8x12,x
        beq   .single

.double:inc   $2805
.single:inc   $2805
.done:  rts

idx2msk:.db   $01, $02, $04, $08, $10, $20, $40, $80

tbl8x12:.db   $7D ; 01111101
                  ; '&%$#"!

        .db   $AF ; 10101111
                  ; /.-,+*)(

        .db   $FF ; 11111111
                  ; 76543210

        .db   $F3 ; 11110011
                  ; ?>=<;:98

        .db   $FF ; 11111111
                  ; GFEDCBA@

        .db   $FD ; 11111101
                  ; ONMLKJIH

        .db   $FF ; 11111111
                  ; WVUTSRQP

        .db   $FF ; 11111111
                  ; _^]\[ZYX

        .db   $FE ; 11111110
                  ; gfedcba`

        .db   $E9 ; 11101001
                  ; onmlkjih

        .db   $FF ; 11111111
                  ; wvutsrqp

        .db   $FF ; 11111111
                  ;  ~}|{zyx [/tt]


Quote from: TurboXray on 11/09/2015, 11:29 PMFinally! I can't retire from all things translations. I've waited so long... ;_; ... . . :mrgreen:
Haha ... you don't get off that easily!  :wink:

Just like you, I'd much rather be writing new code than hacking around in someone's old code.

I'm hoping that you'll want to do Anearth Fantasy Stories with SamIAm when you've got the time.

The community needs to keep him busy ... it's rare to find someone with his combination of passion and capability.  :D

elmer

#121
Quote from: dshadoff on 11/10/2015, 12:48 AMWell, later games did a bunch of things with fonts:

- Koei (and others) made their own font instead of using system font

- lots of games started using multiple different fonts in different spots

- hang-shadows were used in lots of games, but not necessarily on all text (Tokimeki Memorial seems to have this).  This is done by taking the orginal font, shifting it right one pix and down one pix, and printing it in black. Then white (or whatever color) on top of that, without shift.  All on transparent background, so both the black and foreground colors are apparent.

- I think Riverhill (Gunbuster) might have just doen a bold effect on some text by shifting right and blending.

- several companies all added large amounts of text as graphics splashes instead of font/text.
Thanks for the list.  :)

I'm not really talking about custom fonts or text that's built into graphics ... what really interests me is developers that did unusual "real-time" processing of the font data.

"Hang-shadows" aka "drop-shadows" were the most common effect that's used almost-everywhere.

"Outlines" are another common and easy-to-do effect ... especially when the text is a layer on top of a moving background.

I'll have to take a look at Gunbuster and see what it's doing.  :-k

Xanadu 1's "bold" really sparks my curiosity because someone had the smart idea of how to preserve the small details in the font.  =D&gt;

Take a look at these examples ...


     Original    Double      Xanadu      Outline

01   .........   .........   .........   .OO......
02   .X.......   .XX......   .XX......   O..O.....
03   .X.......   .XX......   .XX......   O..O.....
04   .X.......   .XX......   .XX......   O..OOOO..
05   .X.XXX...   .XXXXXX..   .X.XXXX..   O.O....O.
06   .XX...X..   .XXX..XX.   .XXX..XX.   O...OO..O
07   .X....X..   .XX...XX.   .XX...XX.   O..OOO..O
08   .X....X..   .XX...XX.   .XX...XX.   O..O.O..O
09   .X....X..   .XX...XX.   .XX...XX.   O..O.O..O
10   .X....X..   .XX...XX.   .XX...XX.   O..OOO..O
11   .XXXXX...   .XXXXXX..   .XXXXXX..   O......O.
12   .........   .........   .........   .OOOOOO..

     Original    Double      Xanadu      Outline

01   .........   .........   .........   ......OO.
02   ......X..   ......XX.   ......XX.   .....O..O
03   ......X..   ......XX.   ......XX.   .....O..O
04   ......X..   ......XX.   ......XX.   ..OOOO..O
05   ..XXX.X..   ..XXXXXX.   ..XXX.XX.   .O...O..O
06   .X...XX..   .XX..XXX.   .XX..XXX.   O..OO...O
07   .X....X..   .XX...XX.   .XX...XX.   O..O.O..O
08   .X....X..   .XX...XX.   .XX...XX.   O..O.O..O
09   .X....X..   .XX...XX.   .XX...XX.   O..O.O..O
10   .X....X..   .XX...XX.   .XX...XX.   O..OOO..O
11   ..XXXXX..   ..XXXXXX.   ..XXXXXX.   .O......O
12   .........   .........   .........   ..OOOOOO.



Xanadu's "bold" processing preserves the blank "." pixel where round part of the "b" and "d" join the stem on line 05.

That really helps to preserve the roundness of the original glyph and IMHO is vital to making the "bold" effect look good.

When you look carefully at the difference between the "b" and the "d", you can analyze how they must be doing it.

From what I can see, they're shifting the original data right by 1 pixel and then "or"ing it back in to produce the "double" version.

Then they're looking for "X.X" sequences in the original data and making sure to clear any "." pixels like that from the "double" version.

That's probably as simple as ...

        lda   font_data,y     ; Double the font data.
        lsr   a
        sta   (.and + 1)
        or    font_data,y
        sta   (.msk + 1)

        lda   font_data,y     ; Mask out the "0" pixel
        asl   a               ; data in "101" sequences.
.and:   and   #$00
        eor   #$ff
        or    font_data,y
.msk:   and   #$00
        sta   bold_data,y


Now I'm going to actually take a look at their code and see if they're actually doing it any more efficiently than that.  :wink:

TurboXray

Quote from: elmer on 11/10/2015, 02:48 PM
Quote from: TurboXray on 11/09/2015, 11:29 PMFinally! I can't retire from all things translations. I've waited so long... ;_; ... . . :mrgreen:
Haha ... you don't get off that easily!  :wink:

Just like you, I'd much rather be writing new code than hacking around in someone's old code.

I'm hoping that you'll want to do Anearth Fantasy Stories with SamIAm when you've got the time.

The community needs to keep him busy ... it's rare to find someone with his combination of passion and capability.  :D
SamIam is probably more valuable than any of us hackers. It's hard to find a good translator that wants to do PCE translations. Everything in the translation scene is soo Nintendo centric, or counter-nintendo centric (sega stuff), or just plain out skips this generation (PS2, etc). When it comes to RPGS, it's like the PCE is the system no one wants to touch (outside of niche communities that surround it).

 To be honest, Dead of the Brain should be finished. It's almost there. The script was dumped, Dave made tools for script insertion, the font routine works (with some odd ball convoluted support needed to prop it up). And the translator has been sitting in this for years. I would hate to start anything new when other projects are so close.

 I always held this idea that a community could work on projects as a whole.. a team. Members might come and go, but if the translation process is organized enough - people can pick up where others have left off.

 Cosmic Fantasy I has a working font routine; Dave figured out the script format. That just needs a translation. Stuff like that.

SamIAm

#123
I don't know whether I am really more valuable than any hackers, but I am all in favor of being kept busy.

It really takes two to tango, unless you're some freak of nature who can hack and translate and find the time for both. I'm pretty useless by myself.

Also, morale is critical during projects like these, and knowing that the other guy is working his tail off too is critical. The fact that elmer has been doing amazing work motivated me to squeeze in four hours of translating today...and I hope that fact is motivating to elmer.  :wink:

elmer

Quote from: SamIAm on 11/12/2015, 09:52 AMAlso, morale is critical during projects like these, and knowing that the other guy is working his tail off too is critical. The fact that elmer has been doing amazing work motivated me to squeeze in four hours of translating today...and I hope that fact is motivating to elmer.  :wink:
Definitely!  :wink:

I've been feeling guilty that SamIAm has been working so hard on the translation, and that I've been "playing" with the Turbo Everdrive 2.

The reason is that I got the complete 1st-draft of the 1st-level of Xanadu 1 and tried to insert it into the game ... and it immediately ran out-of-memory on the very first script chunk in the game.

So that meant that I've got to implement the entire game-recompression and decompressed-script-overflow code before we can move forward.

Yuk! That's a lot of work.  #-o

That really brought up the question of whether we even have any good alternative to use if the translation needs extra RAM, or whether it would then be Mednafen-only (or CD Stupid Card for those of us lucky enough to have them).

Well, after a lot of messing around (as documented in various other threads), it looks like the Turbo Everdrive 2 is definitely going to be an alternative that people can actually go out and buy if there are any CD translations/homebrew in the future that need extra RAM above-and-beyond the 256KB that the Super System Card provides.

There's also the possibility of TheOldMan's 512KB ROM/RAM card that he's designing, or the mythical 1MB-RAM card that I've been thinking about ... but the Turbo Everdrive 2 actually exists, and can be purchased, and is a really nice card (if a little bit more expensive than some people would like).

So, with that concern out of the way, now it's time to get back to Xanadu!  :)

MNKyDeth

Was it stated earlier that the Arcade Card Duo/Pro are not viable options in this scenario Elmer? Or could we use those for those of us that have them?

spenoza

Elmer has brought up in multiple threads, on multiple occasions, why the Arcade Card standard is not effective/appropriate for this.

MNKyDeth

Quote from: guest on 11/27/2015, 02:16 PMElmer has brought up in multiple threads, on multiple occasions, why the Arcade Card standard is not effective/appropriate for this.
Ok, thank you.

I think I remember reading something on it but wasn't for sure.

I recently bought both of these games and have them now mostly because of this project. I also have a 2.4 TED enroute so I should be good to go hopefully soon. I am just excited for this project as I have always heard good things about the Xanadu games.

CrackTiger

Quote from: MNKyDeth on 11/27/2015, 02:24 PM
Quote from: guest on 11/27/2015, 02:16 PMElmer has brought up in multiple threads, on multiple occasions, why the Arcade Card standard is not effective/appropriate for this.
Ok, thank you.

I think I remember reading something on it but wasn't for sure.

I recently bought both of these games and have them now mostly because of this project. I also have a 2.4 TED enroute so I should be good to go hopefully soon. I am just excited for this project as I have always heard good things about the Xanadu games.
You can play just the action/boss sequences of both games through the debug modes in the meantime.
Justin the Not-So-Cheery Black/Hack/CrackTiger helped Joshua Jackass, Andrew/Arkhan Dildovich and the DildoPhiles destroy 2 PC Engine groups: one by Aaron Lambert on Facebook, then the other by Aaron Nanto!!! Him and PCE Aarons don't have a good track record together! Both times he blamed the Aarons and their staff in a "Look-what-you-made-us-do?!" manner, never himself nor his deranged/destructive/doxxing toxic turbo troll gang which he covers up for under the "community" euphemism!

elmer

Quote from: MNKyDeth on 11/27/2015, 01:57 PMWas it stated earlier that the Arcade Card Duo/Pro are not viable options in this scenario Elmer? Or could we use those for those of us that have them?
I'm still hoping to avoid needing the extra RAM ... but Xanadu 2 is the game that's probably going to cause the most trouble.

That's because its FALCOM2 compression is already doing a good job, and so the amount of memory that I get back by switching to SWD4 or SWD5 is going to be less than with the FALCOM1 compression on Xanadu 1.

I think that I'm going to need quite a bit of extra space for the compressed translations, and I've also got to free up 8KB for the decompressed translation.

Let's just hope that everything fits, and that we don't need the extra memory.

elmer

Time for an update ...

As you, Dear Reader, may have seen, the font hacks that I took screen grabs of a few weeks ago are now properly integrated into the CD on both Xanadu 1 and Xanadu 2.

That's taken a fair bit of behind-the-scenes messing around to actually locate/extract the different code overlays for both games and then put together a PCEAS framework to let me modify them all and then reinsert them into the CD image.

Part of that has involved the discovery of how both games actually locate the files that they're loading from CD.

***************

They're both using a 2KB "directory" structure that's loaded as part of the IPL sectors and is then kept permanently in memory.

They're then referring to files by a 2 byte code when they want to load them ...

The 1st byte is a file type "X" for executable, "Z" for compressed META-BLOCK, and "A" for something else (presumably audio).
The 2nd byte is a binary number, and seemingly refers to the game section.

For instance, in Xanadu 1, the "Main Menu" is actually made up of 3 files "X00", "A00" and "Z00".

It also makes it really clear that there's a single "game" overlay, and 12 different sets of META-BLOCKs for each level ...

"X10", "Z10", "Z11", "Z12", "Z13", "Z14", "Z15", "Z16", "Z17", "Z18", "Z19", "Z1A", and "Z1B".

It's an interesting discovery ... and I wish that I'd found it a long time ago.

Having a list of files like this makes it a lot easier to see how the game is put together.

It also shows that there's a lot of the game that we've not touched at all, yet!

***************

One nice side-effect of finding where the directory structure actually lives when it's loaded into in memory, is that there's enough free space in that bank for the English font, rather than just putting it in the space that I'm freeing up by recompressing the game data.

That's going to be really important on Xanadu 2, because the META-BLOCKs in that game just won't shrink down as much, and I'm already worried if there's going to be enough memory.

***************

Which leads on to the compression/decompression.

I've got a 1st-version of the SWD5 decompressor for the PCE, and I've managed to squeeze it down into being a few bytes shorter that the FALCOM1 decompression code, so it can just live in the same location and overwrite the old code.

I've also hacked the SWD5 format so that it can automatically decompress some data into a different block after it decompresses a script chunk.

That seems like the easiest way to get the game to allow SamIAm's translated script chunks to expand in size and overflow into the space that we're creating by recompressing all those game files.

Now that I've found the directory structure, I'm in the position of being able to rewrite all those old files in the new compression format ... and hope that it all doesn't just blow-up!  [-o&lt;

That's the next task.

***************

Anyway, for anyone that's interested in a challenge, here are the directories for Xanadu 1 & 2.

See if you can guess which groups of files are for the Main Menu, the Cinemas, the Top-Down Game, the Side-Scrolling Game, the Boss fights, etc.  :wink:

***************

Xanadu 1 Files ...

X00, A00, Z00,
X01, Z01,
X02, Z02,
X03, Z03, A03,
X04, Z04, A04,
X05, Z05, A05,
X06, Z06, A06,

X10, Z10, Z11, Z12, Z13, Z14, Z15, Z16, Z17, Z18, Z19, Z1A, Z1B,

X30,
Z30, A40, A50, A60,
Z31, A41, A51, A61,
Z32, A42, A52, A62, A72, A82,
Z33, A43, A53, A63,
Z34, A44, A54, A64,
Z35, A45, A55, A65,
Z36, A46, A56, A66,
Z37, A47, A57, A67,
Z38, A48, A58, A68,
Z39, A49, A59,
Z3A, A4A, A5A, A6A, A7A,
Z3B, A4B, A5B,
Z3C, A4C, A5C,

X20, Z20, A20,
X21, Z21, A21,
X22, Z22, A22,
X23, Z23, A23, A33,
X24, Z24, A24,
X25, Z25, A25,
X26, Z26, A26,
X27, Z27, A27,
X28, Z28, A28,
X29, Z29, A29,
X2A, Z2A, A2A,
X2B, Z2B,


***************

Xanadu 2 Files ...

XF0, ZF0,

X10, Z90, Z0F, A0F,

Z00, Z01, Z02,
Z10, Z11, Z12, Z13, Z14, Z15, Z16, Z17,
Z20, Z21, Z22, Z23, Z24, Z25, Z26, Z27,
Z30, Z31, Z32, Z33, Z34, Z35, Z36, Z37,
Z40, Z41, Z42, Z43, Z44, Z45, Z46, Z47, Z48, Z49,
Z50, Z51, Z52, Z53, Z54, Z55, Z56, Z57,
Z60, Z61, Z62, Z63, Z64, Z65, Z66,
Z70, Z71, Z72, Z73, Z74, Z75, Z76,
Z80, Z81, Z82, Z83, Z84, Z85,

A15,
A20, A24, A25, A26,
A35,
A41, A42,
A51,
A60,
A70, A74, A75,
A82,

XA0,
Z98, A98,
Z99, A99,
Z9A, A9A,
Z9B, A9B,
Z9C, A9C,
Z9D, A9D,
Z9E, A9E,
Z9F, A9F,
ZA0, AA0,
ZA1, AA1,
ZA2, AA2,
ZA3, AA3,
ZA4, AA4,
ZA5, AA5,
ZA6, AA6,
ZA7, AA7,
ZA8, AA8,
ZA9, AA9,
ZAA, AAA,
ZAB, AAB,
ZAC, AAC,
ZAD, AAD,

AB0, AB1, AB2, AB3, AB4, AB5, AB6, AB7,

XC0, ZC0, AC0,
XC1, ZC1,
XC2, ZC2,
XC3, ZC3,
XC4, ZC4,
XC5, ZC5,
XC6, ZC6,
XC7, ZC7,
XC8, ZC8,
XC9, ZC9,
XCA, ZCA,
XCB, ZCB,


***************

TurboXray

elmer, you definitely impress me.. lol

You should put up a public blog site of these two projects, so people outside this forum can see your progress.

elmer

Quote from: TurboXray on 12/01/2015, 10:43 PMYou should put up a public blog site of these two projects, so people outside this forum can see your progress.
Nah, I can't be bothered. IMHO, the folks here are the ones most interested in the PC Engine (except, maybe, for that one French forum that I keep on forgetting about).

I'm just making sure that the people here can see that the translation keeps on slowly moving forwards, and that it's not just going to die like it did the last time, and perhaps, to also see just how much work is involved.

Oh ... it's also a chance to be a noisy Old Fart and pontificate about "the good old days" ... hahaha!  :wink:

**********

Since the subject of sound drivers is being talked-about again, I thought that I'd take a quick look at the Xanadu games.

It looks like they're both using Falcom's own proprietary sound driver, and not the one that's built into the System Card.

I'm going to hazard a guess and say that that is probably because it was easier for them to recode their existing PC-88/PC-98 driver to work on the PCE, than get their current music guy(s) to switch to a completely different way of working.

Of course, if it turns out that they were using MML on the PC-98 ... then I'd be totally wrong!   8-[

**********

And since I've also not mentioned it, yet, it's interesting to see that while Xanadu 1 used the System Card's CD routines to load a complete level of data at one time; when it came to Xanadu 2, and the need to quickly switch out large chunks of data as you move around the level, they appear to have abandoned the System Card's routines and are using their own custom code for all the CD loading.  :-k

ccovell

I gotta say that Xanadu I has absolutely fantastic, awesome music.... but the instruments aren't that complex and they don't change all that much.  It's quite typical of a JP computer composition/translation, I think.  Jinmu Denshou (Yaksa) on the PCE has a similar thing going on.  The focus is on polyphony with a lot of sawtooth sounds.

Compare that to Ankoku Densetsu or Dungeon Explorer, where in a lot of situations simple square waves are used, but 2 channels are paired, playing almost the same note.  The phasing between the square waves does all of the heavy lifting to make a powerful sound.

TurboXray

So Xanadu 2 is another later gen PCE game to use custom cd read routines. The system card one isn't that great for running multiple threads of code. I've seen games do it, but it's hack-y. Besides, it's slow too. Only 90k per second transfer bandwidth. The newer routines are at least 122k/sec.

 If you get a chance, see if you can rip the custom cd read part. I have one from Seiya Monogatari that I'd like to compare.

elmer

Quote from: TurboXray on 12/03/2015, 08:18 PMIf you get a chance, see if you can rip the custom cd read part. I have one from Seiya Monogatari that I'd like to compare.
I doubt that I'll have the time to seriously investigate the custom CD routines for a few months, but I can tell you where they are.

Here is the function that loads a code overlay from both Xanadu 1 and Xanadu 2.

You can see that they're almost identical, and that new custom routines are set up to use the same input parameters as the original System Card routines.

All you have to do is to run Xanadu 2, and by the time that you get to the Main Menu, you'll be able to find the new CD read routine at $a807 in bank $84.

Good hunting!


*********************
XANADU 1 LOAD_OVERLAY
*********************

$3308   jsr   $334a     ; _find_file_index

$330b   jsr   $3377     ; _find_file_pos_len

        lda   $02       ; local addr
        sta   $fa
        lda   $03
        sta   $fb
        lda   $01
        sta   $ff

        jsr   $e009     ; ex_cd_read

        sta   $45
        cmp   #$00      ; $00 = OK
        beq   $3328

$3323   jsr   $33a1
        bra   $330b

$3328   rts


*********************
XANADU 2 LOAD_OVERLAY
*********************

$332b   jsr   $3371     ; _find_file_index

$332e   jsr   $339e     ; _find_file_pos_len

        lda   $02       ; local addr
        sta   $fa
        lda   $03
        sta   $fb
        lda   $01
        sta   $ff

        tma   #$20      ; Remap bank $84 into $a000
        pha
        lda   #$1c
        clc
        adc   $203f
        tam   #$20

$3348   jsr   $a807     ; !!! CUSTOM CD LOADING CODE !!!

        pla
        tam   #$20
        rts

elmer

Quote from: ccovell on 12/03/2015, 05:57 PMI gotta say that Xanadu I has absolutely fantastic, awesome music.... but the instruments aren't that complex and they don't change all that much.  It's quite typical of a JP computer composition/translation, I think.  Jinmu Denshou (Yaksa) on the PCE has a similar thing going on.  The focus is on polyphony with a lot of sawtooth sounds.

Compare that to Ankoku Densetsu or Dungeon Explorer, where in a lot of situations simple square waves are used, but 2 channels are paired, playing almost the same note.  The phasing between the square waves does all of the heavy lifting to make a powerful sound.
Thanks for the analysis, I find that very, very interesting.  :D

A pair of slightly de-tuned channels is a great trick for making a wonderful sound.

**************

Just a quick update on the current progress, since I don't have any new pretty pictures to show.

The game seems to be happy to run with SWD5-compressed data instead of the old FALCOM1/FALCOM2 compressed data.

I'm testing the first scripts, and the overflow functionality (that lets the English translations be much larger than the Japanese originals) seems to be working fine.

My changes to the script compiler to allow for that introduced a couple of bugs that's taken a while to fix.

The current annoyance is that the game is stomping all over my English font ... so that place where I've put it isn't as "safe" as I thought.  :roll:

I think that I can free up some memory for the font by optimizing how the CD directory information is stored ... and that's the next task.

So, two steps forward, half-a-step backwards.  ](*,)

elmer

Time for another couple of screenshots ...

IMG
IMG

It's nice to see some progress, but they don't look too impressive when compared to the previous screenshots, do they?

It's just from the first building that you go into when you start the game. Wasn't that already done?

The answer is "No" ... this is actually a major step forward, and one that's taken a lot of invisible time-and-effort.

Let me explain ...


******************

As SamIAm has said in the main thread, in the past couple of weeks I've actually got all of his current translations inserted into the game (the first 5 levels).

My goal is to get to the point that I can just give him a set of insertion tools, and then he'll be able to make small edits and quickly see how they look in the game.

We're still quite a way away from that goal, but now we're one big step closer.

That's because the game has been built like an onion ... with many layers.

The 12 levels (which contain a total of 168 script files) that SamIAm has been translating are at the outer layer.

They're the most important part of the game ... but they often refer to little snippets of script data that are actually stored in the inside the middle layer, the Game Code overlay itself.

The Game Code overlay uses functions that are built into the Boot Code ... the inner layer.

This is a very structured way of putting a game together, but it can be a real PITA to hack.

In contrast, Zeroigar was constructed like a book ... totally separate pages that really didn't refer to each other. It was also a PITA to hack, but in a totally different way.

In Zeroigar, with its 35+ different programs, I'd often have to find/implement similar hacks in all 35+ different programs. But since each one was separate, each hack was independant of the others, and nothing relied on the previous hacks. That is time-consuming and terribly boring to do ... but it's not particularly difficult.

In the Xanadu games, changes can affect each other. That's a more efficient way of doing things, but it's a bit more complicated to manage.

In particular ... the method that I'm using for recompiling the translated scripts, and for handling the overflow that happens because there's not enough room to the English text, and then repackaging everything back into each level's META_BLOCK so that it gets loaded correctly ... well, that just doesn't work for those inner layers.

Modifying the whole process to be able to handle those inner layers is what has taken a lot of time over the last couple of weeks.

In Xanadu 1, nearly all of the item description script data is stored in the Game Code overlay. The name "Arios" is also in there, as are various common scripts such as the generic things that the "Sister" says when you're in a temple.

Interestingly enough ... each level's META_BLOCK also contains a special DATA_CHUNK with up to 8 level-specific custom items that overwrite the default item descriptions in the Game Code overlay when that level is loaded.

It was only a couple of days ago that I found out that those existed, and then tracked down how they were done. We weren't extracting those scripts before ... now we are.

The problems with having all those scripts in the Game Code overlay is that ...
  • there isn't enough memory in the Game Code overlay for the English versions.
  • the scripts in the levels directly refer to the locations of the scripts in the code.
That's meant that I've had to figure out both how to load up the extra data for the translations, and also how to tell all the level scripts that the Game Code scripts have moved to a different location.


******************

Solving the 1st part has meant splitting the scripts that are in the Game Code into 3 different parts.

The script table that is used to locate each item's description has been moved into some of my extremely-precious free space in the CD Boot Code section. That means that it is always available for reference/modification, which is needed for when the Game Code loads the level-specific item descriptions and overwrites some of the table entries.

The item descriptions themselves have been moved into the bank of extra memory that I've freed by recompressing all of the game's data (the META_BLOCKs) with the more-efficient SWD5 compression.

I've written some new code that's been added to the Boot Code itself to actually load those item descriptions and then copy them into that bank.

All the "names" and "common" scripts are still in the Game Code overlay, and now that the item descriptions have been removed from it, there's plenty of room in the overlay for the larger translations.

FYI ... the current English translations that have been inserted are sometimes taking up to 50% more space than the original Japanese scripts.


******************

Solving the 2nd part has been easier, but needs to be improved.

When I first started to disassemble the scripts and found that Falcom were structuring the game like this, I knew that I'd have to deal with it at some point, and so added the information into the extraction process.

Each script file that SamIAm is translating has a section at the top that contains a list of the "external" scripts that that particular script can refer to that aren't actually located in that particular script file.

It looks like ...

[tt]  @extscript( $997e, .table997E  )
  @extscript( $9ea8, .script9EA8 )
  @extscript( $9ead, .script9EAD )
  @extscript( $9ecd, .script9ECD )
  @extscript( $9f1b, .script9F1B )
  @extscript( $9f8b, .script9F8B )[/tt]

This tells the script compiler that when it sees a script referring to something with one of those labels (the 2nd value), then it should actually compile in a different address (the 1st value).

Now that I've actually got those scripts compiling, that table is changed to the following, which corresponds the the new locations of each of the scripts ...

[tt]  @extscript( $3f7e, .table997E  )
  @extscript( $9614, .script9EA8 )
  @extscript( $998a, .script9EAD )
  @extscript( $99bb, .script9ECD )
  @extscript( $9a2a, .script9F1B )
  @extscript( $9ad1, .script9F8B )[/tt]

This is fine, and works great (you can see the results in the screenshots above), but it's a real PITA to manage.

It means that whenever SamIAm or I edits one of those scripts in the Game Code, then I've got to change that table in all 168 script files.

I need to implement a "better" solution for the script compiler (like "include" files) ... that's the next task on my list.  :-k


******************

So, the conclusion from all of this rambling, is that what you are seeing in those screenshots at the start of this message is actually the result of scripts that are located in a number of different places and that are loaded into memory at totally different times.

The 1st screenshot comes from a script that's located in the 1st script file for the 1st level (the Prologue).

Then, that same script calls some code that gives the player the "Clothes" item, and then calls another script in the Game Code overlay to display the "item-received" script (which has been re-compiled into a new location).

The "item-received" script then looks up the item number in the item table (which has been re-compiled into the Boot Code), and then prints out the item description for "Clothes" (which has been re-compiled into the extra script memory that I've freed-up), and finally prints out " received."

So, even though it just looks like a simple pair of messages on screen ... getting all those things working and properly-coordinated is actually a pretty major step forward in getting the translation done.  :wink:

SamIAm

Awesome post, elmer. :)

So awesome, it inspired me to drop what I was doing and get back to work on Chapter 5. ;)

elmer

This "blog" has definitely been getting quieter in the last few weeks as there's not too been much "interesting" stuff to post, since Xanadu 1 is pretty-much hacked-to-death at this point.

The only interesting problems that have had to be solved were in what I keep on calling the "Weapon Shops", i.e. the "Buy" shop and the "Sell" shop.

First of all, they contain "custom" code for printing the text messages, and that code wasn't extracted-and-patchable in the way that the other code overlays were.

The solution for that was to add some new patching commands into the script compiler to apply the patches at the same time that the translations are applied.

That's a pretty ugly hack ... but it works, and it keeps the ugliness restricted to only those few scripts that use the new script commands.

***********

More interesting was that those Weapon Shop scripts are the only time that I've seen so far that Falcom is decompressing graphic data while the game/music is still running ... well, it's the only one that has caused a problem anyway.

The Weapon Shops use a custom set of tiles for the dialog boxes, and it decompresses that graphic data whenever the dialog box is cleared.

My new SWD5 decompressor is using the HuC6280's TII instruction for data copies ... which, as any PCE programmer knows, blocks interrupts while it is executing.

That doesn't cause any problem if you're only disabling the interrupts for a short time, but in this particular case, the graphics for the dialog box compress really well, and the SWD5 decompression executes TII copies with large chunks of repeated data.

That was blocking interrupts too long, and was causing a skip in the music and a nasty glitch in the graphics on the screen.

The obvious solution is to replace the TII instruction with an assembly routine that does the data copy without blocking the interrupts.

The problem is that that routine is both larger and slower than using the TII instruction.

Sometimes that's the best solution to use, particularly if you're doing a lot of complex stuff with interrupts ... but in this case, there's another solution available.

That solution is just to change the compression code to set a lower limit on the maximum size of any repeated chunk of data that is found.

In this case ... changing that limit from 8KB, all the way down to 128 bytes, was enough to fix the glitching.

In order to avoid hurting the compression too much, the "fix" is only applied to that 1 specific chunk of graphics data ... which was another problem ... but it's all solved now.

***********

As Dave so very correctly pointed out a while back ...

Quote from: dshadoff on 09/14/2015, 09:33 PMThe data that you will be recompressing later will NOT be the same as the data in those blocks today, so a test on SWD3/SWD4 compressibility of existing data is not very relevant.

For one thing, text is usually encoded in these things as 2-byte SJIS for kanji, and 1-byte JIS for kana.  It doesn't compress anywhere near as well as English (though it is generally slightly more dense to begin with).
So, now that we've got a couple of levels of English translations running in Xanadu 1, I thought that I'd take a look at how the compression is doing.

META_BLOCK "Z10" $000d9800, originally 160KB,  SWD5 Jpn 134KB,  SWD5 Eng 138KB.
META_BLOCK "Z11" $00105800, originally 148KB,  SWD5 Jpn 126KB,  SWD5 Eng 130KB.
META_BLOCK "Z12" $00131800, originally 176KB,  SWD5 Jpn 148KB,  SWD5 Eng 154KB.
META_BLOCK "Z13" $0015d800, originally 174KB,  SWD5 Jpn 146KB,  SWD5 Eng 152KB.
META_BLOCK "Z14" $00189800, originally 166KB,  SWD5 Jpn 140KB,  SWD5 Eng 148KB.


The game allocates 176KB for loading a META_BLOCK into memory, and I need to reduce that to 168KB maximum in order to free up the 8KB block that I'm using for the English translations.

Those results show that we're doing really well so far, and that we should have no trouble getting Xanadu 1 to run with a Super System Card 3, and that we're not going to need the extra memory in a Turbo Everdrive 2.  :D

Just to state the obvious ... it's still way too early to tell if Xanadu 2 is going to fit.

elmer

Sometimes things work out ...

IMG


Sometimes things don't ...

IMG


So, once again, with Xanadu 2 it's the Weapon Shops that are being a royal PITA.  :roll:

Falcom are not only doing a completely new trick with them, but they're using custom display code for the 2 English strings that bypasses my regular text-display fixes, and causes character spacing problems.

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).

I think that's quite a neat trick.  :)

However ... now we've got a couple of problems.

The easier one is going to be finding/hacking the new custom display code so that the 8x12/4x12 English font spacing works properly.

The harder one is that even when that is done, the English item descriptions are just too long to fit into the small box that's been provided.  #-o

That will need some thinking ... and possibly a new 6x12 font.

There should be space for a new font where Xanadu 2 is currently loading it's custom 8x12 font ... thankfully.

But it's going to be a real PITA to switch the entire game from working in 4-pixel text-coordinate steps into 2-pixel (or 1-pixel) steps in order to cope with both 4, 8, and now 6-pixel wide English glyphs.  ](*,)

dshadoff

I appreciate all the thought that's going into this, but...

All other RPG game where this has happened, have resorted to short-form names - at least within the context of the weapons shop.

Is this not an option ?  Or just an option you'd prefer not to entertain ?

-Dave

elmer

#142
Quote from: dshadoff on 12/27/2015, 09:01 PMAll other RPG game where this has happened, have resorted to short-form names - at least within the context of the weapons shop.

Is this not an option ?  Or just an option you'd prefer not to entertain ?
It's definitely an option, and I can certainly understand why translation teams do it, but take a look at this example of what's going on ...

IMG

Yes, I could just ask SamIAm to abbreviate both examples to "Lethr Armor" and "Dragn Slayr" ... but it's not a nice work-around, and it doesn't fit with the care-and-attention that Falcom put into these games.

If I can find a reasonable solution to avoid it then, personally, I'd find it pretty embarrassing (as a professional programmer) to have the game display the name of the game's legendary weapon, the weapon that gives it's name to the entire series of games, as "Dragn Slayr" instead of "Dragon Slayer".

Unlike Xanadu 1, Xanadu 2 already contains an 8x12 font that it uses for some character's names, for some special graphical characters, and for that item description in the Weapon Shops (which is why the spacing is almost correct).

It only loads up that font during the game, so I couldn't use that memory for the main English font (because it has to work in the Main Menu), but it does mean that I've got some space that I can use for a condensed font.

If I can change the game to use 1-pixel text coordinates, then it opens-up the possibility to switch the current bi-width English font into a fully variable-width font ... which will look nicer.

IMHO, the current font looks pretty good, and I've tweaked the glyphs to give them a consistent spacing ... but, to-be-honest, that has made the outlined versions in Xanadu 1 overlap so much that they look terrible!

I've spent over 600 hours, so far, hacking these games and recreating an important chunk of Falcom's toolchain, and it would be a shame to take the "easy" solution now just to save a few more hours of trying to do it "right".

dshadoff

#143
Fair enough.
Well, there are also other possible solutions too...

One could have the grid layout of the bottom line adjusted to make a bit more room for the weapon name...

But another one I just thought of, which may look even better than the original....
If possible, switch the location of the weapon name (3rd line) with the power up/down report ("Attack +12" on top line).  That layout would afford more room for the weapon name, and would probably make more sense to the user.

I also have a pretty good feeling that the box on the third line wouldn't be overflowed by "Attack +12" or whatever other possible text could show there.  And even if it couldn't handle all lengths, these phrases would be better candidates for shortening than the weapon names.

Not sure how much work this would be, but given what you've already achieved, it may not be so difficult.

-Dave

elmer

#144
Quote from: dshadoff on 12/28/2015, 02:42 PMOne could have the grid layout of the bottom line adjusted to make a bit more room for the weapon name...
I thought about this, but I'm a bit worried to rely on it because I'm not sure what the maximum width of the numbers in the other 2 boxes is.


QuoteBut another one I just thought of, which may look even better than the original....
If possible, switch the location of the weapon name (3rd line) with the power up/down report ("Attack +12" on top line).  That layout would afford more room for the weapon name, and would probably make more sense to the user.

I also have a pretty good feeling that the box on the third line wouldn't be overflowed by "Attack +12" or whatever other possible text could show there.  And even if it couldn't handle all lengths, these phrases would be better candidates for shortening than the weapon names.
Now this is a great idea, I wish that I'd thought of it myself!  #-o

I'm currently trying to get the 1-pixel coordinates working, but even if I do, I'd favor trying to shift around which box is used for which string anyway ... it's a much more logical layout for a Western game player.

Thanks!  :D

CrackTiger

Yeah, purely from a game player perspective, I'd be much more comfortable with the item names up top.
Justin the Not-So-Cheery Black/Hack/CrackTiger helped Joshua Jackass, Andrew/Arkhan Dildovich and the DildoPhiles destroy 2 PC Engine groups: one by Aaron Lambert on Facebook, then the other by Aaron Nanto!!! Him and PCE Aarons don't have a good track record together! Both times he blamed the Aarons and their staff in a "Look-what-you-made-us-do?!" manner, never himself nor his deranged/destructive/doxxing toxic turbo troll gang which he covers up for under the "community" euphemism!

IvanBeavkov

elmer, I just want to say I find this thread immensely interesting. I just love reading the details about how the game was built. It makes me wish I had the time to devote to learn how to do this.

Keep up the good work!

elmer

Quote from: IvanBeavkov on 12/30/2015, 02:02 PMelmer, I just want to say I find this thread immensely interesting. I just love reading the details about how the game was built. It makes me wish I had the time to devote to learn how to do this.
I'm glad that I'm not just boring everyone!

IMHO Falcom really put these games together well, I think that they're a great example of the best-practices in Game Engine design for the time.

It's been interesting to get a look behind-the-scenes as I've been hacking into the game, and to get an appreciation of just how good Falcom were at putting this kind of game together after they'd spent nearly 10 years of putting together the "Dragon Slayer" and "Ys" series on 8-bit and 16-bit home computers.


Quote from: guest on 12/28/2015, 09:58 PMYeah, purely from a game player perspective, I'd be much more comfortable with the item names up top.
It took a while to figure out how Falcom were setting up the positions of the text sprites, but here you go ...

IMG

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.  :-k

dshadoff

Quote from: elmer on 12/31/2015, 02:47 PMIt took a while to figure out how Falcom were setting up the positions of the text sprites, but here you go ...

IMG

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.  :-k
Wait... did you say "text sprites" ?
If they're using sprites, you need to know that beyond 16 sprites on the same scan line, there will be hardware flickering.  One more difficulty with longer text phrases.

elmer

Quote from: dshadoff on 12/31/2015, 03:11 PMIf they're using sprites, you need to know that beyond 16 sprites on the same scan line, there will be hardware flickering.  One more difficulty with longer text phrases.
Whoops, I guess that I wasn't clear enough.  :oops:

It is just text rendered into a large VRAM bitmap, which is then displayed as sprites.

Falcom are allowing for 128x16 for the weapon name (4 sprites), and 192x16 for the description/benefit message (6 sprites).

The box at the bottom only has room for approx 88 pixels of the description/benefit message, so I've left the extra 2 sprites up at the top of the screen where they won't get in the way.

Falcom are actually using the same low-level text rendering code for those strings as all the other text in the game, but they're setting a flag to bypass all the normal text cursor positioning code, and they're just using lower-level 4-pixel-sprite-strip position coordinates.

That makes it easier for them to control the exact pixel positioning for single-line messages rather than having to abuse the higher-level teletype-style console text code that handles the normal game text.

It wasn't that hard to find once I saw that the text was broken ... but it means putting in a bunch of small fixes for every string that's displayed in that way, rather than the clean fix-it-all-in-one-place that worked for the other game text.