diff --git a/.github/release-notes.md b/.github/release-notes.md
index 44ae7c07..f1cd8470 100644
--- a/.github/release-notes.md
+++ b/.github/release-notes.md
@@ -13,7 +13,7 @@
 
 ## Highlights
 
-- **Frame rates above 60.** Pick 90, 120, 144, 165 or 240, or **Auto** to match your display (up to 240). The game still runs at its original speed; the extra frames are blended between its ticks. A rework of f1zz1ec0ke's #137.
+- **Frame rates above 60.** Pick 90, 120, 144, 165 or 240, or **Auto** to match your display (up to 240). The game still runs at its original speed; the extra frames are blended between its ticks, for the camera, the level, the sky, and the guards, doors and objects moving in it. A rework of f1zz1ec0ke's #137.
 - **macOS on Apple Silicon (experimental).** A new download for M1 and later Macs, based on danturn's #95. Tested on one M3 Mac so far; reports are welcome.
 - **Original controls are now original (#145, #149).** With *Control style* set to Original, your pad behaves as an N64 controller, and *Invert look* works in every original style.
 - **Fixes:** geometry vanishing up close (#150), the first launch opening on the wrong monitor (#151), the end-credits crash on Linux and macOS (#152) and a crash when a guard spawns with a hat (#153, #156).
@@ -57,7 +57,7 @@ The [user guide](https://github.com/jkdansereau/goldeneye-pc-port/blob/v0.6.0/do
 
 ### Added
 
-- **Frame rate cap:** Auto, 90, 120, 144, 165 and 240 join 30 and 60 (F10 → *Video*). Auto is the default on fresh installs; an existing `ge007.ini` keeps its value. Above 60 the extra frames are blended between game ticks (no effect on a 60 Hz display), which adds one tick of latency; a fast camera turn or a big change on screen shows a full frame instead. The *Original N64* display mode keeps 60.
+- **Frame rate cap:** Auto, 90, 120, 144, 165 and 240 join 30 and 60 (F10 → *Video*). Auto is the default on fresh installs; an existing `ge007.ini` keeps its value. Above 60 the extra frames are blended between game ticks (no effect on a 60 Hz display): the camera, the level and the sky, and each guard, door and object along its own motion. This adds one tick of latency; a fast camera turn or a big change on screen shows a full frame instead. The *Original N64* display mode keeps 60.
 - **macOS Apple Silicon download** (experimental), plus source builds with Homebrew's GNU `gcc`.
 - **Original control style as an N64 controller:** every press sends the real N64 button in levels, menus, the watch and the tank. Default layout: South = A, West = B, right trigger = Z, left trigger / RB = R, LB = L, right stick = C-buttons. Each button can be moved per player in `ge007.ini` (`Input.N64Pad.A = a`, ...), and `Input.N64StickFeel` picks the N64's linear stick range.
 - **Mission timer** (#144): an optional always-visible timer, off by default.
@@ -66,6 +66,7 @@ The [user guide](https://github.com/jkdansereau/goldeneye-pc-port/blob/v0.6.0/do
 ### Fixed
 
 - Geometry vanishing when you stand against a wall (#150).
+- With a wider *Field of view*, objects in fog (such as the windows on Surface) no longer flicker or vanish while you turn, and models keep their detail out to the normal distance.
 - The first launch opening on the wrong monitor (#151).
 - A crash during the end credits on Linux and macOS (#152).
 - macOS: a black window that never started the game when it was launched while the display was asleep.
diff --git a/docs/ROADMAP.md b/docs/ROADMAP.md
index 35ab8d17..28194145 100644
--- a/docs/ROADMAP.md
+++ b/docs/ROADMAP.md
@@ -200,9 +200,9 @@ A single campaign pass with these on the checklist would clear most of them.
 | Steam Deck preset skipped when first launched from Desktop Mode | verify | D283 | Fixed on `release/v0.4.1`: the Deck is detected by DMI hardware id (Valve Jupiter/Galileo; `STEAMOS` as a second signal) and the preset applies once per ini, only while Fullscreen/Maximized are untouched. Only a Windows build and a Linux `-fsyntax-only` check ran. **Owed: one run on a real Deck** (Desktop-Mode-created ini, then Game Mode; expect fullscreen 1280x800 and the log line `video: Steam Deck (DMI Valve ...)`). The Known-issues row goes when this ships. |
 | Windows 7 | open | #98 | **Re-checked 2026-10-02: likely feasible around 1.0.** The exe imports no Windows 8+ functions and the bundled SDL2 2.32.10 still supports Windows 7. The real blocker is the first-run converter `ge007-convert.exe` (PyInstaller, Python 3.9+): the native C converter (#6 Part B) removes it, or a separate Python 3.8 build. Work: one Windows 7 VM test, then manual per-release checks (CI cannot test it). Supersedes the earlier 'won't-fix' call. |
 | Alt-tab haze + fast alt-tab recovery | open (v0.7.0, maintainer 2026-10-10) | D578 | Maintainer 2026-10-10 (v0.6.0 build, Windows 120 Hz): alt-tabbing leaves a hazy picture; fast repeated alt-tab is wonky and recovers only after a while or more alt-tabbing. Not new in v0.6.0 (was an owed check). Known issue in the v0.6.0 notes. QoL fix: clean focus-loss/regain path (context/FBO state, present queue reset). |
-| Deck: max Field of view feels choppier while turning | open (maintainer 2026-10-13; goal: fully resolved, not tied to v0.6.0) | D953 | At FOV 90 (menu max) turning feels worse than at 60, at 60 and 90 fps. Frame pacing measured identical at both FOVs. Lead: FovScale pulls every model LOD switch 1.73x closer, and depth-based LOD flips off-axis objects while turning (Dam turn probe: 0 flips at 60 deg, 400 at 90 deg, 120 with the fix candidate on `fix/d953-fov-lod`). Pass 2 (10-13 evening): prop fog fade and fog-range visibility fixed the same way; on Surface LOD/fade/visibility do not change while turning, so they are not the feel. Maintainer: objects "update not at the right speed" (object motion is not interpolated at 90, plan D955). **Next:** D955 Stage 0, and one Deck `GE_D193=1` run per FOV for 2-tick game steps. |
-| Doors and guards flicker at 90 fps (not at 60) | fixed 2026-10-13 (D954); maintainer Deck check owed | D954 | In-between presents drew props (chrs, doors, effects) at the exact camera while rooms used the blended one, so props jumped against the world whenever the camera moved (Surface turn on Windows: 0.4-0.5 deg mean, up to 1.8 deg). Present in v0.6.0 at 90 fps. Fix in `gfx_pc.cpp`: props' plain perspective gets the room camera blend (`P * R^-1 * Rb`) up to the first-person gun. **Owed:** Deck at 90 fps, Surface doors/guards, and the gun must not move while turning. |
-| Objects move at 60 Hz steps at 90 fps (props, doors, guards) | implemented 2026-10-13 (D955); maintainer Deck check owed | D955 | In-between presents drew objects at their tick pose (only the camera was blended). Now blended per joint, keyed by (Model*, joint) from a game-thread snapshot, rebased onto the new camera; exact on room-origin changes, failed gates, split-screen. Dam on Windows: 99.6% of object joint loads blended. **Owed:** Deck at 90: guards walking, gun in hand, hats, deaths, shadows, doors, Facility stall doors/sinks (the old ghost site), room boundaries. Vehicles later. |
+| Deck: max Field of view feels choppier while turning | fixed in v0.6.0 2026-10-13 (D953 LOD/fade/visibility + D954/D955); maintainer Deck-confirmed (Surface windows) | D953 | At FOV 90 (menu max) turning feels worse than at 60, at 60 and 90 fps. Frame pacing measured identical at both FOVs. Lead: FovScale pulls every model LOD switch 1.73x closer, and depth-based LOD flips off-axis objects while turning (Dam turn probe: 0 flips at 60 deg, 400 at 90 deg, 120 with the fix candidate on `fix/d953-fov-lod`). Pass 2 (10-13 evening): prop fog fade and fog-range visibility fixed the same way; on Surface LOD/fade/visibility do not change while turning, so they are not the feel. Maintainer: objects "update not at the right speed" (object motion is not interpolated at 90, plan D955). **Next:** D955 Stage 0, and one Deck `GE_D193=1` run per FOV for 2-tick game steps. |
+| Doors and guards flicker at 90 fps (not at 60) | fixed 2026-10-13 (D954); maintainer Deck-confirmed | D954 | In-between presents drew props (chrs, doors, effects) at the exact camera while rooms used the blended one, so props jumped against the world whenever the camera moved (Surface turn on Windows: 0.4-0.5 deg mean, up to 1.8 deg). Present in v0.6.0 at 90 fps. Fix in `gfx_pc.cpp`: props' plain perspective gets the room camera blend (`P * R^-1 * Rb`) up to the first-person gun. **Owed:** Deck at 90 fps, Surface doors/guards, and the gun must not move while turning. |
+| Objects move at 60 Hz steps at 90 fps (props, doors, guards) | fixed 2026-10-13 (D955 + sky pass); maintainer Deck-confirmed (guards, doors); first-person weapon not blended yet | D955 | In-between presents drew objects at their tick pose (only the camera was blended). Now blended per joint, keyed by (Model*, joint) from a game-thread snapshot, rebased onto the new camera; exact on room-origin changes, failed gates, split-screen. Dam on Windows: 99.6% of object joint loads blended. **Owed:** Deck at 90: guards walking, gun in hand, hats, deaths, shadows, doors, Facility stall doors/sinks (the old ghost site), room boundaries. Vehicles later. |
 | Windows display scaling: the game is not DPI-aware on scaled displays | fixed 2026-10-10 (D626); maintainer by-eye on a scaled display owed | D626 | Seen 2026-10-07 during the v0.5.0 4K captures: on a 3840x2160 display at 125% Windows gives the game a 3072x1728 surface and stretches it, so the picture is softer than native. `gfx_sdl2.cpp` sets `SDL_HINT_WINDOWS_DPI_AWARENESS` only when `allow_hidpi` is off; setting it (`permonitorv2`) on the HiDPI path too renders at native resolution. Workaround today: environment variable `SDL_WINDOWS_DPI_AWARENESS=permonitorv2`. |
 
 ## 5. Modern-remaster layer (port features beyond the N64)
diff --git a/docs/dev/findings-index.csv b/docs/dev/findings-index.csv
index 0abcaaed..9399c6d7 100644
--- a/docs/dev/findings-index.csv
+++ b/docs/dev/findings-index.csv
@@ -464,9 +464,9 @@ D645,FIXED,"Original 1.1: F10 ""Invert look"" did not invert vertical look (#145
 D646,FIXED,"F10 dropdown popup drew over the hint/tooltip panel (popup bounded by the screen edge, not the settings box) —",FIXED 2026-10-12 (ddGeom bounded to the box; maintainer-verified)
 D951,OPEN,"v0.6.0 release gate: Windows golden sweep flags are timing noise in the test, not rendering changes —",OPEN (test-side; 2026-10-13)
 D952,FIXED,"macOS: black window, no frame, when the game starts while the display is asleep (SDL3 Cocoa VSync waits forever on a CVDisplayLink that never started) —","FIXED 2026-10-13 (port-only, gfx_sdl2.cpp; Mac A/B:"
-D953,OPEN,Deck: wide Field of view feels choppier while turning —,OPEN (fix candidate on fix/d953-fov-lod; Dam turn probe 90 deg:
-D954,FIXED,"Doors and guards flicker at 90 fps, not at 60:","FIXED 2026-10-13 (port-only, gfx_pc.cpp + interpportal.c; Windows-measured; Deck check owed)"
-D955,OPEN,"Objects (props, doors, guards) moved at the 60 Hz tick inside a 90 Hz picture:","IMPLEMENTED 2026-10-13 (port-only, gfx_pc.cpp + interpportal.c; Windows-measured; Deck feel check owed)"
+D953,FIXED,Deck: wide Field of view feels choppier while turning —,FIXED 2026-10-13 (v0.6.0; LOD + prop fog fade/visibility follow the game FOV; maintainer Deck-confirmed)
+D954,FIXED,"Doors and guards flicker at 90 fps, not at 60:","FIXED 2026-10-13 (port-only, gfx_pc.cpp + interpportal.c; maintainer Deck-confirmed)"
+D955,FIXED,"Objects (props, doors, guards) moved at the 60 Hz tick inside a 90 Hz picture:","FIXED 2026-10-13 (port-only, gfx_pc.cpp + interpportal.c; sky pass; maintainer Deck-confirmed)"
 D607,OPEN,Address model unified into one header:,DONE 2026-10-07 (macos branch; Windows identity gate:
 D608,FIXED,D34 ANIM_DATA_x re-basing guard in assets/animationtable_data.h was __x86_64__-only:,"FIXED 2026-10-07 (macos branch; mechanical guard widening, arm64 link clean)"
 D609,FIXED,macOS arm64 SIGKILL at exec:,"FIXED 2026-10-07 (macos branch; probe-confirmed; arm64 keeps the 4 GiB pagezero, floor 11.0)"
diff --git a/docs/dev/findings.md b/docs/dev/findings.md
index fee3a65c..d8050cf4 100644
--- a/docs/dev/findings.md
+++ b/docs/dev/findings.md
@@ -875,9 +875,9 @@ covers D24–D69; the log continues in §H (D32 procedure, D70–D121).
 | D646 | **F10 dropdown popup drew over the hint/tooltip panel (popup bounded by the screen edge, not the settings box)** — full `## D646` entry at file tail | FIXED 2026-10-12 (`ddGeom` bounded to the box; maintainer-verified) |
 | D951 | **v0.6.0 release gate: Windows golden sweep flags are timing noise in the test, not rendering changes** — full `## D951` entry at file tail | OPEN (test-side; 2026-10-13) |
 | D952 | **macOS: black window, no frame, when the game starts while the display is asleep (SDL3 Cocoa VSync waits forever on a CVDisplayLink that never started)** — full `## D952` entry at file tail | FIXED 2026-10-13 (port-only, `gfx_sdl2.cpp`; Mac A/B: unfixed 3/3 hang, fixed 0/5) |
-| D953 | **Deck: wide Field of view feels choppier while turning — FovScale moves every model LOD switch 1.73x closer (c_lodscalez built from the rendered fovy, D222)** — full `## D953` entry at file tail | OPEN (fix candidate on `fix/d953-fov-lod`; Dam turn probe 90 deg: 400 -> 120 LOD flips, 60 deg: 0; maintainer LodDistance feel test owed) |
-| D954 | **Doors and guards flicker at 90 fps, not at 60: in-between presents drew props at the exact camera while rooms used the blended one** — full `## D954` entry at file tail | FIXED 2026-10-13 (port-only, `gfx_pc.cpp` + `interpportal.c`; Windows-measured; Deck check owed) |
-| D955 | **Objects (props, doors, guards) moved at the 60 Hz tick inside a 90 Hz picture: in-between presents now blend object motion per joint** — full `## D955` entry at file tail | IMPLEMENTED 2026-10-13 (port-only, `gfx_pc.cpp` + `interpportal.c`; Windows-measured; Deck feel check owed) |
+| D953 | **Deck: wide Field of view feels choppier while turning — FovScale moves every model LOD switch 1.73x closer (c_lodscalez built from the rendered fovy, D222)** — full `## D953` entry at file tail | FIXED 2026-10-13 (v0.6.0; LOD + prop fog fade/visibility follow the game FOV; maintainer Deck-confirmed) |
+| D954 | **Doors and guards flicker at 90 fps, not at 60: in-between presents drew props at the exact camera while rooms used the blended one** — full `## D954` entry at file tail | FIXED 2026-10-13 (port-only, `gfx_pc.cpp` + `interpportal.c`; maintainer Deck-confirmed) |
+| D955 | **Objects (props, doors, guards) moved at the 60 Hz tick inside a 90 Hz picture: in-between presents now blend object motion per joint** — full `## D955` entry at file tail | FIXED 2026-10-13 (port-only, `gfx_pc.cpp` + `interpportal.c`; sky pass; maintainer Deck-confirmed) |
 
 Phase 2 replaced the Phase-1 demo loop with the real `mainproc()` on real OS
 threads, compiled GE's real `src/sched.c`, and brought in PD's fast3d software
@@ -22018,7 +22018,7 @@ FpsCap = 60'`: 20/21 PASS; statue REGRESSION (4.66%, frame 900).
 
 **Status.** FIXED.
 
-## D953: wide Field of view feels choppier on the Deck while turning — LOD switches move closer with FovScale — OPEN (fix candidate, maintainer feel test owed)
+## D953: wide Field of view feels choppier on the Deck while turning — LOD switches move closer with FovScale — FIXED (v0.6.0)
 
 **Symptom (maintainer, Deck).** At the maximum Field of view (90 deg vertical in the menu = `Video.FovScale = 150`) turning feels choppier than at the default 60 deg, at 60 AND 90 fps; frame times look fine. Maintainer can't name a specific artefact ("it just feels worse", "mostly turning").
 
@@ -22036,7 +22036,9 @@ FpsCap = 60'`: 20/21 PASS; statue REGRESSION (4.66%, frame 900).
 Measured (Windows, Surface 1, 1280x800, 60 fps, same scripted look left/right, temp probe from frame 400, since removed): LOD flips 37 / 37 / 37, fade-state changes 1 / 1 / 1, visibility flips 0 / 2 / 0 (FOV 100 / 150 / 150 + fix). Evaluations in the partial fog fade: 256 / 0 / 246, so at max FOV without the fix the props that sit half-faded in Surface's fog at the default FOV were fully invisible; the fix restores them. **On Surface none of these change while turning, so they do not explain the maintainer's "default FOV feels smoother at any fps" (Deck, Surface, 90 fps, D954 build).** Remaining FOV-dependent factor, by code: image-level. At bilinear (the Deck ini: TextureFilter 1) only textures the game flags as mipmapped get mips (`gfx_opengl.cpp` upload), the rest are minified with plain GL_LINEAR, and a 90-deg vertical FOV minifies every surface ~1.7x more, so more of the frame shimmers while the camera moves; thin geometry goes sub-pixel likewise (MSAA 2x). Plus the rectilinear stretch at 116 deg horizontal (edge vs centre screen speed 3.6x, against 1.9x at the default). Discriminating test, no build: FOV 90 with Texture filter = Trilinear (mips on every texture).
 Maintainer (same evening) rejects the texture lead: "models/objects kinda lag behind... like tearing except nothing is tearing... just seem to update not at the right speed." That matches the 90 fps path: in-between passes blend only the camera (D578, D954), so object motion (props and matrix-skinned chrs) still steps at the 60 Hz tick inside a 90 Hz picture. Plan D955 (object-motion interpolation keyed by (Model*, joint), no game hooks) is reviewed (go with changes) and staged; Stage 0 is instrumentation only. Still unexplained: why max FOV feels worse than the default at the same fps. Open lead: GE's wall-clock tick step (frametiming.c) taking 2-tick steps more often at wide FOV on the Deck; never measured (Deck summaries record presents and draw time only); `GE_D193=1` logs render frames vs sim ticks per second.
 
-**Status.** OPEN.
+**Pass 3 (maintainer, Deck, 2026-10-13).** Surface building windows flickered white while the camera moved, at 60 and 90 fps, at FovScale 150: the prop fog fade (`chrobjFogVisRangeRelated`, view depth `zDepth`) was pulled to x0.58, so half-fogged window props went fully invisible; pass 2's `portLodScaleOwnFov` fixes it (maintainer-confirmed on the combined D953+D954+D955 build). Texgen ruled out (probe: Surface's texgen draws keep constant UVs while the camera moves).
+
+**Status.** FIXED (v0.6.0).
 ## D954: doors and guards flicker at 90 fps (not at 60) — in-between presents drew props at the exact camera, rooms at the blended one — FIXED 2026-10-13 (port layer; maintainer Deck check owed)
 
 **Symptom (maintainer, Deck, Surface).** Doors and guards flicker at 90 fps; never at 60 fps. First seen on a D953 test build, but nothing in D953 depends on frame rate (LOD is chosen once per game tick and the in-between passes replay the same list), so the trigger is the D578 interpolation, which only runs above 60 fps.
@@ -22049,7 +22051,7 @@ Maintainer (same evening) rejects the texture lead: "models/objects kinda lag be
 
 **Verified.** Windows build; Surface run as above: convention check ok, 0 passes without a snapshot, the gun disarm hit 431 times per 10 s of gameplay (the remaining passes had no gun drawn). New 10 s log line `D954 prop camera: ...`. Deck build (release recipe: RelWithDebInfo, gcc-14, rpath `$ORIGIN`, bundled SDL2 2.30.0) deployed to the maintainer's shortcut. **Owed:** maintainer Deck check at 90 fps (Surface doors and guards; also the first-person gun while turning, which must not move).
 
-**Status.** FIXED (Deck confirmation owed).
+**Status.** FIXED. Maintainer Deck check 2026-10-13: door/guard flicker gone at 90 fps.
 
 ## D955: object motion at 90+ fps — props, doors and guards moved at the 60 Hz tick inside a 90 Hz picture — IMPLEMENTED 2026-10-13 (port layer; maintainer Deck check owed)
 
@@ -22068,4 +22070,4 @@ Maintainer (same evening) rejects the texture lead: "models/objects kinda lag be
 **Pass 2 (2026-10-13, same evening).** (a) The sky and sky water are pre-projected on the CPU for camera N (`sky.c` G_FLOATVTX_EXT clip-space verts), so on in-between presents the horizon stayed at camera N while the world took the blended camera. Per blend pass the camera-space delta `C = P * R^-1 * Rb * P^-1` (rotation part; the sky is at infinity) is applied to each sky vertex: view point rebuilt from (x_c/sx, y_c/sy, -w), rotated, re-projected; S/T unchanged. Dam: 556-589 passes re-projected per 10 s. (b) Destroyed objects draw world-space matrices under the room projection (`propobj.c` objRender `destroyed` branch), where the camera rebase is wrong: object joints are blended only while the props' corrected plain perspective is loaded (`s_pcam_applied`). (c) The first-person weapon is NOT blended: its loads barely ever come from `hand->weaponModel.render_pos` (counted: under 5 per frame), so it is drawn through another matrix path; follow-up. Dam after (a)+(b): 32,013 of 32,140 keyed joint loads blended, 0 gate rejects, 90.1 presents/s.
 Maintainer, Deck, 90 fps (2026-10-13): guards and doors smooth.
 
-**Status.** IMPLEMENTED (Deck check owed).
+**Status.** FIXED (v0.6.0). Maintainer Deck check 2026-10-13: guards and doors smooth at 90 fps. Follow-up: first-person weapon blend.