Windows: high FPS counter but 60 Hz-feeling motion

[MikuArt]

Hello, you did a really good job on this project congrats!
Im having an issue, the game is running at 165fps stable but the game feel like it's running at 60FPS or less do you know what could be the issue? in game the fps show 165 when using the console so I have no idea how I could fix it

[lordlad]

i had the same experience...

it shows framerate in the triple digits but it's chugging left and right and it definitely doesn't feels like 60+fps at all....

[themuffinator]

thanks for the feedback. what's your setup?

[MikuArt]

thanks for the feedback. what's your setup?

GPU: RTX 3070 Ti
CPU: 13th Gen Intel Core i7-13700K
RAM: 32 Go
Screens: OMEN 25i using G-SYNC (Main) GN246HL (Secondary)

[themuffinator]

platform?

[MikuArt]

platform?

Im using Windows 11 25H2

[MikuArt]

Here is a small video to show the issue some kind of "micro stuttering" I mean it doesn't look like 165FPS don't know if that stuttering but it's not smooth at all (I know it's a video so it's not going to be 165FPS but I hope you can see what I mean)

Enregistrement.2026-08-13.123421.mp4

[themuffinator]

This is a genuine code defect, not just a G-SYNC/driver support question.

The engine-side decoupled-presentation work in 7858254e presents every capped frame while the authoritative game clock remains 60 Hz. The matching game-side interpolation work never reached openQ4-game/main: current SP/MP Game_local.cpp::Draw renders the latest player snapshot directly, with no PreparePlayerSceneForRender, presentation snapshots, or pm_presentViewBias. Those hooks exist only on the old high-framerate-rendering-phase3/4 branches.

That precisely explains a truthful 165 FPS counter while camera/viewmodel/world state repeats a 60 Hz snapshot. The high-framerate plan/release-completion text is therefore ahead of the game code that was actually packaged.

I am porting the stranded presentation work onto current companion main rather than blaming the display setup or blindly merging an old branch that has diverged substantially. This issue remains the canonical high-refresh smoothness report.

For final A/B evidence, please still attach a com_showFramePacing 2 log and note actual display refresh, com_maxfps, r_swapInterval, window mode, VRR state, and a one-monitor comparison. Those can expose a secondary pacing issue, but they do not change the missing-interpolation defect.

[MikuArt]

com_showFramePacing log.txt

With window mode I tested full screen, windowed etc it's the same.

[themuffinator]

Thank you — this log is exactly the evidence needed.

I parsed 176 complete frame-pacing snapshots from it. Presentation is genuinely running at 134.3–165.9 Hz (mostly 153–165 Hz), with p50 6 ms, p95 9 ms, p99 10–11 ms, and zero wait overshoot/wake jitter, while the authoritative game clock remains exactly 60 Hz (ticDelta/frame about 0.36–0.42). That confirms the primary defect is repeated 60 Hz game snapshots, not a false FPS counter or scheduler cap.

There is still a smaller pacing tail—isolated maxima reached 54 ms—so after the interpolation build lands I will want the same capture repeated to separate residual stalls from the now-confirmed motion-quantization problem.

The current companion branch implements the first safe slice: SP/MP/spectator first-person camera origin/axis/FOV plus the complete viewmodel pose are interpolated only during Draw; gameplay, physics, scripts, networking, demos, and saves remain authoritative at 60 Hz. It intentionally blends previous→current over one tic (up to ~16.7 ms presentation latency) rather than extrapolating through collision/prediction. Broader world entities/FX and raw-input compensation remain follow-up work. I will link the draft PR after its independent edge-case review is incorporated.