Xanadu II Translation Development Blog

[Michirin9801]

Transparent boxes? How are they printing transparent dialogue boxes?

As you might guess ... the dialogue boxes are actually sprites.

Actually, that makes it even more mind-boggling to me, I mean, I'd think they'd use part of the BG layer to render them and the text due to how much easier I think that would be, I mean, that way they could just swap out the empty tiles for the tiles with letters and numbers, but they're doing that with sprites? Are they changing parts of the sprite on-the-fly with code or what? Each letter can't possibly be its own sprite, that would cause a whole lot of flickering...

[elmer]

Actually, that makes it even more mind-boggling to me, I mean, I'd think they'd use part of the BG layer to render them and the text due to how much easier I think that would be, I mean, that way they could just swap out the empty tiles for the tiles with letters and numbers, but they're doing that with sprites? Are they changing parts of the sprite on-the-fly with code or what? Each letter can't possibly be its own sprite, that would cause a whole lot of flickering...

It's just a design-choice. 

When you're dealing with 12x12 kanji text, instead of simple 8x8 or 8x16 English/Katakana/Hiragana, then you've got to deal with packing 2 glyphs into 3 tiles-wide.

You can either do that with dynamic-drawn 8x8 tiles, or dynamically-drawn 16x16 sprites.

Either way is a PITA, and neither is that much more difficult than the other.

With the LoX games, they're basically creating a 256x64 bitmapped sprite that they can draw the text into.

Other games may use a 256x64 bitmapped set of tiles to draw into ... or one of the many little variations on that.


Generally, the Japanese code will deal with text coordinates as either on 4-pixel boundaries, or on 8-pixel tile boundaries plus an even/odd flag.

Both of those are easy(ish) to hack in a bi-width English font, since there's minimal changes to the underlying Japanese code. But you need spare RAM for the English font, and the table of character widths.

Going to a full VWF is a much more tricky proposition, because you've got to change the game's whole text coordinate system to 1-pixel boundaries.


But, whatever you do, you still end up dynamically uploading text glyphs into sprites/tiles as the message box is drawn.

It's not really any different to uploading new data for animated backgrounds or animated sprites.


In some ways, the big & huge sprite-based text box is easier to deal with, because you don't have to make sure that the screen scroll is always tile-aligned, you don't have to worry about masking out any other sprites that may be underneath the message box, and you don't have to fixup the background data after the box is removed.

[Michirin9801]

It's just a design-choice. 

When you're dealing with 12x12 kanji text, instead of simple 8x8 or 8x16 English/Katakana/Hiragana, then you've got to deal with packing 2 glyphs into 3 tiles-wide.

You can either do that with dynamic-drawn 8x8 tiles, or dynamically-drawn 16x16 sprites.

Either way is a PITA, and neither is that much more difficult than the other.

With the LoX games, they're basically creating a 256x64 bitmapped sprite that they can draw the text into.

Other games may use a 256x64 bitmapped set of tiles to draw into ... or one of the many little variations on that.


Generally, the Japanese code will deal with text coordinates as either on 4-pixel boundaries, or on 8-pixel tile boundaries plus an even/odd flag.

Both of those are easy(ish) to hack in a bi-width English font, since there's minimal changes to the underlying Japanese code. But you need spare RAM for the English font, and the table of character widths.

Going to a full VWF is a much more tricky proposition, because you've got to change the game's whole text coordinate system to 1-pixel boundaries.


But, whatever you do, you still end up dynamically uploading text glyphs into sprites/tiles as the message box is drawn.

It's not really any different to uploading new data for animated backgrounds or animated sprites.


In some ways, the big & huge sprite-based text box is easier to deal with, because you don't have to make sure that the screen scroll is always tile-aligned, you don't have to worry about masking out any other sprites that may be underneath the message box, and you don't have to fixup the background data after the box is removed.

I see... This is all some pretty complicated stuff, but I think I can better get the picture now...
I always thought that drawing dialogue boxes was better with the BG layer than tiles because then you'd free up sprites that you can use to do something else and prevent flickering, and also because I wasn't exactly aware that you could update a sprite's data dynamically other than animating it replacing it in its entirety with another sprite that you have to have stored either in ROM or in RAM, but apparently sprites are more flexible than I thought...

[elmer]

I always thought that drawing dialogue boxes was better with the BG layer than tiles because then you'd free up sprites that you can use to do something else and prevent flickering, and also because I wasn't exactly aware that you could update a sprite's data dynamically other than animating it replacing it in its entirety with another sprite that you have to have stored either in ROM or in RAM, but apparently sprites are more flexible than I thought...

Overlap and flickering are always things to be concerned about.

It's one good reason to use a fullscreen wide solid box if you're going to use sprites.

If you look at LoX1, you'll see that they never bring up a text box when there are huge amounts of enemy sprites on the screen.

But they wanted the transparent status bar on the side (which has to be sprites), so they were already allowing VRAM for a large set of status-bar sprites.

Other games like to draw multiple cascaded text boxes on the screen. That pretty-much has to be done in BG layer on the PCE.

It's all about making a careful decision between the tradeoffs. Everything has a cost.

And yep, you can modify sprite data on the fly, just like you can background tiles ... it's all just VRAM.

The only thing that you can't change during the frame is the sprite-attributes themselves.

The question is ... when to stop messing around with stuff?

I could probably backport LoX2's nice textured message boxes back into LoX1 ... but is that a step too far?

LoX1 doesn't display text in as many colors as LoX2 does, but it has most of them available.

That's another possible change that we could make to the scripts. But should we?

Hmmmm ... even though using LoX2's textured message box backgrounds in LoX1 looks like it's probably technically possible, and it looks quite pretty ... there are other concerns that make it look like it really is a "step too far".

In particular, the changes snowball down to the Weapon Shop text boxes, and then the Weapon Shop status bar as well.

You can't really do one box without doing them all, and doing them all would be making too many graphical change changes to the LoX1 game. Neither SamIAm nor I feel that it is our job to just override Falcom's original game in that way.

I'm OK with tweaking palettes so that stuff looks a little better on modern output devices; and anything to do with dialog text itself is fair-game, but we really don't want to make major changes to the in-game graphics.

[Michirin9801]

The only thing that you can't change during the frame is the sprite-attributes themselves.

Umm, what attributes? >w>

The question is ... when to stop messing around with stuff?

I could probably backport LoX2's nice textured message boxes back into LoX1 ... but is that a step too far?

LoX1 doesn't display text in as many colors as LoX2 does, but it has most of them available.

That's another possible change that we could make to the scripts. But should we?

Hmmmm ... even though using LoX2's textured message box backgrounds in LoX1 looks like it's probably technically possible, and it looks quite pretty ... there are other concerns that make it look like it really is a "step too far".

In particular, the changes snowball down to the Weapon Shop text boxes, and then the Weapon Shop status bar as well.

You can't really do one box without doing them all, and doing them all would be making too many graphical change changes to the LoX1 game. Neither SamIAm nor I feel that it is our job to just override Falcom's original game in that way.

I'm OK with tweaking palettes so that stuff looks a little better on modern output devices; and anything to do with dialog text itself is fair-game, but we really don't want to make major changes to the in-game graphics.

That's fair, if you don't feel like you should be altering the game's graphics like that then don't! The flat text boxes look fine as they are...

[elmer]

The only thing that you can't change during the frame is the sprite-attributes themselves.

Umm, what attributes? >w>

The "sprites" that you see on the screen are made up of two parts ... the graphical data that sits in VRAM, and makes up the different pixel values, and the attribute data that is internal to the VDC chip, that says where to put the sprite on the screen, how big it is, what palette to use, and where in VRAM to read the pixel data from.

You can change the graphics data in VRAM at any time, but you can't modify the attribute data directly.

You've got to upload copies of the attribute data into VRAM (which you can do at any time), and then tell the VDC chip to load up a new set of attribute data from VRAM at the start of the next display frame.

That's pretty-much how sprites work on nearly-all of the 4th-generation and earlier machines.

There's usually a very clear separation between the sprite graphics and the sprite attributes.

[Michirin9801]

The only thing that you can't change during the frame is the sprite-attributes themselves.

Umm, what attributes? >w>

The "sprites" that you see on the screen are made up of two parts ... the graphical data that sits in VRAM, and makes up the different pixel values, and the attribute data that is internal to the VDC chip, that says where to put the sprite on the screen, how big it is, what palette to use, and where in VRAM to read the pixel data from.

You can change the graphics data in VRAM at any time, but you can't modify the attribute data directly.

You've got to upload copies of the attribute data into VRAM (which you can do at any time), and then tell the VDC chip to load up a new set of attribute data from VRAM at the start of the next display frame.

That's pretty-much how sprites work on nearly-all of the 4th-generation and earlier machines.

There's usually a very clear separation between the sprite graphics and the sprite attributes.

Oh I see... I didn't know that, that explains a lot!

[elmer]

This is shaping up to be BETTER than the original presentation.

Insane.

Well ... we are certainly trying to polish some of the UI elements that deal with English text so that they're both a bit clearer and also work better on modern display technologies (without compromising their display on an old TV).

The maps are a case-in-point of that.

They're also a great example of trying to figure out just where the line is in terms of what we're willing to change, and what is us taking that "step too far".


In LoX2, you get given a map for the current level at some point, and you can look at it from the Inventory section of the Pause Menu.

Now, it's easy to miss that Inventory section itself, because there's no graphical hint that you can scroll in that direction on the Pause Menu, but that's a battle for a different day. 

Here's what it looks like on the first level, with me about to select the icon for the classic rolled-up crinkly old faded parchment map ...




And here's what you see next ...




Eeek! That looks a bit strange! 

We've still got the dark grey border from the previous screen, but now there is a razor-sharp (not crinkly) scanline transition to a brown map, with an interior crinkly border, and some strange-looking pinky-purple hues for "fading", plus some even stranger-looking green hues for the "fading" on the town name.

Not only that, but you've got blue-stippled shading on the inland part of the island that looks perilously close to the color of the rivers and ocean.


Hmmm ... well, after some thought, I guess that the pinky-purple and green bits are probably an attempt to take advantage of the limited color bandwidth of a composite TV signal, and produce more of a subtle brightness change. I've seen that trick used a few times before ... but mostly in the 8-bit era.

But these days, when using a modern high-resolution display with an RGB-modded PCE, or when running on an LCD display with an emulator, those color choices just look, errrr ... "not good" (IMHO).


So, with only some palette changes, and without changing Falcom's main map graphics (except for the English names), here is a version that still tries to keep the faded-out and yellowing look, but fix both the strange color-changes, and the inland vegetation color.




Now, there is still the question of whether this is too much of a change from the original graphics, but I currently believe that this both honors Falcom's original intent and style, and also gives us something that will look good on both old composite tube TVs, and modern high-resolution displays.

[Black Tiger]

That map looks great and doesn't feel out of place. After seeing the original next to it, only the original feels like it's from another game.

[Michirin9801]

The map looks perfectly fine to me!

[Gredler]

Ship it!

[ParanoiaDragon]

Wow, offhand, I don't recall ever knowing there was a map, though, it's been, maybe 10 years or so since I beat LoX2?

[esteban]

Now, there is still the question of whether this is too much of a change from the original graphics, but I currently believe that this both honors Falcom's original intent and style, and also gives us something that will look good on both old composite tube TVs, and modern high-resolution displays.

There are some art techniques that are directly tied to the medium, and it is crazy that we are at point where we can decide whether "purity" of experience should be in (1) original canvas CRT or (2) modern canvas.

This modified map (which looks fantastic, by the way), really is appropriate in 2017, since it is true to the *original intentions* of the designers (they, obviously, wanted it to look nice on the displays mainstream consumers would be using).

Preserving every pixel for historical accuracy is one thing (and should be done).

But the current LoX project is about MOAR than that


DISCLAIMER:
**There will always be debate about how to interpret the original intentions/aspirations of the original designers**

[SamIAm]

Time to play devil's advocate.

Some of the coloring principles you see in the original maps that are on the chopping block now are applied elsewhere in the game and might be worth saving.

For example, the pink/purple shading you see on the dark lines. It turns out that if you look around, you can find many examples throughout the game of purple being used to shade brown.

You'll probably have to save and enlarge these images to see it.



On the ship, in the very first screen where the player takes control.



The wood on the floors in the first village.



Here, it's very subtle. You'll have to look at the shadow on the rocks on the right.



Another similar case, on the left.



Here, it's not so subtle. Zoom in, and you'll see purple all over the place.



The original map again, just for reference.

Purple isn't the only shading color that's ever used with brown, don't get me wrong, but it's in there a lot.

In the case of the maps, changing this purple to grey, along with changing the blue vegetation to green and upping the contrast a little, probably isn't going to cause a disruption in the visual style. It could be that it would fool everyone. If it helps things look not-stupid on an LCD, then cool, we can go for it.

However, I think we really need a CRT test to say for sure.

The updated map again, for comparison:

[geise]

I dig the black behind the map. Makes a nice contrast. Awesome work!