Variable Width Font? War of the Dead

[Hildebrande Glossop]

So,
I've been  taking apart the War of the dead PCE rom; I can make tables, replace text, tiles, etc. The problem is, there's not enough room for all the english text I want to insert. From my limited knowledge, am I to understand that this will require expanding the rom, and ASM programming to implement a variable-width font? It seems as if the game displays two rows of tiles per one row of japanese text, and the extra row add the plosive marks. I'm still playing around with it, but I thought you guys would probably know something.
I can't find any documentation on this subject, so any help would be appreciated.

[Spikeman]

I'm not too familiar with PCE, but usually a VWF doesn't take up so much space that you have to expand the ROM. If there's limited space though, you may have to.

It seems as if the game displays two rows of tiles per one row of japanese text, and the extra row add the plosive marks.

The best thing to do here would probably be to remove the code that draws the extra row and modify the code that increments the row position so it works for only have one row instead of two. Then you can add the extra VWF code (there might even be enough extra space from just the code you've removed).

The general technique I use when adding a VWF is this: (note: assuming the font is 1x1 tile, the process is similar if it's bigger)

1) Find an area in RAM with 2 bytes free, you'll be storing two values: the carry (the amount the next letter needs to be shifted) and the total width (to see when to do a newline - optional if you want to do this manually).

2) Modify the code that prints one letter so that it prints to two tiles at once - the proper tile and the next tile. This is necessary because, say the width of the letter is 8 pixels and the tile is 8 pixels wide, then shifting it even 1 pixel over would put 7 pixels of it on one tile and 1 on the next.

3) Now add shifting into the code. I usually just start with a constant value (like 4) to see if everything's working before I make it load from a width table. For the first tile, you want to bitshift the letter right the carry amount (which should be initialized to zero). For the next tile, you want to bitshift the same graphics left (tile width - carry), so if the carry is 5 and your tile width is 8, you'd be shifting it 3. This makes it so the letter is split with its first 3 tiles on the first tile and its next 5 on the second tile.

Note: There are a few issues that make this a little more complicated. 1) If there is a background color built into the tiles sometimes shifting the letters around will put "holes" in the background. This is fixable by shifting a block of background color and ORing it with the shifted letter graphics. I can explain more if needed. 2) If your font isn't 1bpp (which is probably the case) the shifting can be a bit more complicated. This usually isn't too difficult to figure out, for example in 4bpp games you just shift 4*carry instead of just carry.

4) Calculate the new carry value. I usually just do (carry + letter width) % tile_width. Note that this is the only place the width of the tile is used - everywhere else just uses the carry value. Note: only do this after the second half of the letter is drawn. Also, be sure to zero the carry value every time there is a newline or a new window of text or you'll get weird results.

5) Once you have that all working, add a width table - this is just a table of the widths of the font. You can look up width values by loading from [width_table_address + font_value] since each entry is only one byte. This takes up the most space out of anything, but depending on the system you should have more freedom of where to place it. Something you can do in a lot of games it place it where the kanji were in the Japanese font, since you don't need those anymore.

There's a few examples of VWF code in the documents section: http://www.romhacking.net/?page=documents&title=vwf

And here's one for a GBA game I coded: https://github.com/moozilla/Telefang-2-English-Translation-Project/blob/master/asm/VariableWidthFont.asm

[Pennywise]

Just an FYI, War of the Dead is/was being worked on by kingofcrusher and I believe most of the script was translated. I think filler helped translate it. Not sure what became of the project though.

Regardless of all that, I'm not even sure a VWF is possible on the Hu-card stuff. That said what you're up against is pretty universal across all the old games. The most basic option to tackle this problem is to modify the text pointers, but that is often not enough for a decent translation. Probably one of the best options is to expand the ROM and relocate the text, but if you can't do that there's always compression.

[Hildebrande Glossop]

Thanks for all the info, guys

I found the thread on current translations, very helpful! As well you wealth of info on the VWF, I'm gonna read through that tonight.

Looks like it is pretty much done, and very well too. I always figure that out right after I place a "help wanted" ad...

Hypothetically, one could make a font that displays two or more english letters per tile, right? Maybe that's what I can do in the future, I still have to teach myself a lot more about hex editing, pointers, etc. Before I can bend the code like that.

[Ryusui]

A VWF is always possible, as long as you have enough VRAM to accommodate unique data for every last tile of on-screen text. (And, yeah, a processor powerful enough to do all that tile-shifting in real time.)

[tomaitheous]

The problem is, there's not enough room for all the english text I want to insert.

In the rom or on the screen? If it's a rom space issue, VWF won't help with that. Either rom expansion (and probably minor hacking to use the additional rom space) or some custom compression like 2 or 3 word look up ( ASM hacking/writing involved). If the japanese font is 8x8, then it's probably the old tilemap method. Where all the tiles are already in vram and the print routine just updates the tilemap as to which tile to point to - for showing on that line. Setting up a VWF routine would probably entail taking that area reserved for tiles and using it directly for a pseudo-bitmap buffer (like most PCE CD games do). That's a pretty advanced type of hack IMO.

[justin3009]

I must say.  The way Spikeman states  how and what to do for a VWF makes A LOT more sense than half the explanations I've seen people give on here ._.

[Spikeman]

Heh, glad I'm not talking nonsense then.

I always thought writing a VWF would be really difficult, until I tried writing one. It turns out another game I was looking at already had a VWF, so I just traced through the code and figured out how it was doing what it was doing. The code from that game was a lot more concise and simple than a lot of the code I've seen posted here, I actually just copied the code into the other game with some slight modifications (ie. the original was 8x8, I needed 16x16). For other games I've had to modify it a lot more, but it's really cool how easy it is to modify existing code to do what you need. For example, this game I copied the code into just loaded the font directly into VRAM and referenced it by tile number, so I simply used this VRAM space to hold the new graphics. Oh and for what it's worth the game I took the VWF from was Rhythm Tengoku for GBA, it's worth a look if anyone is a GBA programmer.

[justin3009]

Damn I was hoping that'd be a Super Nintendo game XP  But nonetheless I love the way you explained it all.  I'm seriously trying to learn how to implement a VWF into a certain game and I'm damn sure it's possible.  That explanation may have helped get me more prepared for doing such a feat.

[kingofcrusher]

Yeah it's totally finished, just needs a play-through to fix any text errors and stuff. I think the script fits if I remember correctly, I inserted it back in november but just never got around to playing through it. I think I needed to revise a couple little things here and there too (names and menus), but otherwise it's just sitting on my hard drive waiting to get beta-tested.

I was going to do a VWF and add a SRAM save routine instead of the god-awful password system, but honestly the game isn't very good and definitely not worth the effort involved unless you just want to do it to learn or something. Trying to play through it on real hardware is nearly impossible unless you spend hours and hours grinding, the game is balls hard and makes huge jumps in difficulty between areas that have no graphical ques to differentiate them. You'll be walking along fighting dudes you can easily beat, then suddenly you're facing a monster that kills you in 2 hits, it's infuriating if you don't have save states.

[DarknessSavior]

Damn I was hoping that'd be a Super Nintendo game XP  But nonetheless I love the way you explained it all.  I'm seriously trying to learn how to implement a VWF into a certain game and I'm damn sure it's possible.  That explanation may have helped get me more prepared for doing such a feat.

I too wish someone would post a concise guide for doing a VWF on the SNES. Though I agree with justin here, the way you explained it was quite well done. Perhaps you should submit a document on the subject?

~DS