From 84ea322a18edacb3220007e59a31c06d9944cbf7 Mon Sep 17 00:00:00 2001 From: Cyd Date: Tue, 21 Jul 2026 15:58:48 -0500 Subject: [PATCH] Document the weapon-fire/pick-range investigation, paused per user Records tonight's finding before stopping this thread: the user correctly pushed back on an oversimplification (the renderer isn't a purely passive wire tap -- the protocol has a real synchronous pick-query shape, sect_pixel/ sect_vector, where the board runs its own Moller-Trumbore ray-triangle test and replies with range+identity). Checked directly against the REAL firmware (not just the reference software renderer's notes): - sect_pixel/sect_vector never appear in this capture -- unused by this build. - Action 0x23 (the notes' fire/pick candidate) gets no reply from the real firmware either (checked via the h_reply hook, which fires on ANY firmware-issued reply) -- but its payload doesn't match the documented FLYK format at all (no screen coords; a counter-tagged discharge-event shape instead), and its wire context (list_remove + zone-color + a PSFX-shaped 0x1d) reads as a weapon-discharge notification with visual consequences, not a pick query. Net: open question, not resolved. BT4.10/MUNGA's real pick/range mechanism (if board-side at all) is not yet identified. Paused per the user rather than continue an open-ended search without a specific pointer. Co-Authored-By: Claude Opus 4.8 --- emulator/firmware-decomp/IG-SHADING-MODEL.md | 43 +++++++++++++++++++- 1 file changed, 41 insertions(+), 2 deletions(-) diff --git a/emulator/firmware-decomp/IG-SHADING-MODEL.md b/emulator/firmware-decomp/IG-SHADING-MODEL.md index 8243b3b1..71ed3036 100644 --- a/emulator/firmware-decomp/IG-SHADING-MODEL.md +++ b/emulator/firmware-decomp/IG-SHADING-MODEL.md @@ -247,7 +247,7 @@ No wire-level investigation done yet. BT411's `gauges-hud.md` / draw pass? a different coordinate space/orthographic projection? a distinct wire action type?) before searching the firmware blind. -### 6d. Weapon-fire rendering — not observed, cause NOT YET INVESTIGATED +### 6d. Weapon-fire rendering / board-side pick-range mechanism — PARTIALLY INVESTIGATED, PAUSED Per BT411 `rendering.md` §"Weapon beams": beams are ordinary TUBE geometry (`ermlaser.bgf`), muzzle-anchored every frame — i.e. on the wire this should look like ordinary create/list_add/draw_scene traffic for a thin, elongated @@ -255,7 +255,46 @@ object, NOT a special ray-trace primitive. Per `combat-damage.md`, the original game's fire/target-lock mechanism is fully reconstructed and working in BT411's port, so a live session showing no fire is more likely an input/ session-state gap (RIO fire button not reaching this DOSBox session) than a -missing render path — check that before assuming a rendering gap. +missing render path. + +**User's counter-point (2026-07-21), correcting an oversimplification above:** +the renderer is NOT a purely passive tap in the strict protocol sense — there +IS a real query/response shape in the wire protocol (VELOCIRENDER_PROTOCOL.md +`vr_sect_pixel`(4)/`vr_sect_vector`(5): synchronous, blocking, the board runs a +REAL Möller–Trumbore ray-triangle test over its own live scene and replies +with an instance handle — "the exact range to the pixel in the center of the +target and what that pixel is a part of"). Whether the SHIPPED BT4.10/MUNGA +build actually uses this path (vs. computing it host-side, as BT411's own +`HudSimulation`/pick-ray reconstruction does) was the open question. + +**Investigated, using this pipeline's unique capability (running the REAL +firmware, not a reimplementation):** +- `sect_pixel`(4)/`sect_vector`(5) never appear on this capture's wire at all + (0 occurrences) — this build doesn't use the 1994-enum pick-query actions. +- Action `0x23` (the notes' "fire/pick" candidate) DOES appear (23 times), and + checked directly against the real firmware's OWN reply mechanism (`h_reply` + hook, which fires on ANY firmware-issued reply regardless of action): NO + reply follows `0x23` in this build either — consistent with the old + fire-and-forget finding, now confirmed against the actual firmware code + rather than just the software reimplementation. +- BUT the `0x23` payload itself does NOT match the documented FLYK format + (`[u:f][v:f][host ptr][-1]`, screen coords) — this build's payload is + `[1][incrementing event ID | 0x30000000][0]`, no screen coordinates. Wire + context around it (`0x23`×2 → `list_remove`×2 → `0x1b`×2 → a 264-byte + `0x1d`, matching the documented PSFX/particle-burst branch ≥160B) reads + like a WEAPON-DISCHARGE NOTIFICATION with visual consequences (a projectile + resolving + effect spawn), NOT a board-side "what's under the crosshair" + query. So `0x23` in BT4.10/MUNGA is very likely NOT the same mechanism the + 1994-era FLYK notes describe under the same action number. + +**Net conclusion: open.** Either this build's real pick/range mechanism lives +under a still-unidentified action, or BT4.10/MUNGA moved this computation +entirely host-side (matching BT411's own architecture) and `0x23` (whatever +it really is) is unrelated to targeting. Paused here per the user +(2026-07-21) rather than open a broader search without a specific pointer — +resume by identifying what wire traffic accompanies a KNOWN weapon fire in a +fresh, targeted capture (fire once, deliberately, with minimal other action +noise) rather than mining an existing capture for a guessed action number. ### 6e. Cockpit cage — intermittent, NOT YET CROSS-CHECKED See `emulator/render-bridge/COCKPIT-CAGE-NOTES.md` (the OTHER renderer's