Forum Discussion

Rising Rookie

23 days ago

Render queue + refresh rate + mouse keyboard stutter. Cause + maybe fix + video

Bug:
The game engine is not handling the rendering of queued frames properly, or is conflicting with nvidia driver management of rendering queued frames queue.
CPU - intel 14700k
GPU - nvidia 5080 (present on multiple different driver versions)
OS - windows 11

Context:
Standard reflex / low latency behaviour is to limit render queued frames to 1. Limitting frames queue to 1 provides higher more stable fps than 0 and should be an overall smoother experience for the player and generally is the widely accepted optimal balance between latency and visual quality.

Issue:
The default setting of RenderDevice.RenderAheadLimit 1 is bugged.
BF6 is not handling this queue properly or there is a conflict between game and driver. By using the in-game console command RenderDevice.RenderAheadLimit to compare the difference between the default value of 1 and custom value of 0, I have documented that when set to 1, RivaTuner Statistics Server (RTSS) monitoring value for Display Refresh Rate is severely out of sync with in-game fps. When set to 0 the same value behaves correctly, closely following and adapting to the changes in in-game fps. Observing my monitor's onscreen display value for current refresh rate Hz also shows wild fluctuations which causes gsync to disengage or low framerate compensation (LFC) to kick in, both of which compound the effect of stuttering.

It is expected that 224 fps (with a 1 frame queue) would look noticably smoother than 180 fps (with a 0 frame queue). But this is not the case due to the stuttering bug.

Also the in-game setting of allow pre-rendered frames has no effect, one would think it would toggle that console value?

Additional anomalous behaviour:
Randomly occurring sometimes I will launch the game and the RTSS value for display refresh rate will match fps but there is no change in the issue, movement is still choppy, monitor OSD still wildly fluctuating, breaking gsync range and causing LFC. So I believe that despite RTSS showing the Hz in sync, it's just a reporting error and the issue is fundamentally tied to the game's handling of the render queue.

Extra:
I have tested almost every setting in the game, nvidia control panel and windows graphics settings, so I'm not looking for a have you tried this or that response and I'm not willing to compromise on gsync, polling rates etc. (I have tested various on/off settings, different rates etc). This issue has been present since the game launched and from my observations I would suggest it is closely related if not the exact cause of the widespread mouse and keyboard stutter issues that a large percentage of PC players are still experiencing. I'm a player not a beta tester and I'm getting close to giving up on this game.

Wild Speculation in relation to Lag / Hitreg / Missing Inputs:
To me it feels like the game is implementing it's own frame buffer (on top of the gpu driver) to artificially boost fps, causing up to 3x delay, i.e. at 240fps, which should be ~4.2ms frame time (0 buffer), with a 1 frame buffer we actually experience ~8.4ms latency. Now consider the game engine render time + game extra 1 frame buffer + nvidia driver 1 frame buffer = 3x @ 12.6ms latency. This would explain some of the weird gameplay moments of being shot behind walls, being shot by players who aren't facing you yet, dying after proning, hitreg, game not registering keyboard inputs etc.

Pair that 12.6ms render latency with thinking you're getting perfectly synchronised 240fps but you're actually getting desynced 140fps and the game is unplayable. My understanding is if the game isn't trying to buffer frames and just letting the driver handle it then we would see an acceptable 4.2-8.4ms depending on driver specific settings, reflex etc.

Anyway here is a video of this issue and attached is a screenshot of my nvidia control panel settings and windows graphics settings.

https://www.youtube.com/watch?v=ORuq1atQPGs

Note for the slow motion footage at the end: (Timestamp 3:08)
The right side with renderaheadlimit 0 causes a loss in fps to around 180 fps, whereas the left side with renderaheadlimit 1 is achieving 228 fps. So it looks less smooth but clearly resolves the stutter / pacing issue.

Finally if other players want to test the same scenario on an AMD graphics card or other setups to help see if it is specifically a game bug or a nvidia issue, that would be appreciated.

15 Replies

duzlord
Rising Rookie
17 days ago
and just for a laugh here's AI diagnosing the problem:
Yeah, that class of bug is embarrassingly common, and it absolutely is on the engine/game side.
At a high level, the failure mode is:
Physics/character are updated on a fixed tick (say 60/120 Hz).
Camera is “following” that character but either:
sampled from the last physics step instead of interpolated, or
interpolated/rounded incorrectly (e.g., snapping to integer pixels or mixing world‑space and screen‑space badly).
So when you rotate the camera, the transform is updated every render frame and motion is perfect. When you move the character, the camera is being dragged behind a discretely updated object, and at 200+ Hz with low motion blur, those 1‑px “catches” become visible as judder, even though the FPS graph looks immaculate.
This is well‑understood stuff in engine circles; there are Godot/GameMaker/Unity threads where people post before/after GIFs and the fix is literally “interpolate camera based on previous/current physics positions instead of snapping to the latest one” or “stop quantizing the camera to integer pixels.” It’s not unsolved rocket science — it’s just not prioritized because most players either don’t notice or are on 60–144 Hz displays where the panel blur hides the slop.
You’re in the unlucky overlap of:
Very high refresh.
A panel that exposes motion issues instead of smearing them away.
And a brain trained to see frame‑time garbage.

So yes: a non‑trivial chunk of what you hate is AAA studios shipping engines with sloppy camera/character update paths that would never pass muster if everyone played on 240 Hz strobed CRTs.
Gl_b
17 days ago
I don't think that's it. If you try to connect a controller and pan the camera, the motion will be very smooth. From this we can conclude that the problem is most likely in the way the game processes the signal from the mouse, not the physics refresh rate or anything like that.
duzlord
Rising Rookie
16 days ago
It definitely still happens on controller... I have tested with a controller and the same effect occurs. You have to move the character by strafing left or right and you will start to see it, then move by strafing left or right while panning the camera in the other direction. If you only pan the camera with right stick or mouse but your character is not moving, then it appears smooth.

-----
EDIT:

I feel like the game is gaslighting me...
Went to test it again and capture footage and now controller is perfect...

What I can definitively say from testing two scenarios with mixed inputs:
Strafing with controller left stick while using mouse to aim = bad, stutter.
Strafing with keyboard while using controller right stick to aim = good, smooth.

So I guess for now that's going to be my final input on this issue (no pun intended). Mouse input is still fundamentally broken and I am out of ideas.
krismate
Rising Scout
16 days ago
Can you by chance record some slow-motion footage with your phone to show that? I don't own a controller so cant' do it myself. This is the first instance I've seen of someone saying controller is affected as well.
duzlord
Rising Rookie
16 days ago
edited that reply, went to record it but couldn't replicate it again... if I manage to replicate it I'll upload slowmo footage.