D219 M-157 correction: measured G_LIGHTING for glass2.c sparks, theory doesn't hold up

Went back and actually tested the G_LIGHTING hypothesis from the
previous commit instead of leaving it as an untested code-reading
inference. Two things prompted this: (1) noticed a code comment near
the existing GE_D172 probe documenting a live result never written up
in findings.md -- "G_LIGHTING is ruled out (5000/5000 samples off)" for
explosion.c's particles specifically, meaning the sibling case this
session's theory leaned on was already empirically disproven, not
merely unconfirmed; (2) that's exactly the kind of unchecked assumption
this session's own rule-2 taxonomy work was written to prevent.

Added GE_D157 (gfx_pc.cpp, gfx_sp_vertex, env-gated, cached getenv):
logs geometry_mode/LIGHTING + resulting shaded RGB whenever a vertex's
raw color bytes match one of glass2.c's g_BulletSparkColors[] entries.
Re-ran the identical Bunker1 repro that produced the magenta/green/cyan
screenshots -- only 2 hits, both LIGHTING=off, both unaffected white,
no hit at all for the pale-yellow value the door-spark path should
produce. Reading: G_LIGHTING likely isn't the mechanism here either
(consistent with the sibling case), though the probe may simply not be
catching the real spark vertices yet (exact-byte-match is fragile).

Corrected the D219 finding to flag the "cross-validates M-110" framing
from the previous commit as superseded, not delete it -- the reasoning
trail (including the mistake) stays visible so a future session doesn't
repeat it. Root cause of the visually-confirmed rainbow bug remains
open; next steps revised to a texture-identity-keyed probe variant.

Added GE_D157 to GE-ENV-PROBES.md. No src/game changes. findings-index
regen was a no-op.

docs/dev/GE-ENV-PROBES.md

@@ -51,6 +51,7 @@ Two classes:
 | `GE_D193B` | `src/game/model.c` (`sub_GAME_7F06D3F4`, `#ifdef PORT`) | Rate-limited (1/97) raw anim root-motion decode trace (D193): `joint=` / `flip=` / `base=` mtx channel index / `frame=` / `tmp=` decoded s16 translation triple from the anim bitstream / `angle=` / `anim` ptr / `bd=`+`bs=` the D32 u32 bitDescriptors/bitStream addresses / `njoints`. M-80 Facility: `base=0`, `angle=0` **always** (root-motion facing delta never non-zero — top lead), `tmp` ≈ (±small, ~1086 hip-height, ±small). Compare `tmp`/`angle` magnitudes against a clean N64 decomp build of the same anim+frame. | **live** (D193) |
 | `GE_D250` | `src/boss.c` (`bossMainloop`, wraps `lvlRender()`, `#ifdef PORT`) | Per-wall-second line: `[D250] lvlRender avg=Nus n=M` — average + count of `lvlRender()` (DL-building: culling/animation/scene traversal) calls that wall-second, isolated from `gfx_run()`'s software-RSP interpretation cost (already covered by the existing "frame rendered in Nus" line). Added M-120 to chase D250 (fps stuck ~45-50 on Dam, ruled resolution/MSAA/vsync/build-flags out already) — found `lvlRender` itself is cheap (~0.5-1.5ms avg), so it is NOT the missing ~10-15ms/frame either; the still-unexplained cost must be elsewhere in the per-retrace-message loop (scheduler/thread round-trip, audio, or something not yet isolated by a targeted timer). Cheap; safe for a full playtest. | **live** (D250) |
 | `GE_D172` | `port/fast3d/gfx_pc.cpp` (`gfx_sp_tri1` — SETCOMBINE dedup log + non-LOD multitex tri dump; `#ifdef PORT`) | Particle magenta/cyan colour (D172). Logs each distinct SETCOMBINE + active cycletype, and — for a 2-cycle tri that consumes TEXEL1 with `tex_lod=0` and a distinct 2nd tile — the tile fast3d *samples* for each texunit vs what the DL *configured*. **Found D172**: 40/40 particle tris configured tile 1 @ tmem 392 (fire) but sampled tile 0 (smoke) → `smoke*smoke`. FIXED (`gfx_lod_tile_offset` `return rdp.tex_lod ? 0 : i`). Probe kept inert. | **live** (D172 FIXED, probe kept) |
+| `GE_D157` | `port/fast3d/gfx_pc.cpp` (`gfx_sp_vertex`, right after the vertex color/lighting branch; `#ifdef PORT`) | D219/D252's "rainbow particle" family — bullet-impact spark on Bunker1 door confirmed by screenshot to cycle magenta/green/cyan (M-157). Keyed on the vertex's raw `v.cn[]` bytes exactly matching one of `glass2.c`'s `g_BulletSparkColors[]` entries; logs `geometry_mode`/LIGHTING state + resulting shaded RGB, to test (and, on the first run, refute) the M-110 G_LIGHTING-reinterpreted-as-normal theory for this call site. Only 2 hits so far (both `LIGHTING=off`, unaffected white) — likely not catching the actual door-spark vertices yet; needs a texture-identity-keyed variant, see D219 M-157's "Next, concrete" list. | **live** (D219/D252, still investigating) |
 | `GE_DVM` | `src/game/gunfire.c` (`gunUpdateAndFire` gate dump + `gunRenderFirstPersonGunModels` render dump; `#ifdef PORT`) | 1P weapon viewmodel (D215). `[DVM]` line: the `field_87F` show/hide gate terms + `Gun_hand_without_item` sub-terms + `copy_of_body_obj_header` RootNode/Switches/numRecords. `[DVMr]` line: `87F` + `cmds_emitted` = gfx commands the weapon `subdraw()` produced (healthy ≈ 150; the D215 bug showed **1**). Rate-limited ~1/s per hand. **Found + verified D215** (`renderdata.flags` read 0 → all weapon DL nodes gated off). Probe kept inert. | **live** (D215 FIXED, probe kept) |
 | `GE_DTEX` | `port/fast3d/gfx_pc.cpp:1001` | Per-`import_texture` param log (dims / line / size / lod / gen_mipmaps). Used to root-cause RC2 and D159. Kept as an inert diagnostic. | **live** (RC2/RC3 not finished) |
 | `GE_TEXDUMP` | `port/fast3d/gfx_pc.cpp:1020`, `port/fast3d/gfx_opengl.cpp:700` | PPM dump of every uploaded texture + a `fmt/siz/palfmt/palidx/pal[0..3]` line. Root-caused D161 (Depot ceiling). Kept as an inert diagnostic. | **live** (RC3 not finished) |

docs/dev/findings.md

@@ -11129,7 +11129,7 @@ if that's recorded anywhere in the D280 write-up above.
 
 **Status (from §F table):** **RESOLVED (M-115, 2026-09-12)** — byte-order fix in `src/game/image.c` scoped by pixel format (16-bit family bswap16-at-store, 32-bit identity); user playtest-confirmed. Superseded history below, which began: **OPEN — observed, not investigated.** Next: `GE_PCDUMP`/`GE_TEXDUMP` a Dam PPK explosion; check whether it's the same `gfx_lod_tile_offset` tile-sampling defect D172 fixed for blood, on an explosion DL D172's fix didn't touch. **Status: re-checked at runtime M-90 — mechanism covered by the D172 fix on current `main`; close pending a human by-eye pass (folds into PR #47 playtest).** **M-89 triage (local-Qwen, static analysis only, not yet runtime-confirmed):** the explosion DLs (`assets/oddtextures.c` `globalDL_0x078/0x120/0x1c8/0x270…`) use the same `G_CYC_2CYCLE`+`G_CC_INTERFERENCE,G_CC_MODULATEIA2`+`G_TL_TILE`, tile0=IA smoke/tile1=RGBA fire mechanism as the already-fixed D172 blood/spark records — no separate/unfixed code path found in `explosion.c` or the asset DLs. If still purple after D172's fix (which the user's Dam report postdates — needs re-confirming on current `main`), the next suspect is the GLSL combiner implementation of `G_CC_INTERFERENCE`+`G_CC_MODULATEIA2` for cycle 2 specifically (`gfx_generate_cc`, `port/fast3d/gfx_pc.cpp:312-494`), not the tile-offset fix. **Next, concrete:** run Dam (`-level_33`) with `GE_D172=1` while triggering a PPK/grenade explosion and check for "BUG" lines in the log (silence = D172's fix already covers this DL and the row can likely close on a re-test; needs a scripted-fire repro, not yet built). **M-90 runtime re-check DONE (scripted-fire repro built with `GE_INPUTSCRIPT`): the D172 fix demonstrably covers Dam's particle DLs — row can close on a human by-eye pass.** Ran `-level_33` headless with `GE_D172=1`, 64 scripted Z-pulses (`GE_INPUTSCRIPT="200:Z;215:Z;..."`, ~15 controller-reads apart) and a `GE_PCDUMP` window over the same span. Result: **40/40 particle multitex tris log `SAMPLED1=tile1 (tmem=392)`** — the correct RGBA fire tile, i.e. exactly the post-D172-fix behaviour (pre-fix these read `SAMPLED1 = tile0 (tmem=0 fmt=IA)`, the smoke texture); **zero** "BUG"/unknown-GBI/D146-abort lines; **0** purple/magenta pixels (`r>120, b>120, g<90, r-g>50, b-g>50`) across all 28 captured frames. Caveat: the user's M-87 "purple" report may predate the D172 fix on their binary (playtests run on whatever build was current); this re-check proves the sampling path is correct on current `main`, which is as far as a headless pass can take it — a final by-eye look at a live Dam PPK firefight is the honest closer (cheap for the user, folds into the D217 PR #47 playtest). **M-108 — REOPENED, the by-eye closer FAILED.** User played a live Dam (`-level_33`) PPK firefight on the current `main` build (post-D233/D234 fixes, same session as D243) and confirmed explosions are **still blue/purple**, directly contradicting M-90's clean scripted-repro result (40/40 correct-tile samples, 0 purple pixels, 28 frames). This means the M-90 `GE_INPUTSCRIPT` scripted-fire repro was very likely **not exercising the same explosion instance/DL the live firefight hits** — plausible gaps: a different explosion variant (grenade vs. bullet-impact spark vs. enemy-death vs. PPK-specific muzzle/hit effect) using a DL the scripted test's Z-pulses didn't trigger, or a state/lighting/prim-color condition (M-89's alternate suspect: the `G_CC_INTERFERENCE`+`G_CC_MODULATEIA2` cycle-2 GLSL combiner implementation, `gfx_generate_cc`, `port/fast3d/gfx_pc.cpp:312-494`) that only manifests under conditions the synthetic repro didn't reproduce. **Do not trust the M-90 all-clear for this finding going forward** — it proved one particle path clean, not that Dam's live-fire purple is fixed. Next: a live `GE_PCDUMP`/`GE_D172=1` capture during an actual purple explosion in real play (not a scripted approximation) is now the only way forward — need to pin down exactly what triggers it (PPK gunshots hitting a surface/enemy? a thrown/tossed explosive? which). **User has now confirmed (2026-09-12) this is NOT Dam-exclusive — game-wide, not just suspected.** Treat as confirmed scope, not pending a second-level check. **User wants this actively fixed, not just triaged** — next session should prioritize a live `GE_PCDUMP`/`GE_D172=1` capture during a real explosion (any level) over further static analysis, since the M-89/M-90 static passes are exhausted on this finding without producing a fix. **New HIGH-interest lead (M-110): `explosion.c` never clears `G_LIGHTING` before drawing any of the 15 particle DLs** (`globalDL_0x078` through `0x9a8` in `assets/oddtextures.c`, all structurally identical, all `G_CC_INTERFERENCE`+`G_CC_MODULATEIA2`) — grepped every particle-draw call site in `explosion.c` (`gSPClearGeometryMode` calls at lines 883/1495/1718/2227 only ever clear `G_CULL_BOTH`/`G_FOG`/`G_CULL_FRONT`, never `G_LIGHTING`) and confirmed `G_CC_INTERFERENLine truncated
 
-**M-157 (2026-09-16/17, this session): the M-110 `G_LIGHTING` mechanism is now CROSS-VALIDATED at a second, independent particle-draw call site — and this one has a real visual capture.** While chasing D252 (see that entry's M-156), reused the `GE_INPUTSCRIPT` Z-pulse technique on a bare `-level_09` (Bunker1) boot with `GE_PCDUMP` running, aimed at a plain metal door. **Got the first-ever visual capture of this bug family**, and it is dramatic: the same bullet-impact spark, hitting the same spot on the same door across consecutive shots, renders as bright **magenta** (frame 108), fading pale-purple (114), **green** (129), **teal/cyan** (144), purple again (198) — a literal hue-wheel cycle, screenshots in `scratch/d252_impact_zoom_*.png` (session-local, not committed — small enough to re-capture on demand with the command below). This is a plain rifle/pistol bullet hitting a static door, nowhere near an explosion — a different, previously uninvestigated code path from both D219's `explosion.c` particles and D252's `IMAGE_FIRE_N` aging system.
+**M-157 (2026-09-16/17, this session): first real visual capture of this bug family — but the G_LIGHTING theory below turned out to be a plausible-looking dead end, corrected at the end of this entry; read the whole thing, not just the first paragraph.** While chasing D252 (see that entry's M-156), reused the `GE_INPUTSCRIPT` Z-pulse technique on a bare `-level_09` (Bunker1) boot with `GE_PCDUMP` running, aimed at a plain metal door. **Got the first-ever visual capture of this bug family**, and it is dramatic: the same bullet-impact spark, hitting the same spot on the same door across consecutive shots, renders as bright **magenta** (frame 108), fading pale-purple (114), **green** (129), **teal/cyan** (144), purple again (198) — a literal hue-wheel cycle, screenshots in `scratch/d252_impact_zoom_*.png` (session-local, not committed — small enough to re-capture on demand with the command below). This is a plain rifle/pistol bullet hitting a static door, nowhere near an explosion — a different, previously uninvestigated code path from both D219's `explosion.c` particles and D252's `IMAGE_FIRE_N` aging system.
 
 **Traced the actual call chain and ruled out three plausible mechanisms with code evidence before finding a fourth that fits:**
 1. **Not the D252 fire-tile system.** `GE_D252=1` (hooked in `import_texture_rgba16`) got **zero hits** on this exact repro — this bug fires through a different texture-loading path entirely.
@@ -11145,6 +11145,12 @@ if that's recorded anywhere in the D280 write-up above.
 
 Repro for future sessions (headless, no game code touched): `GE_PCDUMP="0-1200:3" GE_INPUTSCRIPT="60:Z;70:Z;80:Z;...;350:Z" ./build-pc/ge007.x86_64.exe -level_09`, then inspect `ppm/frame_0001*.ppm` visually (or via any PPM viewer) near the door directly ahead of Bunker1's spawn — the spark reproduces on nearly every shot. This headless-visual-capture technique (`GE_INPUTSCRIPT` + `GE_PCDUMP` together, then inspecting the resulting PPMs directly) is itself a reusable finding for future "does this actually look wrong" investigations in this project — no live human needed to get eyes on a rendering bug, which several other OPEN findings (D290, D291, D294) have been stalled on for exactly that reason.
 
+**Correction, same session, right after writing the paragraphs above: went back and actually measured G_LIGHTING instead of trusting the pattern-match to M-110.** Missed on first pass that the code comment at `gfx_pc.cpp` (right next to the D219 `GE_D172` probe, ~line 2015) already documents a live result never written up in this findings.md file: **"D219 round 2: G_LIGHTING is ruled out (5000/5000 samples off, live-confirmed still purple/blue)"** for `explosion.c`'s particles specifically — the sibling case the M-157 write-up above leaned on had *already* been empirically disproven, not merely unconfirmed. That should have been caught before asserting a "cross-validation" for `glass2.c` on code-reading alone.
+
+Added a small, targeted diagnostic (`GE_D157`, `port/fast3d/gfx_pc.cpp`, right after the vertex color/lighting branch in `gfx_sp_vertex`, `#ifdef PORT`, cached getenv) that logs `geometry_mode`/`LIGHTING` state and the resulting shaded RGB whenever a vertex's raw `v.cn[]` bytes exactly match one of `glass2.c`'s `g_BulletSparkColors[]` entries (`{0xFF,0xFF,0xFF,0xFF}`, `{0xFF,0xFF,0xC8,0xFF}`, `{0xFF,0x00,0x00,0xFF}`). Re-ran the identical Bunker1 repro that produced the magenta/green/cyan screenshots: **only 2 hits, both `LIGHTING=off`, both pure white `(255,255,255)` unaffected** — no hit at all for the pale-yellow `(255,255,200)` value `objHit`'s door-spark call path should produce via `g_BulletSparkColors[1]`. Two possible readings, both worth recording: **(a)** most likely, **G_LIGHTING genuinely is off here too, and this mechanism does NOT explain the bullet-spark rainbow** — consistent with the sibling explosion.c case, and the two white hits this probe did catch (probably the correctly-rendering muzzle flash, `arg2==4`/`6`'s `flareimage2` branch) support that lighting is off for this whole particle family in this scene; **(b)** the probe's exact-byte-match approach may simply not be catching the actual spark vertices at all — vertex color could be getting modified before reaching this function by something not yet traced (Gouraud interpolation across the quad, a different `gfx_sp_vertex` call site, or `arg2`'s value at runtime differing from the `1` literal read in the static source). **Confidence: LOW-MEDIUM that G_LIGHTING is not the mechanism; the real root cause of the visually-confirmed rainbow cycling is OPEN AGAIN, not narrowed.** Do not carry the "cross-validates M-110" framing forward — that phrase in the first paragraph of this entry is superseded by this correction, kept only so the reasoning trail (and the mistake) stays visible.
+
+**Next, concrete, revised:** (1) confirm whether `GE_D157` actually fires at all during the visible magenta/green frames by cross-referencing frame numbers (`num_dls`) against the known-bad frame range (108-220 in the repro above) — if it never fires in that window, the probe is looking at the wrong vertices entirely and needs a texture-identity-based trigger instead (key on `explosion_smokeimages`/`flareimage2`/`scattered_explosions`'s actual runtime texture address, the way D252's probe keyed on `IMAGE_FIRE_N`'s addresses) rather than an exact vertex-color match. (2) Once the probe reliably fires on the actual bad frames, log the full RGBA path in the frame the screenshot shows magenta/green, not just LIGHTING state — the D217-style texture-cache-collision lead already proposed for `explosion.c` (see the code comment cited above) applies here too and hasn't been checked for this call path at all. (3) `GE_D157` is left in tree, env-gated, zero cost unset — extend it rather than replacing it.
+
 
 ## D250 — FPS is inconsistent/low on many levels after 60 Hz shipped (M-119, user QA; D248 follow-on).
 

port/fast3d/gfx_pc.cpp

@@ -1501,6 +1501,36 @@ static void gfx_sp_vertex(size_t n_vertices, size_t dest_index, const Vtx* verti
             d->color.b = vcn->b;
         }
 
+#ifdef PORT
+        /* D157 diag (temporary, session 2026-09-16/17): does bullet_spark_render
+         * (glass2.c) actually draw with G_LIGHTING on? The M-110 mechanism
+         * (this vertex's v.cn[]/n.n[] union reinterpretation above) was
+         * already ruled out for explosion.c's particles (5000/5000 samples
+         * measured LIGHTING=off, see the D219 comment a few hundred lines
+         * below) -- don't assume it holds for glass2.c's bullet sparks
+         * without measuring. Key on the ORIGINAL authored bytes
+         * (v->v.cn[], readable regardless of which branch fired above,
+         * since n.n[]/cn[] are the same union storage) matching one of
+         * glass2.c's g_BulletSparkColors[] entries exactly. */
+        static int ge_d157 = -1;
+        if (ge_d157 < 0) ge_d157 = getenv("GE_D157") != NULL;
+        if (ge_d157) {
+            static const uint8_t known[][4] = {
+                {0xFF,0xFF,0xFF,0xFF}, {0xFF,0xFF,0xC8,0xFF}, {0xFF,0x00,0x00,0xFF},
+            };
+            for (const auto& k : known) {
+                if (v->v.cn[0] == k[0] && v->v.cn[1] == k[1] && v->v.cn[2] == k[2] && v->v.cn[3] == k[3]) {
+                    sysLogPrintf(LOG_NOTE,
+                        "D157: bulletspark-color-match cn=(%d,%d,%d,%d) geometry_mode=%08x LIGHTING=%s -> shaded=(%d,%d,%d)",
+                        v->v.cn[0], v->v.cn[1], v->v.cn[2], v->v.cn[3], rsp.geometry_mode,
+                        (rsp.geometry_mode & G_LIGHTING) ? "ON" : "off",
+                        (int)d->color.r, (int)d->color.g, (int)d->color.b);
+                    break;
+                }
+            }
+        }
+#endif
+
         d->u = U;
         d->v = V;