findings: D249 static review rules out two suspects, narrows to portal BFS

Confirmed correct level IDs (Streets=29, Egyptian=32, not the finding's
original level_20 guess). Source review clears both the unscaled-far-clip
and LOD-distance-multiplier hypotheses (bgfog.c/video.c both already scale
consistently). Narrowed to bg.c's portal/room-visibility BFS as the one
remaining suspect -- could be a real bug or just N64 behavior newly visible
on PC's sharp display; needs a live screenshot + location before touching
this decomp-verbatim system, not more static tracing.

Headless GE_PCDUMP long-sightline attempts on Streets/Statue/Egyptian did
not transfer from the D245 technique -- none of them have a scriptable path
to an open sightline without real level navigation.

Claude-Session: https://claude.ai/code/session_01KwZViAFaXua3PKgHHjNgvi

docs/dev/findings-index.csv

@@ -144,7 +144,7 @@ D245,OPEN,IsWater water: two competing patterns with a visible seam that moves a
 D246,OPEN,"Tiny pixel strips at the left and right edges of the screen, ""like overscan"" —","OPEN — one candidate ruled out (M-116 follow-up), root cause not found."
 D247,RESOLVED,Black bars top and bottom of screen —,"NOT A BUG — confirmed faithful, unmodified N64 decomp behaviour, no code change made."
 D248,FIXED,"Port runs a stable 30 FPS instead of 60 FPS game-wide (M-117, user asked to verify FPS after the D209 timing-keystone fixes).","FIXED, root-caused to a genuine pointer-width ABI bug in src/sched.c (compiled for the PC build, not excluded)."
-D249,OPEN,"LOD/culling breaks down on large open levels (Streets, Egyptian named specifically) at *default* FOV —",OPEN — not investigated.…
+D249,OPEN,"LOD/culling breaks down on large open levels (Streets, Egyptian named specifically) at *default* FOV —","OPEN — M-142 static review ruled out the unscaled-far-clip and LOD-multiplier suspects (both already correct); narrowed to the portal/room-visibility BFS, needs a live screenshot+location, not more c…"
 D250,FIXED,"FPS is inconsistent/low on many levels after 60 Hz shipped (M-119, user QA; D248 follow-on).","FIXED — per-call getenv() cost was the bottleneck; rock-steady 60-61 fps after, user re-tested 1440p/4K clean."
 D251,FIXED,F10 options overlay QoL pass:,"FIXED (port-only, port/src/optionsoverlay.c)."
 D252,OPEN,"Particle effects cycle through a rainbow palette (M-124, user playtest of the v0.2.0-pre candidate).",OPEN — root cause genuinely open as of M-141:

docs/dev/findings.md

@@ -551,7 +551,7 @@ covers D24–D69; the log continues in §H (D32 procedure, D70–D121).
 | D246 | **Tiny pixel strips at the left and right edges of the screen, "like overscan" — look like raw pixels, not 3D graphics (M-116, user QA report).** — full `## D246` entry at file tail | **OPEN — one candidate ruled out (M-116 follow-up), root cause not found.** Step (1) from the original plan is done… |
 | D247 | **Black bars top and bottom of screen — possible aspect-ratio defect (M-116, user QA report).** — full `## D247` entry at file tail | **NOT A BUG — confirmed faithful, unmodified N64 decomp behaviour, no code change made.** `GE_PCDUMP` captures (both against the pre-existing save and a fresh-EEPROM run, to rule out a stale `Screen` option from earlier test sessions) show the exact same inset on Frigate… |
 | D248 | **Port runs a stable 30 FPS instead of 60 FPS game-wide (M-117, user asked to verify FPS after the D209 timing-keystone fixes).** — full `## D248` entry at file tail | **FIXED, root-caused to a genuine pointer-width ABI bug in `src/sched.c` (compiled for the PC build, not excluded).** `osScAddClient()` (`src/sched.c:187-199`) stashes a per-client "present every retrace vs.… |
-| D249 | **LOD/culling breaks down on large open levels (Streets, Egyptian named specifically) at *default* FOV — far-away geometry has visible culling issues (M-119…** — full `## D249` entry at file tail | OPEN — not investigated.… |
+| D249 | **LOD/culling breaks down on large open levels (Streets, Egyptian named specifically) at *default* FOV — far-away geometry has visible culling issues (M-119…** — full `## D249` entry at file tail | OPEN — M-142 static review ruled out the unscaled-far-clip and LOD-multiplier suspects (both already correct); narrowed to the portal/room-visibility BFS, needs a live screenshot+location, not more code reading.… |
 | D250 | **FPS is inconsistent/low on many levels after 60 Hz shipped (M-119, user QA; D248 follow-on).** — full `## D250` entry at file tail | FIXED — per-call `getenv()` cost was the bottleneck; rock-steady 60-61 fps after, user re-tested 1440p/4K clean. |
 | D251 | ****F10 options overlay QoL pass:** — full `## D251` entry at file tail | **FIXED (port-only, `port/src/optionsoverlay.c`).** (a) The panel now computes how many rows fit the *actual* current 2D height (`maxVisibleRows()` from `viGetY()`) and scrolls… |
 | D252 | **Particle effects cycle through a rainbow palette (M-124, user playtest of the v0.2.0-pre candidate).** — full `## D252` entry at file tail | OPEN — root cause genuinely open as of M-141: both named hypotheses refuted (width/height derivation; byte-group order); unverified new lead = shared TMEM slot 0x188 / GL-cache key reuse across the 15 fire records. Cheap repro: bullet-impact sparks. Documented only for v0.2.0-pre per user instruction. |
@@ -10744,7 +10744,9 @@ crash class C2 (Facility `-level_34`, Runway `-level_35`): `import_texture_i8` A
 
 **LOD/culling breaks down on large open levels (Streets, Egyptian named specifically) at *default* FOV — far-away geometry has visible culling issues (M-119, user QA report).** Distinct from **D222** (which is specifically high `Video.FovScale` breaking *near-screen-edge* culling on NPCs/objects — not implicated here, default FOV) and from **D218** (the fog/far-clip *tint* boundary at wide FOV — also not the same symptom). This report is at the stock FOV, on the game's two biggest/most-open outdoor-scale levels, affecting *far* geometry specifically — points at either (a) a portal/room-visibility BFS cutting off too aggressively at range on large multi-room layouts (same neighbourhood as D233/D234's near-camera portal-cull bugs — worth checking whether D233's `gfx_sp_tri1` w<0 trivial-reject fix, which only guarded *behind-camera* vertices, has a sibling far-plane/depth-range case), or (b) GE's own N64 LOD/detail-swap system (mip-tile / simple-model substitution at distance — see D218's still-open question of "does GE have a separate geometry/object LOD-swap distinct from `Visibility.FarFog`") not being ported faithfully, popping or dropping geometry instead of swapping detail level. **Second, separate ask bundled in the same report:** the user would like LOD **improved** in general (presumably distance-based detail transitions look rougher/more abrupt on PC than remembered) but explicitly wants this **gated behind a toggle** so the original N64-accurate LOD behaviour stays selectable ("in case you want old school graphics") — i.e. this is a QoL feature request layered on top of a correctness bug, not one fix.
 
-**Status (from §F table):** OPEN — not investigated. Next: reproduce on Streets (`-level_20`) and Egyptian (`-level_08`, confirm level id) at default `Video.FovScale`; `GE_PCDUMP` a long sightline where geometry visibly drops/pops, cross-referencing whatever governs GE's LOD-tile selection (`gfx_lod_tile_offset` family, already touched by D172/D219) and the portal/room-visibility walk (D233/D234 neighbourhood) to determine which of (a)/(b) is actually firing before designing a fix or the requested toggle.
+**Status (from §F table):** OPEN — static review this session ruled out two of the three suspects; the remaining one needs a live repro, not more code reading. **Level IDs confirmed:** Streets = `-level_29` (not `-level_20` as originally guessed — that number was Egyptian's neighbourhood; Egyptian itself is `-level_32`, `verify.sh`'s alias `egypt`). Attempted a headless `GE_PCDUMP` long-sightline capture (same technique as D245's scripted-turn probe) on both — **abandoned as a bad test**: Streets spawns directly behind a barricade/wall (no open sightline at all from the reachable start), and Statue's (`-level_22`) relevant open vista is well past the spawn point, behind navigation this session has no reliable scripted way to reach (unlike D245's in-place camera turn, walking through a level's actual layout via blind `GE_INPUTSCRIPT` button-mashing risks getting stuck on geometry/AI and wouldn't reliably land at the right spot even if it didn't). **This one genuinely needs a live human capture** (screenshot + exact location) before further diagnosis — logged here rather than burning more session time on scripted navigation guesses.
+
+**Two of the three original suspects ruled out by source review (no live access needed for this part):** (1) **Not an unscaled far-clip plane.** Checked whether `Video.DrawDistance`'s fog-distance scaling (D218) forgot to extend the actual projection matrix's far-clip plane by the same factor, which would hard-cull geometry the fog says should still be visible — it doesn't: `fogLoadCurrentEnvironment` (`bgfog.c:311-345`) computes one `scaledFarFog` value and feeds it to *both* `viSetZRange`'s far argument (which becomes `g_ViBackData->zfar`, the actual `guPerspectiveF` far plane in `fr.c:736`) *and* the fog-blend-distance math (`g_CurFogDetails.scaled_far_fog_dist`) a few lines later — they can't drift apart. (2) **Not the LOD-distance multiplier.** `portLodDistanceMultiplier()` (`port/src/video.c:196`) is a plain `100.0f/pct` scale with `pct` clamped to `[25,400]`, applied to `modelUpdateDistanceRelations`'s per-model LOD-swap distance (`model.c:1962`) — at the port's own default (`cfgLodDistance=150`), this makes `distance` *smaller* (multiplier ≈0.667), which per the function's own documented sense keeps *more* detail visible farther out, not less. Both mechanisms are self-consistent, already more generous than stock N64, and not a plausible source of "geometry drops/pops" at default settings. **Remaining live suspect, unconfirmed:** GE's own screen-space portal/room-visibility BFS (`bgDetermineVisibleRooms`/`bgQueuePortalTraversal`/`bgRectIntersect`, `bg.c`) — a decomp-verbatim system, not distance-based per se but screen-space-rect-based (a portal's *projected* bounding box vs. the parent room's, `bgRectIntersect` at `bg.c:1812`). Its **near-camera** degenerate case (a portal straddling z=0 producing huge/NaN screen coords) was already found and fixed as D106/revised-by-D271 (`bg.c:1724-1751`, `#ifdef PORT` guard) — but there is no equivalent guard, and no evidence of one being needed, for the opposite **far-camera** case: a portal at long range legitimately projects to a small (but numerically fine, non-degenerate) screen rect, and if that rect fails `bgRectIntersect` against the parent/screen box, the room is correctly culled per N64's own algorithm. That could be either (a) a genuine mismatch this port introduces somewhere in the projection chain that N64 didn't have, or (b) N64's own always-present behavior that's simply more visible on PC's sharp, high-res display than it ever was through a blurry N64-era CRT/composite signal — the same "reveal, not regression" pattern several other findings in this project have hit (cf. D227's tc-overflow, invisible until a related fix made textures correct). **Cannot distinguish (a) from (b), or find a concrete bug to fix, without a screenshot + exact in-level location from a live playthrough** — do not touch `bg.c`'s portal BFS without that evidence; it's large, sensitive, decomp-verbatim game logic (AGENTS.md non-negotiable #2), not a narrow ABI-class case like D106/D271's near-plane guard was.
 
 ## D251 — **F10 options overlay QoL pass: