D226: design refinement — HUD scale needs a fast3d span transform (boxes + text + icons), not per-glyph scaling

This commit is contained in:
James Dansereau committed 2026-09-23 15:00:38 -04:00
1 parent 91bd0f84b7
commit 66b33f7f45
1 file changed
+2
+2
View File
@@ -10723,6 +10723,8 @@ D243 (cutscene shake/duplication, its own CONSOLIDATED NEXT STEPS block appears
**Status (from §F table):** **OPEN — root cause / call sites identified, not designed or implemented.** Two viable directions: (a) a `#ifdef PORT` wrapper at just these 2-3 `bondview2.c` call sites that scales the emitted `gSPTextureRectangle` geometry (`xl/yl/xh/yh`) by a new `f32 portHudScale` (default 1.0 ⇒ byte-identical) while inversely scaling `dsdx/dsdy` to keep the same source glyph texels mapped onto the larger/smaller rect, re-anchored so the opposite edge (bottom for the lower-left block, top for dialogue) doesn't move; or (b) thread a scale parameter into `textRenderOutlined`/`textDrawGlyphQuad` itself, defaulted to 1.0 at every other call site. (a) is more surgical (matches the "don't touch shared menu text" constraint) but duplicates a little geometry math; (b) is more central but touches a much more widely shared function. No PD precedent found (PD's port has no equivalent HUD-scale option). F10 overlay slider candidate once implemented, alongside `Video.FovScale`.
**Design refinement (2026-09-23, not implemented).** Per-glyph scaling in `textDrawGlyphQuad` (option a/b above) is insufficient. Both HUD text sites first draw a background box sized to the measured *unscaled* text (lower-left: `draw_blackbox_to_screen`; top dialogue: `microcode_constructor_related_to_menus` over `msg.y..msg.bottom`), NTSC's dialogue path is `textRender`, not `textRenderOutlined`, and the ammo counter pairs text with an icon image (`set_rgba_redirect_generate_microcode`). Scaling glyphs alone would overflow the boxes and split the ammo readout. **Recommended:** a port-side span transform in fast3d, analogous to D335's aspect modes: a new EXT command carrying (scale, anchor x/y) that scales *all* rect and vertex positions (x and y, plus texrect dsdx/dsdy) about the anchor until cleared. The game-side edit is then just a wrap around each HUD call (box + text + icon together), anchored bottom-left for status text, top-centre for dialogue and bottom-right for ammo. The D335 LEFT/RIGHT/CENTER anchoring composes with it. Slider `Game.HudScale` 75–200%, default 100 (no emission, byte-identical).
## D230 — In-level music quality: a bass instrument sounds corrupted on PC, correct on N64 reference (M-105, user reports; repro refined M-106).
**In-level music quality: a bass instrument sounds corrupted on PC, correct on N64 reference (M-105, user reports; repro refined M-106).** Filed to give the post-D77 residual its own label — D77 (in-level music *absence*) is RESOLVED (PR #42, missing `return` in `sub_GAME_7F0C0BF0` zeroed the seqp volume on the only in-level trigger path), so "music doesn't play" claims in tracked docs are stale; what actually remains is this quality gap. **M-106 repro, deterministic (not intermittent):** Control's elevator track and its regular in-level track both carry the bad instrument throughout; Cavern's elevator track has it too; Runway's track is otherwise fine but the same instrument enters ~5–7s after the track starts and sounds bad from then on. User confirmed against original N64 reference audio that a bass instrument belongs there on Runway — this is **not** a wrong-instrument/wrong-bank selection (rules out the D77 trigger-path family and the seqp-volume fix's neighborhood); the instrument choice is correct, only its *sound* is wrong on PC. Determinism (same track, same spot, every time) points at a static decode/synthesis bug for this instrument's wavetable/ADPCM data — most likely low-frequency-specific (pitch-shift/downsample artifacting, a wrap/loop-point error, or a clipping/gain issue that only bites bass-range samples) — rather than a live mixing/voice-stealing issue (D147/D152/D202 family), which would be intermittent. The mixer layer and the trigger layer are both proven working by every track that sounds right, so the suspect neighborhood is the seq/instrument-bank decode path (`csplayer.c`/`synthesizer.c`, bank loading), not `port/` audio plumbing.