mirror of
https://github.com/jkdansereau/goldeneye-pc-port.git
synced 2026-10-23 15:52:42 +02:00
James Dansereau
d2caaa09bc
Extended M-167's freeze technique to render_pos (Bond's own draw position), aiming at the model-duplication symptom M-167 didn't fix. Two live crashes along the way, both from the same root cause: model pointers get reused by the allocator across different logical model instances, so any attempt to skip subcalcmatrices() based on inspecting render_pos's value or caching pointer identity can be fooled into treating a brand-new, uninitialized instance as already-validated -- leaving render_pos at its fresh tombstone value for a later consumer (sub_GAME_7F06C768, computing zDepth) to crash on. Fixed by never skipping subcalcmatrices() at all -- it always runs now, guaranteeing render_pos is never left invalid regardless of model lifecycle. The freeze is purely a contents copy on top of a now-guaranteed-valid buffer. Live-playtest stable (no crash, full session). But the result is informative-negative: freezing unconditionally also suppresses the LEGITIMATE per-shot camera/model repositioning (AI_TRYTeleportingChrToPad moves Bond between several distinct shots during the cutscene), not just the illegitimate intra-shot cycling -- so the camera now looks the wrong direction for later shots and Bond still appears stuck. Both GE_D243X3/GE_D243X4 remain diagnostic experiments, not real fixes. Documented two next-step candidates (delta-threshold re-baseline, or hooking the teleport call directly) for distinguishing legitimate repositioning from the cycling bug. porting-notes.md gets the generalized lesson: freezing a value and freezing a pointer target are different operations -- the latter needs the call that keeps the pointer valid to always run, with the freeze applied to contents afterward, not to whether the call happens.