VWF for NES

[griever]

Well, I'm talking about variable width font for NES... I guess, there are no games, which had this feature. Is it possible anyway?

[Bregalad]

Technically, yes, under the condition you use CHR-RAM. It would just waste some load of tiles and that could be problematics in some situations (not ALL situations of course).
I remember this having already been discussed, search VWF in the search function.

[tepples]

Blargg and I were working on a proportional font engine for an NES-based text reader. We eventually abandoned it when we discovered that the NES emulator in a portable DVD player is so inaccurate that it would need loads of workarounds that just don't suit authentic NES development.

But in an RPG or an edutainment game, wasting 60 tiles of CHR RAM in one of the pattern tables for three lines of VWF text might be worthwhile. It's too bad there weren't more games using TQROM (the Pinbot board, which contained both CHR ROM and an 8 KiB CHR RAM) or that Chinese MMC3 clone board (similar).

[Bregalad]

If you'd like to use VWF, chances are that you are writing a RPG, and then chances are that you want it battery backed. This would need a non-existant TQROM+PRGRAM+Battery board, that Nintendo may have made for you if you were a serious game developper back then.
Also, 3 lines of VWF isn't much, especially considering that it's 8xY tiles (where Y is variable). I guess 16xY tiles could be confortable to read, but if you are using 8xY letters, they'd be so small anyway that you don't want many of them being even smaller. It'd just allow some letters like "I" to be something like 5 pixels wide instead of 8, and some letters like "W" to be 9 or 10 pixels wide.

Also, it's a interesting thing to note that most console RPG developpers back then were japanese, and that japanese letters are all the same width. SNES games using VWF like FF6 and Chrono Trigger were adapted to VWF only in their American verison, the originals used fixed 12x16 font. So only american or european RPG developpers would have seriously used this, and few existed (only the Ultima games and Pirates! comes in my mind for this category).

[tepples]

If you'd like to use VWF, chances are that you are writing a RPG, and then chances are that you want it battery backed. This would need a non-existant TQROM+PRGRAM+Battery board

That or just an SNROM, which is more than enough if you are using pure CHR RAM and not a lot of DPCM.

Also, 3 lines of VWF isn't much, especially considering that it's 8xY tiles (where Y is variable). I guess 16xY tiles could be confortable to read

Perhaps. If you do funny stuff with the palettes like the VWF engine I was working on did, you can fit 3 lines of 160x16 pixel text into 60 tiles.

Also, it's a interesting thing to note that most console RPG developpers back then were japanese, and that japanese letters are all the same width.

But there are more than 256 of these letters, right? As for 12x16 fonts, it's just as hard to draw 12x16 pixels as it is to draw arbitraryx16 pixels because both sizes require bit shifting to fit onto an 8-pixel grid.

[Bregalad]

That or just an SNROM, which is more than enough if you are using pure CHR RAM and not a lot of DPCM.

I never say the opposite, but you just mentionned TQROM yourself so that's why I said that.

Perhaps. If you do funny stuff with the palettes like the VWF engine I was working on did, you can fit 3 lines of 160x16 pixel text into 60 tiles.

I wasting 2 BG palettes for monochrome text, leaving only 2 normal palettes for the rest of the screen would sound like a pretty bad chose to me.

But there are more than 256 of these letters, right?

I don't know, but most japanese RPGs on the NES seems to have worked fine with a single japanese alphabet (katakana I think) wich is only about 100 letters (one tile per letter), and using several reserved latin letters or other japanese symbols needed at particular places in the game, leaving the rest for the background.

As for 12x16 fonts, it's just as hard to draw 12x16 pixels as it is to draw arbitraryx16 pixels because both sizes require bit shifting to fit onto an 8-pixel grid.

No, I meant 12 vertically. FF6 and Chrono Trigger on the SNES uses letters of 12 vertically and 16 horizontally in Japan, and 12 vertically and variable horizontally in America.
I just said back on the NES day, few japanese companies would go trough all the trouble to add VWF to their already existing game engine when porting their game to America. Square did it on the SNES because their games were very popular even in America, after the release of Secret of Mana.

[tepples]

wasting 2 BG palettes for monochrome text, leaving only 2 normal palettes for the rest of the screen would sound like a pretty bad chose to me.

That or rewriting the first 8 palette entries at the raster split that shows the text box, mostly hiding the $3F0x garbage using the monochrome bit.

[tokumaru]

No, I meant 12 vertically.

If you are not using the standard Width x Height format, please say so. I also thought it was the opposite.

That or rewriting the first 8 palette entries at the raster split that shows the text box, mostly hiding the $3F0x garbage using the monochrome bit.

Does that really work? I'm sure that makes the garbage less noticeable, but does that really hide it?

If one palette entry could be updated every hblank, and one wouldn't mind having 8 blank scanlines between the game window and the text box, it would be possible to set the palettes without visible glitches.

I don't think VWF are worth all this trouble, though...

[Bregalad]

If you are not using the standard Width x Height format, please say so. I also thought it was the opposite.

Well, this kind of stuff always confuses me.

If one palette entry could be updated every hblank, and one wouldn't mind having 8 blank scanlines between the game window and the text box, it would be possible to set the palettes without visible glitches.

Even one single palette entry cannot be updated just during HBlank. I tried it in my windowbox demo a while ago, while Memblers tested it on hardware.

A better idea would be to have the grayscale bit set for the whole textbox vertically, so that only the palette's luminosity would be limited for the rest of the screen, but not the color itself.
You'd always have something like :
Palette 0 : Black, Any Dark Color ($0x), Any Light Color, Any Light Color ($2x or $3x)
Palette 1 : Black, Any Light Color, Any Dark Color, Any Light Color
Palette 2 : Black, Wathever, whathever, wathever
Palette 3 : Black, Wathever, whathever, wathever

Then you can use Palette 0 for even couple of lines (or for the left side of the screen) of your VWF, and Palette 1 for odd couple of lines (or for the right part of the screen) and have the grayscale bit set for all the VWF part, so that color is always $00 and $20/$30 (wich makes no difference), so you get white text on grey box OR grey text on white box. Color emphasis would get some color if it really looks too bad in grey. I guess this would be a reasonable way to do things, since you need some dark colors and light colors in the same palette anyway if you want any chance of doing good graphics. And you don't have to deal with complex $2006/$2007 writes.
The only real con is that you're forced to have the VWF box taking the whole screen in width.

[tepples]

That or rewriting the first 8 palette entries at the raster split that shows the text box, mostly hiding the $3F0x garbage using the monochrome bit.

Does that really work? I'm sure that makes the garbage less noticeable, but does that really hide it?

There might be about one or two garbage lines, but the border of the text box can hide that as well as the "Sayoonara" demo does.

I don't think VWF are worth all this trouble, though...

Agreed, especially because by the time carts became big enough to hold longer RPGs and Nintendo censorship became toned down, the Super NES with its 64 KiB of VRAM was already out.

[tokumaru]

Even one single palette entry cannot be updated just during HBlank. I tried it in my windowbox demo a while ago, while Memblers tested it on hardware.

I remember this demo... The problem with it was that you had to change the palette and have $2006 point to the correct scanline to render next. But if you are only changing colors, only at the end $2006 must point to where the text box starts.

Setting a palette entry without worrying about the state of $2006 afterwards can be as fast as 12 cycles (3 writes, with A, X and Y previously loaded), which would fit perfectly into the ~28 cycles of hblank.

Also, IIRC, someone said that the PPU only renders the color pointed by the PPU address register if it's within the first 32 bytes of palette, and not the mirrors, so setting address increments of 32 will result in the address falling outside of that range, meaning you don't have to worry about glitches in the next scanline (if that person is correct, I have not tested this).

EDIT: This actually sounds very weird. There are a lot of things about the mirrored palettes I still don't get.

[commodorejohn]

I think Union Bound's adventure/RPG games use a variable font - they have a very small text window (about 8x2 tiles) and display Chinese characters which are 16x16. I'm pretty sure they just have an 8x2 area set aside and then write new characters into that space, as I can't see them having anywhere near a functional set of Chinese characters in the CHR space otherwise.

Someone really needs to translate those - they're the highest-quality unlicensed carts I've ever seen. Well, except for the music.