Author Topic: Xanadu II Translation Development Blog  (Read 47515 times)

elmer

  • Hero Member
  • *****
  • Posts: 2159
Re: Xanadu II Translation Development Blog
« Reply #510 on: October 16, 2016, 10:46:27 AM »
I'll build a custom version of Mednafen, and see what happens.  :-k

Ah ... it doesn't need a custom version, just set "pce.forcesgx" to 1 in the config file.

I'm getting some interesting artifacts in the background colors of both Xanadu 1 and Xanadu 2 when I do so, though.

Hmmmm ... are people seeing these on a real SuperGrafx/SuperCDROM???

It looks like the first palette entry of each palette (and thus the background color) isn't getting faded to zero (black) properly. It doesn't happen all of the time, but it's pretty consistent *when* it happens.

Curious ... I'll have to find out what's going on.  :-k

<EDIT>

It happens on the original ISO rips, so it's not something that we've broken in the translation.

It's either a bug in Falcom's code that only surfaces on the SGX, or it's a problem with Mednafen (either in the original, or in my build of it).  :?

<EDIT2>

It's Falcom, and not Mednafen.

They're leaving garbage colors in the background color register (palette 0, color 0), which is OK on the PCE because it displays the overscan color register (palette 16, color 0) in offscreen areas.

On the SuperGrafx, the background color register is always displayed, even in offscreen areas, which means that the screen border color in the Xanadu games keeps on changing.

Cr*p!  ](*,)
« Last Edit: October 16, 2016, 12:08:04 PM by elmer »

elmer

  • Hero Member
  • *****
  • Posts: 2159
Re: Xanadu II Translation Development Blog
« Reply #511 on: October 17, 2016, 03:24:38 PM »
It also opens up the faint possibility that we could add subtitles to a SuperGrafx CD-ROM version of the translation!  :-k

But realistically ... there are so few of us SuperGrafx & SuperCDROM owners still out there, that I can't see it being worth the time-and-effort, since most people would prefer a dub anyway.

They're leaving garbage colors in the background color register (palette 0, color 0), which is OK on the PCE because it displays the overscan color register (palette 16, color 0) in offscreen areas.

On the SuperGrafx, the background color register is always displayed, even in offscreen areas, which means that the screen border color in the Xanadu games keeps on changing.

Ahhhhhhh ... after more research, it looks like Falcom are actually sometimes relying on the way that the PCE uses color 0 of palette 0 for the background of the displayed screen, and color 0 of palette 16 for the overscan areas.

Since the SuperGrafx (in SuperGrafx mode) operates differently, this means that I can't even remotely contemplate the idea of SuperGrafx subtitles because they'd actually mess up Falcom's use of the background color.

Darn!  #-o

elmer

  • Hero Member
  • *****
  • Posts: 2159
Re: Xanadu II Translation Development Blog
« Reply #512 on: October 18, 2016, 11:14:56 AM »
The Weapon Shop screens have been a bit of a nightmare when it comes to graphics cleanup, so I've taken a little break and have fixed Falcom's spelling mistake when you start the Prologue.

It's gone from ...




To ...




It's nice to finally get that done!  :D

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

BTW ... while doing the reseach into where those graphics are, and how to fix them, I found a soft-lock bug in game ... and "yes", it is in the original Japanese version!  :shock:

If you press the START button to break out of the Prologue, and also press the START button to break out of the Opening Visual, then, if you get the timing right, when you actually get to the game itself, with Areios and Daimos on the Rolandia, then game doesn't display Daimos's first message box, and you're totally stuck while the game sits there playing the music and moving the sailors and birds  around as normal.

Falcom!  [-X
« Last Edit: October 18, 2016, 11:16:32 AM by elmer »

Bonknuts

  • Hero Member
  • *****
  • Posts: 3292
Re: Xanadu II Translation Development Blog
« Reply #513 on: October 18, 2016, 01:42:13 PM »

Ahhhhhhh ... after more research, it looks like Falcom are actually sometimes relying on the way that the PCE uses color 0 of palette 0 for the background of the displayed screen, and color 0 of palette 16 for the overscan areas.

 So sprite color #0, overscan color, is showing on the SGX plane? This is the problem? Color #0, of palette #0, is its own plane regardless of either VDC (it shows behind both not matter what), so I don't see how that's an issue.

 If it's sprite color #0 (palette #16, color 0) - they why not leave sprite plane on VDC2 enabled at all times? As long as the SAT is clear, it shouldn't obstruct anything. And since it's always on, it shouldn't show as a solid color plane. If all else fails, you could always use the SGX window plane regs - but I don't think you'd need even to go that far.

elmer

  • Hero Member
  • *****
  • Posts: 2159
Re: Xanadu II Translation Development Blog
« Reply #514 on: October 18, 2016, 06:12:44 PM »
So sprite color #0, overscan color, is showing on the SGX plane? This is the problem? Color #0, of palette #0, is its own plane regardless of either VDC (it shows behind both not matter what), so I don't see how that's an issue.

I'd be happy to hear of a solution if you can think of one that can be applied relatively cleanly.

I could just be having a brain-fart and not be thinking clearly.  :-k

Here are just a few examples from Xanadu 2.


Some things that Falcom did are a little bit sloppy, such as leaving a garbage value in palette 0 color 0, like these ...

SGX:








PCE:




Now, in that case, I can just clear palette 0, color 0 to "black", and everything should look OK (if I can track down where the palettes are stored on the CD).

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

But take a look at these ...

SGX:






PCE:






In these cases, Falcom are actually relying on the difference between the background color (palette 0, color 0), and the overscan color (palette 16, color 0) in order to provide the correct border color.


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

I can't think of any automated (and therefore "practical") method of hacking the game so that I can fix the background colors in the top cases, without also destroying the background colors in the bottom cases.

I'm guessing that pretty-much-every case could be "manually" fixed ... but that would take months of work, and all for almost no end-user-benefit ... which seems crazy.
« Last Edit: October 18, 2016, 06:17:07 PM by elmer »

Bonknuts

  • Hero Member
  • *****
  • Posts: 3292
Re: Xanadu II Translation Development Blog
« Reply #515 on: October 19, 2016, 05:22:03 AM »
In the both batch of pics, that's actually quite ingenious of Falcom. I never thought of that, for doing image that clipped regions. The border can be whatever sprite color #0, allowing a much more useful color to be applied to color #0 (pal#0) for background usage (it's in all the BG subpalettes). I'm gonna have to remember that trick!

 I see what you mean. You could minimize the damage by using Patty's window regs and two hsync calls; making the second VDC visible only on a 32px height window somewhere in the fame instead of the whole thing. But that might get messy if the game uses hsync calls during the cinemas.

 EDIT: Is the border color always black??? (in the cinemas, not the regs themselves)
« Last Edit: October 19, 2016, 05:28:13 AM by Bonknuts »

elmer

  • Hero Member
  • *****
  • Posts: 2159
Re: Xanadu II Translation Development Blog
« Reply #516 on: October 19, 2016, 06:20:07 AM »
EDIT: Is the border color always black??? (in the cinemas, not the regs themselves)

Yes, the border is always black.


Quote
I see what you mean. You could minimize the damage by using Patty's window regs and two hsync calls; making the second VDC visible only on a 32px height window somewhere in the fame instead of the whole thing. But that might get messy if the game uses hsync calls during the cinemas.

I can't (sensibly) do anything that would need an interrupt hook, or that would change the height of the screen that VDC #1 sees (because that would change the sprite coordinates).

Falcom uses various different screen heights depending upon where you are, for instance the Opening Video changes the height at the end, and the Boss fights use a different screen height to the Top-Down game levels.

Falcom also relies on the difference between the border and background colors in the game itself occasionally (most noticably for the Waepon Shops, but maybe elsewhere, too).

I haven't even looked at the Boss Levels to see if they rely on the difference.

And this is all just Xanadu 2 ... I've not looked at Xanadu 1 on the SGX to see what it does.

Bonknuts

  • Hero Member
  • *****
  • Posts: 3292
Re: Xanadu II Translation Development Blog
« Reply #517 on: October 19, 2016, 11:39:52 AM »
Are all the sprite palettes used in the cinema code? Is there at least one free one, or one static one that contains the color black?

elmer

  • Hero Member
  • *****
  • Posts: 2159
Re: Xanadu II Translation Development Blog
« Reply #518 on: October 20, 2016, 04:12:56 AM »
Are all the sprite palettes used in the cinema code? Is there at least one free one, or one static one that contains the color black?

I expect that there's at-least-one free ... but it may not always be the same one.

There are also all of the cutscenes in the game to consider, and the deliberate use of the background color in some (but not all) of the top-down game areas.

Bonknuts

  • Hero Member
  • *****
  • Posts: 3292
Re: Xanadu II Translation Development Blog
« Reply #519 on: October 20, 2016, 09:51:10 AM »
So, this is what I had in mind: Set VDC2 to disable BG layer but enable sprite layer. Normally this would show the BG color in the border areas, which we don't want because Falcom using sprite color #0 for out of bounds region areas. So setup VDC2 SAT to show sprites across the whole screen, but using black as a visible pixel color. Set VDC2 window reg to show sprites above VDC1 (all layers) and behind VDC 2 BG layer. Initially, set all sprites filling the whole screen to appear low priority (behind BG layer), which will set them behind all layers and keep VDC2 from showing BG color #0.
 
 Now, pick a region of the display area (whole thing, not just the clipped part of VDC 1) and setup a sprite of sprites in this region to point to a buffer in memory where you can blit to. When showing a message, switch the priority to above VDC1, else clear the buffer and set the this specific sprite block to low BG priority.

 Does that make sense?

elmer

  • Hero Member
  • *****
  • Posts: 2159
Re: Xanadu II Translation Development Blog
« Reply #520 on: October 21, 2016, 05:51:14 AM »
Does that make sense?

If I'm understanding you correctly, you're basically suggesting using a 256-wide display of VDC#2 sprites to create the top and bottom black borders, with some nice use of the SGX hardware so that the VDC#2 SAT doesn't need to be continually updated every frame, or every size-transition.

But the technique would rely on there being a constant black value somewhere in one of the 16 sprite palettes, which isn't certain, or even particularly likely.

I guess that the big question that I have, since I'm not familiar with the intricate details of the SGX's extra hardware, is .... is it really OK to have VDC#1 and VDC#2 set to different horizontal and vertical display widths/heights?

Bonknuts

  • Hero Member
  • *****
  • Posts: 3292
Re: Xanadu II Translation Development Blog
« Reply #521 on: October 21, 2016, 04:05:31 PM »
Does that make sense?

If I'm understanding you correctly, you're basically suggesting using a 256-wide display of VDC#2 sprites to create the top and bottom black borders, with some nice use of the SGX hardware so that the VDC#2 SAT doesn't need to be continually updated every frame, or every size-transition.

But the technique would rely on there being a constant black value somewhere in one of the 16 sprite palettes, which isn't certain, or even particularly likely.
Have fifteen sets of grouped sprite cells (forming 32x32 or 32x64), each color responding to color 1 to 15. Then you can assign whatever palette you want. You could even prebuild multiple configured SATs for this, so you don't have to assign any palettes, and just VDMA them during vblank to change which one to use (no cpu power to shift things around). I mean, you have a lot of vram in SGX to mess around with. Especially since you won't be using the BG layer, so the BG map area is free game.

Quote
I guess that the big question that I have, since I'm not familiar with the intricate details of the SGX's extra hardware, is .... is it really OK to have VDC#1 and VDC#2 set to different horizontal and vertical display widths/heights?
Patty (video priority controller) doesn't care. Pixels are still sent by the VDC to Patty, and the VCE still sends hsync and vsync to both VDCs. So if one VDC is "clipped" compared to the other VDC, it'll just show sprite color #0 to Patty.

elmer

  • Hero Member
  • *****
  • Posts: 2159
Re: Xanadu II Translation Development Blog
« Reply #522 on: October 23, 2016, 06:25:55 AM »
Patty (video priority controller) doesn't care. Pixels are still sent by the VDC to Patty, and the VCE still sends hsync and vsync to both VDCs. So if one VDC is "clipped" compared to the other VDC, it'll just show sprite color #0 to Patty.

Excellent, thanks for the info!  :D

I've really got a lot to learn about the extra hardware in the SuperGrafx.

The thing is ... after all of that work (if it's even practical), what do I get?

AFAIK we've already decided not to do SuperGrafx-only subtitles, and concentrate on making the dub as-good-as-possible.

Can't SuperGrafx owners run the Xanadu games correctly just by switching the system into "compatibility" mode (single VDC)?

Bonknuts

  • Hero Member
  • *****
  • Posts: 3292
Re: Xanadu II Translation Development Blog
« Reply #523 on: October 23, 2016, 07:28:13 AM »
Ahh, ok.

Pretty sure the switch isn't even necessary except for a couple of games that write outside the traditional VDC address range (games that expect the ports to be mirrored and use mirrored addresses instead of the original ones). The second VDC is disabled from mixing by default, because the Patty window regs are always initialized on power on state (internally; not from code). I've had the switch set to SGX mode for year and don't recall having a problem.

 Fun fact: Patty can also control which VDC receives the STx opcodes too. I was surprised they went the extra mile with this.

elmer

  • Hero Member
  • *****
  • Posts: 2159
Re: Xanadu II Translation Development Blog
« Reply #524 on: October 23, 2016, 08:15:20 AM »
As I said a few days ago, the Weapon Shop and Status Bar have been a real PITA to do a graphics cleanup pass on.

It's finally done, and I thought that it might be good to explain the technique used, since it's not one that's been commonly seen since the 4th-generation development days, and someone might want to use it in another translation, or a homebrew game.

Here are the original Japanese Status Bar and the Weapon Shop's Gems Box ...






If you look carefully, you'll see that the background of each of the boxes is actually made up of a repeating 8x16 texture ...






The regular English text that is displayed in the Message Boxes is drawn by first decompressing a copy of the blank Message Box graphic, and then copying that to VRAM before finally drawing the text pixels on top of that clean background.

That's fine for the Message Boxes, where the game itself is stopped, but it's too slow a process for the numbers that are displayed on the Status Bar.

For the Status Bar, where the numbers change on a constant basis as you kill the monsters, Falcom are using a different technique.

What they're doing is to store a copy of that 8x16 background texture permanently in memory, and then just figure out what part of the texture corresponds to the pixels underneath the digit that they want to display.

Here is something to show how that actually works in practice, with the numbers that are displayed on different lines for the top and bottom of the Status Bar, and the middle of the Current Gems Box.




Then, as Falcom are writing the digit, line-by-line, into the box sprite, they can use that texture data to replace the pixels that were overwritten by the previous digit that was displayed in that location.

That's a pretty fast way of updating the numbers that are displayed on the Status Bar and Weapon Shop, and it's very efficient in terms of the memory used.


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


But ... it's a bit of a PITA when it comes to trying to add a drop-shadow to the numbers in order to make them pop off the background and be easier to read, and more consistent with the other shadowed text that's in the game now.

I couldn't just draw a separate drop-shadow, the way that I'm doing on the Message Boxes, because that would be too slow, and effect the game's frame rate.

There isn't enough free memory to store pre-drawn copies of each digit, in each location, with a real drop shadow baked into the texure.

What I've done is to dredge up a really old technique that's not perfect, but it gives the illusion that there's a drop-shadow on the digit, but without causing any runtime overhead, and with only minimal extra memory usage.

For this to work, you just keep a 2nd copy of the background texture, and then use the original "clean" version if you're displaying a "space" character, but use the new background texture whenever you're writing a digit.

The new background texture has a drop-shadow baked into it that works well-enough to look good for each and every different digit that can be drawn at each of the 3 different positions in the texture.

Creating the new texture is a bit of an "art", and requires a lot of compromise between what a real drop-shadow should look like, and what is good-enough to create the right impression without making the entire box too dark for numbers like "1" and "7" that contain lots of blank space in them.

Here's what that looks like, with the original texture on the left, and then the new shadow texture next to it, together with a before-and-after for the 3 different lines that the numbers are displayed on ...




It definitely darkens the outline of the digits, but you'll probably think that it looks pretty horrible.

That's because you're seeing the whole 8x16 texture at once.

In reality, the game code only writes the 7 lines of each digit that are displayed, and leaves the rest of the texture untouched. That's what makes this technique work ... you only use the new drop-shadow background texture on the lines that it is needed on.

Here's my test example of how it actually looks in practice, with the new fake-shadowed text on top, and the original non-shadowed text on the bottom.




The effect is pretty subtle, but it does manage to look like there is a drop-shadow on the numbers, and it definitely lifts them visually off the background and makes them more readable, at least IMHO. It's not pixel-perfect, but it's good-enough to fool the eye.


So, after all of that messing around, and after modifying the boxes themselves to add a drop-shadow to the icons and the "GEMS", this is the final result (with the high-contrast palette) ...






If you can't immediately see difference between those and the Japanese originals ... then that's the point. The idea is to add just-enough change to help the text pop out more, but without screwing up the look of Falcom's game.  :wink: