This project brings the same blockbuster assembly logic from Myria’s original 1998 English fan translation to the menu system— in shorter terms, it makes the SNES menu system look more like the GBA menu system seen in “FFV Advance” from 2006.
Last week I was reviewing perceived issues with the author; here is a log of that for context.
( Claude is transcribed with indented text, below. )
Hi Claude, I hope you're reporting well! Can you dedicate some attention and time to debugging the current state of the Variable Wdith Font (VWF) hack that's under development in the ffv-decomp directory, please? In this most recent iteration you were attempting to adjust the digits 0-8 on the screen, and I was able to confirm in that test rom (iirc, ff5c.sfc) that the digits do indeed look variably kerned. Good work on the current version-- can you try to take it to the next checkpoint of the romhack by making all the font characters VWF? Thank you!
Good to be reporting well! Great news that the digits test showed variable kerning on-screen — that confirms the render pipeline works. Let me get up to speed on the current VWF state before extending it to the full font.
{{ does machine work & describes it a bit along the way }}
Done — v5, the full-menu VWF, is now installed in ff5c.sfc and ready for you to playtest. Reload the ROM in Mesen (a reset isn't enough; the code is in the file, not the running instance) and open any menu. Every menu label should now render proportionally spaced; digits stay ~8px so number columns keep aligning. The v4 "garbled digits" behavior is retired.
What I did to get here:
Confirmed the ROM state: your kerned-digits test was v4.2 (renderer + pixel queue + NMI drain, proven end-to-end), and menu_vwf_v5.asm — the full string-writer intercept — was already drafted but never applied. The v4.2 ROM is preserved as ff5c.sfc.v4bak if you need to roll back.
Verified v5's assumptions against the actual ROM before touching it. The stock string writer at C2/E59D decodes exactly as v5 expects (4-byte head PHB PHP SEP #$20, fallback resume at $C2E5A1, shared exit at $C2E5EA). I also fully decoded the character-translate routine at C2/E5ED and found it does 16-bit adds ($5140/$5217) — the high byte goes to a "companion" tilemap cell one row up. That looked like a bug in v5 (it floods that cell with tile $FF instead of $51/$52), but I dumped all three font tiles and they're byte-identical blanks, so v5's behavior is visually stock-equal. Letters in this font are genuinely 8×8.
Mapped the freespace neighborhood by scanning for every JML/JSL into bank $E0: earlier hacks live at $E05000-$E052FF and at $E058E8/$E05E88. v5 assembled to $E05300-$E056FA — no collisions, and asar's diff touched only the three hook sites, that region, and the checksum.
Two things to watch in the playtest:
Mixed spacing in dense menus is expected, not a bug. The pixel queue holds ~506 bytes per frame; if a menu draws more text than that in one frame, the overflow strings fall back to stock 8px rendering.
If you see garbled tiles or menu weirdness, the prime suspect is the queue WRAM at $7E:A937-AB36 — v5 assumes it's idle during menus but that was never sentinel-verified. The test: on the v4bak ROM, use Mesen's memory viewer to fill $7E:A937-AB36 with $AA, navigate every menu and a shop, then read it back — any byte that changed means the game uses that region and we need to relocate the queue. (The Mesen MCP server isn't connected in this session, so that step is manual.)
Let me know what the menus look like and we'll take it from there.
{{ does human stuff, returns }}
They're looking really good! Nice job porting the special VWF logic handling from 1998 into a new implementation! I'm seeing that the "i" entry is certainly still receiving too much space-- can you instruct me on the location of the new 2bbp VWF kerning table measurements, so I can adjust, please? Another interesting observation is the redraw period during certain menu navigation, like when closing a secondary menu window, this leads to a big redraw that briefly shows the WRAM tiles' arrangement --which is very chaotic and crowded-- before they snap into the expected positions. Great work on this, overall, it's incredible to see a new UI in this very dated game!
{{ does machine work }}
Confirmed both the table location and the root cause of the roomy "i" — and the redraw flash has a clean explanation too. Here's everything: