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

Epeson
Rising Scout
22 days ago
Hey, thanks for your effort. I’ll give it a try and let you know how my experience was.
duzlord
Rising Rookie
22 days ago
After further testing by applying renderaheadlimit 0, I am observing that it also completely resolves the lighting / texture flickering experienced when anti-aliasing is disabled.
komandor_szyszka
Seasoned Rookie
22 days ago
could u try measuring this with presentmon, a not rtss? would be good to have 100% confirmation it's game and not anticheat, rtss might have issues getting through that, presentmon wont

also, can u try checking how the RenderDevice.RenderAheadLimit behaves after yeeting reflex and pcl files? it also could be messed up reflex (and dlss in general) implementation that makes it so limit = 0 never applies if you have reflex loaded

but the game does it's **bleep** best to not respect console commands, frequently resetting them to what it thinks they should be (and i mean sometimes on respawn, sometimes on entering drone, going to options screen etc)
duzlord
Rising Rookie
21 days ago
I believe presentmon is blocked by the anticheat as when I use presentmon graphs within RTSS they just hang on "waiting for presentmon data stream", and other programs like capframeX have not been able to detect or capture data from bf6. Which really sucks as someone who likes to gather data and optimise games, I would like to be able to capture complete data. And yea alot of the console commands do reset, but for these tests I was checking the output of the command by simply running RenderDevice.RenderAheadLimit with no arguments, which returns the current value, which was unchanged for those tests.
I play around for a bit and see if I can get anything working. I might try get some definitive non averaged fps values through RTSS atleast to see if there are micro dips occurring.
komandor_szyszka
Seasoned Rookie
20 days ago
crank up the po
polling period then in whatever's used for RTSS overlay source to get as close to issue as possible
Gl_b
19 days ago
I was able to capture data from BF6 using CapFrameX, which is based on PresentMon, I believe. But I always got very smooth and stable frametimes, so I thought the data wasn't helpful for troubleshooting this particular issue.
Pointi1978
Seasoned Ace
19 days ago
Tried this in the Shooting range. Setting this to 0 immideately made my game feel stuttery and not smooth despite game still reporting a flat 125 FPS. Set it back to 1 again and game is smooth again.
FYI: 4k 144hz OLED Screen with Gsync, HDR enabled. RTX 4090, i7-13700k. Any other FPS lock than 125 makes game feel stuttery.
real3hunna
New Traveler
18 days ago
Does this mean it fixes the stupid jidder issue? Mouse smooth again? 240hz feel like 240hz?
Epeson
Rising Scout
18 days ago
Unfortunately, that didn’t help in my case. The developers really need to take care of this.
duzlord
Rising Rookie
16 days ago
just going to leave this here and probably uninstall the game...

https://www.reddit.com/r/godot/comments/1863slf/getting_weird_object_jitters_with_character/

excerpt:
I think I know what this is. Your player movement is probably in _physics_process(), which means if you game is running at a higher frame-rate than that, you get stuttering in the camera (because the camera is locked to 60hz while the game tries to update faster):
Source: I had this problem FOREVER in a game I was working on. I eventually had a hunch, so I moved all the movement and camera logic to _process, and it all suddenly went away.