mirror of
https://github.com/RetroPortingToolKit/psxrecomp
synced 2026-10-26 02:11:36 -04:00
Alex Vanderveen
6d564c8eaf
present_should_wall_pace() skipped the wall-clock pacer entirely whenever present_vsync_owns_cadence() was true, trusting the GL swap to block. A swap that does not block then leaves the guest with NO speed limit at all and the game simply free-runs -- indistinguishable, to a player, from a stuck fast-forward. Measured on FF7 (NVIDIA GL under a compositing WM), 45 s, nothing held, telemetry off: driver vsync "owns cadence" 4771 frames ~106 fps 1.77x PSX_VSYNC=0 (pacer forced on) 2651 frames ~58.9 fps 1.00x this change, default settings 2643 frames ~58.7 fps 0.98x Running the pacer underneath vsync is safe because frame_pacer_wait() is deadline-based rather than a fixed sleep: when the swap has already consumed the period, now >= next_deadline and it returns immediately after advancing the deadline. So it costs nothing where vsync works -- and in particular adds no latency to the healthy path, which is why vsync was given sole ownership in the first place -- while supplying the cap where vsync does not block. The frame-interpolation exclusion is kept: that path subdivides this same interval and would genuinely double-pace. The startup line is corrected with it. "wall-clock pacer skipped" is how a bring-up session decides pacing is accounted for, and it is what sent this investigation hunting a phantom stuck fast-forward instead of an unpaced present. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0194TYJAqgyG9a9PJe9uUcgQ