Drawing text in CHR-RAM

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems. See the NESdev wiki for more information.

Moderator: Moderators

Post Reply
User avatar
Vectrex2809
Posts: 102
Joined: Mon Jul 14, 2014 6:05 am
Location: Tokyo, Japan

Drawing text in CHR-RAM

Post by Vectrex2809 »

So, I fired up Faxanadu and I noticed that game has a pretty interesting way to show text during gameplay in a way that doesn't eat up too much of the available CHR but having a full ASCII(?) fontstet in the data that's being copied into 64 tiles of CHR-RAM.
I think it's a pretty cool way to display text that can be exploited even more than Faxanadu does it by making smaller fonts like I did in the included ROM, which save up even more font space in the CHR while allowing for longer strings of text. Also, it can technically display up to 256 chars that are 4 bytes long in size (compressed of course) which is always nice :)
What do you think of this technique? Are there any other games where this technique is used? Discuss
Attachments
smallfont.nes
(32.02 KiB) Downloaded 249 times
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Drawing text in CHR-RAM

Post by tokumaru »

Super Bat Puncher?
User avatar
rainwarrior
Posts: 8731
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Drawing text in CHR-RAM

Post by rainwarrior »

Tepples' RHDE game does it too.

If you do monospaced font, this is actually a great way to have a larger character set without having to have them all constantly paged in RAM (though you now have to manage which glyphs are where in RAM for which text is being displayed, etc.)

If you do variable width font (like RHDE) screen coverage becomes a problem. You can double it by reserving two palettes for it (e.g. black + two whites) but that's a big imposition. If it's just for small text bubbles though, it has the potential to work really nicely?

Super Bat Puncher does do it, restricted to small boxes but also monospaced. (I'm not sure if Miau was considering variable width font but never ended up implementing it?)

I think there are some Chinese pirate/translation games that do it for more characters (like Faxanadu).


Romancia (Famicom) is the only commercial era game that I know of that did a variable width font (in a small box). Edit: was incorrect, an English translation hack in 2008 implemented the variable width font. Romancia is fixed width, but still rendered to CHR-RAM.
Last edited by rainwarrior on Thu Oct 05, 2017 3:22 am, edited 1 time in total.
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Drawing text in CHR-RAM

Post by tepples »

A bunch of Super NES games have VWF routines, especially RPGs and things like Mario Is Missing. But then it's easier on Super NES for about four reasons: more CHR RAM, DMA to CHR RAM, no temptation to use CHR ROM, and the MMIO multiplier can be (ab)used as a shifter to get each glyph into place.

The Action 53 menu and my ports of robotfindskitten and 240p Test Suite use the same VWF routine as RHDE. So does Nova the Squirrel, if these screenshots are to be believed.

I made a mock-up of what Super Bat Puncher would have looked like with VWF.
User avatar
Alp
Posts: 223
Joined: Mon Oct 06, 2014 12:37 am

Re: Drawing text in CHR-RAM

Post by Alp »

rainwarrior wrote:You can double it by reserving two palettes for it (e.g. black + two whites) but that's a big imposition. If it's just for small text bubbles though, it has the potential to work really nicely?
I ripped the Dragon Warrior/Quest graphics yesterday to study how they were put together, and I was surprised to learn that the Enix Logo, "The End" text, and even an alternate font, were stored this way!
DW_Title_00.png
DW_Title_00.png (8.11 KiB) Viewed 5649 times
(The actual in-game colors haven't been added yet, because I'm studying the monster sprites first.)
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: Drawing text in CHR-RAM

Post by lidnariq »

It seems to be a pretty common technique — Bisqwit (in analyzing a pirate multicart) found that Konami had done the same for the Goonies title screen.
User avatar
Bregalad
Posts: 8055
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Re: Drawing text in CHR-RAM

Post by Bregalad »

Vectrex2809 wrote:So, I fired up Faxanadu and I noticed that game has a pretty interesting way to show text during gameplay in a way that doesn't eat up too much of the available CHR but having a full ASCII(?) fontstet in the data that's being copied into 64 tiles of CHR-RAM.
This is only understandable if you play Faxanadu (J). This one did this in order to display 16x16 px kanjis in dialogue box, something the typical NES game is unable to do. The (U) and (E) versions just kept the system in place.

Also, I didn't see it mentionned but I'm pretty sure Romancia does this, and it does so without kanjis, justs normal 8x8 kana.
A bunch of Super NES games have VWF routines, especially RPGs and things like Mario Is Missing.
Most of the time the original japanese version has fixed width character, but often a width of 8 is insufficient for kanjis and a width of 16 is too much, so they used a value in-between and paint the characters in VRAM on the fly. Also, most systems lacks enough VRAM to store all kanjis used in a game simultaneously anyway - which is a 2nd reason painting to VRAM on the fly was not really an option anymore as game started to get better dialogue and needed kanjis.
Last edited by Bregalad on Thu Oct 05, 2017 6:26 am, edited 1 time in total.
User avatar
rainwarrior
Posts: 8731
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Drawing text in CHR-RAM

Post by rainwarrior »

rainwarrior wrote:Romancia (Famicom) is the only commercial era game that I know of that did a variable width font (in a small box).
I should revise this statement. Romancia did not use a variable width font, just it did render text to CHR. It was the English translation hack that made the font variable width.

So, it's not actually an example of variable width font in a commercial era NES/Famicom game, though it might possibly be its earliest use on the NES anyway?
User avatar
Vectrex2809
Posts: 102
Joined: Mon Jul 14, 2014 6:05 am
Location: Tokyo, Japan

Re: Drawing text in CHR-RAM

Post by Vectrex2809 »

lidnariq wrote:It seems to be a pretty common technique — Bisqwit (in analyzing a pirate multicart) found that Konami had done the same for the Goonies title screen.
I know 4 Nin Uchi Mahjong also did this to display a large number of Kanji in an NROM game
AWJ
Posts: 433
Joined: Mon Nov 10, 2008 3:09 pm

Re: Drawing text in CHR-RAM

Post by AWJ »

Bregalad wrote:Most of the time the original japanese version has fixed width character, but often a width of 8 is insufficient for kanjis and a width of 16 is too much, so they used a value in-between and pain the characters in VRAM on the fly. Also, most systems lacks enough WRAM to store all kanjis used in a game simultaneously anyway - which is a 2nd reason painting to VRAM on the fly was not really an option anymore as game started to get better dialogue and needed kanjis.
Romancing SaGa actually loads its entire (rather small) kanji font statically into VRAM. Twice--once at 2bpp and once at 4bpp. Early SNES games that didn't have a lot of graphics to begin with could afford to be pretty wasteful with VRAM.

Dynamically-loaded fonts are very common in Game Boy games, although few of them use kanji or sizes other than 8x8 (an example of one that does is Super Robot Wars 2G, which has 12x16 kanji and 8x16 everything else) Ages ago I wrote an ASM hack for a GB translation that I don't think was ever finished or released (it was some other game I can't remember, not SRW) that changed a dynamic font into a half-static half-dynamic one in order to get more text on the screen at once. The way it worked was I loaded the most common lowercase English letters statically and all other characters dynamically, so you could have as much text onscreen as you wanted as long as no more than n characters were uncommon or uppercase. Naturally, the character encoding was out-of-order and put all the static characters together, in order to simplify the static-or-dynamic test.

The Korean versions of Pokemon Gold and Silver are GBC-only whereas all other language versions are compatible with the original GB. The reason is that the Korean versions use a dynamic hangul font and they need the GBC's second bank of VRAM for it.
User avatar
Alp
Posts: 223
Joined: Mon Oct 06, 2014 12:37 am

Re: Drawing text in CHR-RAM

Post by Alp »

lidnariq wrote:It seems to be a pretty common technique — Bisqwit (in analyzing a pirate multicart) found that Konami had done the same for the Goonies title screen.
It might be common, but my hentai game does the opposite, for a compression scheme.

The bitfields are split into both a positive and negative 1-bit image, and compressed in ROM.

The points where the layers overlap become the 3rd color, and the points where they never touch is transparency, restoring the original 4-color image. The decompression process is a bit on the slow side, but you can't argue with an 8KB image reduced to an average of 1024 bytes or less, can you? :P

(The images are mostly cell-shaded, which really helps this particular compression scheme, as it was designed for it.)
Post Reply