Xanadu II Translation Development Blog

[NecroPhile]

Lookin' sexy as hell!

His armor looks different.  Is it even better than the mighty earth armor? 

[NightWolve]

Lovely, yeah, that's the thing I always loved about the system and its games, these colorful portraits.

Anyway ... it annoyed me enough that I've tracked down where those frames are located in the cutscene data, and I'm now clearing the bad data during script-insertion so that the stray pixels are gone. 

Awesome that you're actually able and willing to fix such issues! We finally have our own Neill Corlett (among too-numerous-to-count talented SNES hackers) in elmer for our PCE platform!!

[elmer]

Elmer: Sadly, this glitch may have beaten us all. Even the best of us.

While tongue-in-cheek humor may not always work (although it is always appreciated) ...

Awesome that you're actually able and willing to fix such issues! We finally have our own Neill Corlett (among too-numerous-to-count talented SNES hackers) in elmer for our PCE platform!!

Sometimes outright flattery does the trick! 

Well, either that, of it's been a stupidly hot here today, much too hot to do new stuff, but just hot-enough to niggle my guilt for not fixing an annoying problem.

Anyway ... the 1/60th second screen-glitch during the transition from Daimos and Landis to the scrolling sword is now fixed. 

Falcom were doing things in the wrong order, leading to a small window where the screen could display tile data as if it were BAT data.

Or to put it another way ... they changed the screen size from 32x32 to 64x32 and THEN turned the screen off, rather than doing it the other way around.

This could be an issue with Mednafen's emulation ... but I believe that Rypheca has got the VDC processing right here (in terms of which registers can be modified during the frame, and which are only read once-per-frame during the vblank).

I'm sure that Bonknuts knows the answer.

Since I've not said it for a few weeks now ... it's time to repeat that this whole translation wouldn't have been done (by me) without the existence, and sheer superb quality and usefulness of Mednafen.

[Arjak]

Outstanding work, Elmer! Those character portraits look great! The one thing that bothers me is that on the title card, the part that says "The Legend of" doesn't quite match the part that says "Xanadu II." There's a bit of an art style clash. I think it's because of one having a black outline and the other not having one. That's just a minor nitpick, though.

Lookin' sexy as hell!

His armor looks different.  Is it even better than the mighty earth armor? 

Pfft, Water Armor for life!

[elmer]

The one thing that bothers me is that on the title card, the part that says "The Legend of" doesn't quite match the part that says "Xanadu II." There's a bit of an art style clash. I think it's because of one having a black outline and the other not having one. That's just a minor nitpick, though.

You are, of course, entirely right ... ... ... but. 

To misquote Ralph Waldo Emerson ... "Consistency is the hobgoblin of small minds".

The correct quote is actually closer to the truth here ... "A foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines."

In this case, we've got a problem that's in the "foolish consistency" category, and is actually caused by the limits of the logo's implementation in the game (i.e. you're right, but there's a good reason it's that way).

We've only got 7 colors (+ transparency) to draw the entire logo.

We're already using the 1 free color that we had in order to anti-alias the outside of "Xanadu" so that it looks nice.

The text that says "The Legend Of" is only 1 pixel wide.

That means that it needs to either have a drop-shadow, or an outline, in order to stop it from merging into the background too much and becoming difficult to read.

A drop-shadow on that text would look very strange when the main "Xanadu" doesn't have one ... and even then, there would still be spots like the overlap between the "T" and the "X" that would still look strange.

Another alternative would be to drop the anti-aliasing on the "Xanadu" and use a drop-shadow on both lines of text.

It's certainly an option, but to me, the anti-aliasing on the edge of the Xanadu does such a lovely job of smoothing out the stair-stepping of the edges of the "X" that I'd really hate to lose it.

By using an outline on "The Legend Of", together with the anti-aliasing on the "Xanadu", we've placed both lines of text on the background layer of the image, rather than raising either of them above it.

Now, none of this was actually discussed when Phase drew the logo ... but I think that he was right, and I can use the argument above to explain/justify his choices.

I could be entirely full-of-shit, but I still think that given the limitations that we've got, there's nothing about "The Legend Of" having an outline that offends me ... and I'm a very picky so-and-so. 

<EDIT>

Arjak: After a night's sleep I realized that it's possible to see the "small minds" part of the Emerson's quote as an insult aimed at you ... please know that it wasn't meant that way.

The quote is there to give me an opportunity to comment upon when it's OK to throw "consistency" out of the window.

[Arjak]

No worries; I understood what you were saying. It was a nitpick, and fixing the issue would likely be more trouble than it's worth.

[elmer]

Cleanup continues, and this time I've been looking at the Pause Menu.

I've been trying to figure out how to edit the graphics on the screen to add drop-shadows to the text so that it's consistent with the drop-shadow on the main text (and so is easier to read).

There are lots of small changes, and so I thought that it would be interesting to show the same screen in its different versions.

All the screengrabs are from one of my savestates before I fight the last boss in the game, so I've got pretty-much-everything maxed-out, and have just-enough Elixirs to keep me safe! 


Here's how the screen looks when loaded with Falcom's original ISO ...




And here's how it looked a coupple of days ago, with the high-contrast palette and the VFW for the descriptions, but with none of the graphics actually edited ...




And here's how it looks now, with bunch of small cleanups ...

[SamIAm]

Nice work! I can't wait to give this the old CRT test. 

[elmer]

Nice work! I can't wait to give this the old CRT test. 

It took a while to send to you ... but I look forward to hearing what you think. 

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

I've now applied the high-contrast palette and the same kind of graphic cleanup to the Save Slot selection menu that you see when you start the game.

There's not much still left to do, now (graphically speaking)! 

[elmer]

Hmmm ... I haven't mentioned this before ... so it's probably time to tell everyone that the visual cutscenes in both Xanadu 1 and Xanadu 2 have been investigated/deconstructed/poked/prodded and generally abused to the point that I'm pretty confident that we'll be able to modify the lip-sync and transition timings so that everything matches (within reason) the English dub, when it's done. 

It also opens up the faint possibility that we could add subtitles to a SuperGrafx CD-ROM version of the translation! 

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.

[Vimtoman]

Would the SuperGrafx version work on mednafen?

[elmer]

At the moment, Mednafen appears to be disabling the emulated SuperGrafx hardware when you run an ISO image ... so "no".

That makes perfect sense, since there never was a SuperGrafx/SCD game released.

But I imagine that it wouldn't be hard to re-enable the emulated SuperGrafx hardware.

I'll build a custom version of Mednafen, and see what happens. 

[elmer]

I'll build a custom version of Mednafen, and see what happens. 

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. 

<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! 

[elmer]

It also opens up the faint possibility that we could add subtitles to a SuperGrafx CD-ROM version of the translation! 

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! 

[elmer]

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! 

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

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! 

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! 

[TurboXray]

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]

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. 

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.

[TurboXray]

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)

[elmer]

EDIT: Is the border color always black??? (in the cinemas, not the regs themselves)

Yes, the border is always black.

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.

[TurboXray]

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]

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.

[TurboXray]

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]

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?

[TurboXray]

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.

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]

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! 

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

[TurboXray]

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]

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. 

[megatron-uk]

The work on cleaning up the menu and UI elements is fantastic. They look so much better than the original images posted several pages back. Top work! 

[esteban]

The work on cleaning up the menu and UI elements is fantastic. They look so much better than the original images posted several pages back. Top work! 

I can't put it any better.

Elmer, you crazy bastard, we love you for all the effort you put into the fine points.

Finesse.

Pure finesse, comrade.

[TurboXray]

I like the drop shadow. It subtle but effective. Nice.

[TailChao]

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.

Thanks for doing this, it's very appreciated.

I like the drop shadow. It subtle but effective. Nice.

It'll probably look very clear over composite, too.

[Michirin9801]

Hello there! I really appreciate the work you're doing and I'm really looking forward to playing this gorgeous game with its just as gorgeous PSG soundtrack! Keep it up!

[technozombie]

+1 Elmer, you are insane in the absolute most awesome way possible.

[elmer]

+1 Elmer, you are insane in the absolute most awesome way possible.

Well ... I'll agree with the "insane" bit, anyway! 

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

We're still putting together all of the last-minute details for the dub, and getting together screenshots to attract folks with voice-talent into wanting to be a part of it, and ...

... I thought folks might like this screenshot.

It's what you can see by disabling Falcom's sparkle fade-out of the Xanadu 1 logo.

Looks kinda nice, to me.

Thanks to Phase for the logo! 

[Michirin9801]

... I thought folks might like this screenshot.

It's what you can see by disabling Falcom's sparkle fade-out of the Xanadu 1 logo.

Looks kinda nice, to me.

Thanks to Phase for the logo! 

♥~So pretty~♥

[SamIAm]

Man, I love these games.

[Dicer]

Such amazing work from anyone and everyone involved...

I just hope that we get to experience this before the end of days.

[elmer]

I just hope that we get to experience this before the end of days.

Yeah, when I was a kid, being forcefed Religious Education ...

... "the sound of the last Trump" had something to do with the Angel Gabriel, IIRC.

Ain't life just so funny!   

[elmer]

Man, I love these games.

Me, too. 

Thanks for introducing me to them.

I have no idea how they ever got made ... they just don't seem to fit the "commerical" mold of the time. 

[elmer]

We're still putting together all of the last-minute details for the dub, and getting together screenshots to attract folks with voice-talent into wanting to be a part of it, and ...

... I thought folks might like this screenshot.

It's what you can see by disabling Falcom's sparkle fade-out of the Xanadu 1 logo.

SamIAm wanted to see what Falcom's original Japanese logo looked like in the same setting, so I disabled the fade-out, and took another screenshot.

Dang ... Phase's logo looks really, really good in comparison! 

[elmer]

The replacement English level-name screens are going in now, and Phase's new font is looking great! 


Falcom's original screen ...




Translation screen ...

[Michirin9801]

Holy crap that looks amazing!!
Great job ^^

[SamIAm]

Wait until you see the chapter titles. It's the same font, of course, but they just look really nice. I'm 100% satisfied with the way they're turning out.

A CRT test is pending.

[ashrion]

Great

[LentFilms]

Wow, that new font looks incredibly nice! Awesome work guys!

[Dicer]

Wait until you see the chapter titles. It's the same font, of course, but they just look really nice. I'm 100% satisfied with the way they're turning out.

A CRT test is pending.

I have a crt, I'll test

[SamIAm]

Just checked them.

They look amazing. 

[elmer]

Just checked them.

They look amazing. 

Ahhhh ... not too dark, then? Phase's anti-aliasing *should* look really nice on a blurry composite signal. 

[FraGMarE]

I dunno who Phase is, but good pixel art is good!

Hate doing fonts, but loooove doing title logos. 

Just checked them.

They look amazing. 

Ahhhh ... not too dark, then? Phase's anti-aliasing *should* look really nice on a blurry composite signal. 

AA to save the day!  I think the edges will look great on a CRT.  Want to see an absolutely flawless example of pixel art aa?  Go check out Gaiares title logo, specifically the edges of it... good god.  so lovely. 

[elmer]

I dunno who Phase is, but good pixel art is good!

It sure is! 

Hate doing fonts, but loooove doing title logos. 

Hahaha ... yep, it's always been tough to find someone that actually enjoys putting in the mind-crushing effort that it takes to make a low-resolution font look good.

AA to save the day!  I think the edges will look great on a CRT.  Want to see an absolutely flawless example of pixel art aa?  Go check out Gaiares title logo, specifically the edges of it... good god.  so lovely. 

Yes, that looks really good ... but, to be honest, it's actually easier to do that on a large graphical logo than it is to do it on a small font, without causing the font to look horribly blurry.

We had a limited number of spare palette entries to play with on the LoX logo, but even the single color that we could afford to use really helps the outside-edge of the logo look nicer.

Unfortunately, we couldn't bump the logo from 8 -> 16 colors and free-up some entries to anti-alias the interior at all.

Either way ... Phase's font shows (I think) that even though we didn't get much in the way of great-looking English translations back-in-the-day, the basic PCE hardware can push some good-looking screens that look as-good-as or better-than a lot of SNES games managed.


Anyway, here's the Chapter title from the game's 2nd level ... IIRC SamIAm wanted to include this one in the screenshots that the dub-folks are going to see ...