mirror of
https://github.com/jkdansereau/goldeneye-pc-port.git
synced 2026-10-23 15:52:42 +02:00
James Dansereau
c58797c2da
Chasing D252 further, got the first-ever screenshot proof of this bug family: a plain bullet-impact spark on a Bunker1 door cycling magenta -> purple -> green -> teal -> purple across consecutive shots, captured headlessly via GE_INPUTSCRIPT (Z fire pulses) + GE_PCDUMP together, then reading the resulting PPMs directly (PIL) instead of only grepping a probe log. Traced the call chain (glass2.c's bullet_spark_render, a different code path from both D219's explosion.c particles and D252's IMAGE_FIRE_N system) and ruled out three mechanisms with actual code evidence before finding one that fits: - Not D252's fire-tile system (GE_D252 got zero hits on this repro). - Not a struct-layout/ABI bug (sImageTableEntry is 12 bytes on both 32- and 64-bit, no pointer members -- checked before assuming, per this session's own rule-2 bucket-(a) discipline). - Not the primitive color (g_BulletSparkColors[1], a hardcoded literal for world-prop hits -- always pale yellow). - The texture itself (explosion_smokeimages, IA8, verified via the asset table) has no color channels and decodes correctly. That leaves M-110's G_LIGHTING-not-cleared mechanism (already proposed, unconfirmed, for explosion.c) as the one that fits: bullet_spark_render never clears G_LIGHTING either (only ORs in G_CULL_BACK), so if lighting is on, fast3d reinterprets the vertex color bytes as a lighting normal and computes a scene-light SHADE color instead -- independently converging on the same mechanism at a second call site, for a visually distinct symptom (bullet sparks vs explosions). Flagged honestly as unresolved bucket (b) vs (c): bullet_spark_render's missing lighting clear is decomp-verified N64 ground truth, so a src/game fix needs the port-layer alternative ruled out first, per docs/dev-process.md's own new taxonomy -- not assumed just because the mechanism fits. Also documented the headless-visual-capture technique itself (GE_INPUTSCRIPT + GE_PCDUMP together, then actually opening the PPMs) in porting-notes.md as a reusable method -- several other long-open visual findings (D290/D291/D294) have been stalled purely for lack of eyes on the pixels, not for lack of a working probe. No src/game or port/ changes -- diagnosis only, screenshots are session-local (scratch/, gitignored). findings-index.csv regen was a no-op.