mirror of
https://github.com/jkdansereau/goldeneye-pc-port.git
synced 2026-10-24 00:02:45 +02:00
James Dansereau
7c48f664ca
* D222/D218: fix high-FovScale culling + add Video.DrawDistance D222 (high FovScale breaks screen-edge culling): currentPlayerSetCameraScale() derives both the frustum-cull plane normals and the fog/LOD distance-visibility-fade scale (c_scalelod/c_lodscalez) from c_perspfovy, which every viSetFovY/viSetAspect/viSetFov/viSetZRange call in fr.c was setting from the nominal fovy -- never the portFovScale-widened value D211 already computes for the actual render projection two lines away. Factored the widen-FOV math into a shared port/src/video.c helper (portScaleFovY, same logic D211 already had inline) and fed it into all 4 currentPlayerSetPerspective call sites. Identity at FovScale=100 by construction. Audited: the affected fields are consumed only by render-side fog-visibility-fade and screen-space transform code (propobj.c/bondview.c), not NPC AI visibility/behavior. D218 (wide FOV exposes the fog/far-clip boundary): implements the previously-parked plan. Video.DrawDistance (percent, 100-400, explicit override) and Video.DrawDistanceAutoFov (couples the multiplier to FovScale by default) applied in fogLoadCurrentEnvironment (bgfog.c) to both the far-clip plane and the fog-blend distance read, so they stay consistent. Clamped to [1.0, 2.5] per the plan's own far-field z-fighting caution. Both new knobs added to the F10 overlay alongside FovScale. Rebuilt clean, crash-free at FovScale=150/DrawDistanceAutoFov=1 on Dam. bunker1 golden framediff was inconclusive in this dev box -- confirmed via an A/B stash/rebuild that the unmodified baseline also fails it by a similar/larger margin (pre-existing frame nondeterminism, not a regression from this change). D249 (default-FOV culling, sometimes) is unrelated/still open -- different mechanism, not touched here. Needs a human's eyes: does high-FOV screen-edge culling and the wide-FOV fog/draw-distance artifacting actually look fixed now. Claude-Session: https://claude.ai/code/session_016DQUKGLZxFtPy52MkKXXog * D249 follow-up: add Video.LodDistance geometry-LOD scaling Found a real, distinct geometry-LOD system in src/game/model.c: MODELNODE_OPCODE_LOD nodes whose children are shown/hidden per-frame by modelUpdateDistanceRelations() testing a view-space distance (scaled by getPlayer_c_lodscalez(), now FOV-consistent per this branch's D222 fix) against each node's MinDistance/MaxDistance -- separate from the fog-visibility-fade D218 already covers. It has an existing ground-truth multiplier hook, g_ModelDistanceScale, already used transiently by the game itself (chr.c's 0.3125f close-up override, front.c/title.c's menu modelSetDistanceDisabled calls). Rather than write to that shared global (would fight those existing overrides), compose a second multiplier at the same call site: portLodDistanceMultiplier() (port/src/video.c), driven by new Video.LodDistance (percent, 25-400, default 100) and Video.LodDistanceAutoFov (default OFF, unlike DrawDistanceAutoFov -- this is meant as a standalone perf lever to pull down, not something that silently costs more as FovScale widens). Inverse-scaled: 200% keeps full detail twice as far (more cost), 50% drops to the lower LOD twice as soon (less cost). Both new keys in the F10 overlay. Identity at LodDistance=100. Rebuilt clean, crash-free at LodDistance=40 (aggressive) on Dam and at defaults on bunker1. Claude-Session: https://claude.ai/code/session_016DQUKGLZxFtPy52MkKXXog * D222/D218 follow-up: fix guard fade-early regression, retune draw-distance coupling Live playtest on Dam found two issues in the D222/D218/D249 work: 1. Regression: D222's c_lodscalez widening (correct for the screen-edge cull planes) is also read directly by propobj.c's chrobjFogVisRangeRelated()/sub_GAME_7F054C58() -- the character/prop fog-visibility-fade cutoff. Uncompensated, this made guards fade sooner at wide FOV than before D222. Fixed by dividing that same c_lodscalez reading by portDrawDistanceMultiplier() at both call sites, so the "how far can you see" question stays answered consistently across both consumers. 2. Tuning: a straight 1:1 FovScale auto-coupling on portDrawDistanceMultiplier() wasn't aggressive enough -- live-tested up twice (1x -> 2x -> 4x FovScale, clamp ceiling raised 2.5x -> 4.0x -> 6.0x each time) until guards held up and the Dam tunnel's blue fog artifact receded. Re-verified the fog ramp itself (not just the far-clip cutoff) scales with the multiplier end-to-end. User confirms this is good for now.