True Double Buffering

You can see the games framerate limiter is set to 144, and Special K's is disabled, the present interval is 1 so it's not 1/2 sync. The only thing keeping it at 60 is double buffering, because my gpu is not powerful enough to run it at 120. If I increase the settings, it drops to 40, another multiple. This is the behaviour you are looking for to verify double buffering is active.

Explicitly setting 2 buffers does not work in any other games, and I haven't set the buffers in this one either as you can see it is -1. It doesn't work in Left 4 Dead which is a game that should only have double buffering in the first place. The really interesting thing is that if you enable the in-game vsync option, it's still triple buffering, but if you force it on, it's double buffering. Forcing it on in other games just gives triple buffering. Whatever makes it work is unique to Fallen Order.

I was only trying Special K here to see if the texture cache could do something about the notorious stuttering the game has.

 

Fallen Order is Unreal Engine 4 IIRC, you may have the same luck with other games using that engine. Ironic, because Kaldaein (specialk creator) has mentioned multiple times on other forums that Unreal is a pain to work with.

Also, all Unreal Engine games have a config file somewhere, and you will usually find the fps/framelimit/buffering settings there, usually Engine.ini or GameUserSettings.ini. Might give a clue as to what settings the engine is using to achieve the desired result.

Fallen Order config locations:
%LOCALAPPDATA%\SwGame\Saved\Config\WindowsNoEditor\GameUserSettings.ini
%USERPROFILE%\Saved Games\Respawn\JediFallenOrder\GameUserSettings.sav (probably encrypted, cant just open in notepad)

 

Aright, I tried it on Maneater, another UE4 game. And it worked, once again the ingame vsync option is triple buffered, but forcing it with Special K is double buffered. I then tried it with a Unity game, Tiny Combat Arena, and once again explicitly setting the buffer count to 2 is still triple buffered.



It seems that UE4 is somehow exempt but only in combination with Special K. If you know of another program that can force vsync on it would be interesting to test it.

 

Was reading the Discord today and saw this, lucky I thought of you --

"for DXGI, yes,
but that's double buffering there
you need 3 in DXGI
2 is for triple buffering in D3D9
because naming mismatch"

In short -- For DX11 games set buffers to '2' for double buffering, for DX9 based games, set it to '1' for double buffering.
Join the Discord! There's a wealth of information there and people more knowledgeable than I.

Also, you're not using the latest version, which of course may help with compatibility. Again grab it from #Installers in the Discord, or the link I provided on the previous page.

Also also:

Yeah I missed that before. So what happens if you enable Special K's Frame Limiter and set it to 60? And with buffers set to 1, as above. And possibly also try with Waitable Swap Chain off and on.

Also note not all frame limiters are made equal -- Special's Ks, RTSS, the driver's own limiter all work slightly differently and Special K's is likely the best of them. So if you're going to get a smooth ride with frame limiting, Special K will probably be able to do it -- depending on its various features that might need toggling. The Wiki and Discord will help here.

 

tiny combat arena is a dx11 game as you can see, and setting 2 buffers does not work.

in my experience no framerate limiter is by itself enough, only with vsync is true smoothness achievable. but triple buffering can only lock to the refresh rate, and 1/2 sync is for whatever reason not smooth, which leaves double buffering.

you can see that when the framerate is limited by vsync, the frametime graph as measured by software, is wiggly and inconsistent, but the actual presentation is ultra-smooth. when the framerate limiter is active, frametimes are by its own measurement perfect, but the presentation is not smooth. so there is an error in how frametimes are measured in software which is probably why framerate limiters are not able to be smooth.

It is not needed, double buffering works in the game when vsync is forced by special k. So the framerate is limited to 60 only by pure vsync. It works despite NOT setting the buffer count to 2, which is a mystery. And it does NOT WORK in other DX11 games, despite EXPLICITLY setting their buffer counts to 2. truly maddening. Something is going on with the driver or windows.

 

That's not it, RTSS/AB graph for whatever reason just doesn't necessarily show how frames are presented in reality.
I can see that in Heroes of the Storm with DXVK graph, it shows lots of noticeable stutter that RTSS graph doesn't show. But that doesn't mean fps limiters produce garbage presentation intervals in general. I can see very stable VRR refresh rates in my monitor's refresh rate OSD with the Nvidia driver limiter and there is zero noticeable jumping when panning the camera etc. (e.g. in Strange Brigade). It depends on the game.

 

Indeed switching to "frame presentation" as frametime calculation point makes RTSS graph show the same stutter as DXVK graph. It also seems to better reflect the actual frame time variance (that is mirrored by monitor VRR refresh rate OSD) of both the Nvidia driver and RTSS fps limiter. Which makes me wonder if this would be the better default setting?
I probably got tricked when checking this in the past by not noticing that this option also needs to be changed for an individual .exe profile and not just the "global" template.

 

If the presentation is ultra smooth, and the framerate is limited purely by vsync which is driven by the video clock, which should be a trustworthy signal, then the frametimes must be perfectly even. And if the frametime measurement shows a variance which does not exist in reality, then it is an error. This is not a personal attack, I see this with all software measurement and limiting tools.

 

you know whats better than all this? g-sync/vrr

(i know not everyone can or wants to buy a more expensive monitor, but as someone who is extremely sensitive to vsync stuff, I will say it was money well spent, personally)

 

not all vsync is implemented the same
not all frame limiters are implemented the same.

ffxiv 72 fps limit has a frametime variance of 7ms, from 13.8 to 20.8.
rtss 72fps limit has a constant 13.8ms

 

The reality stands that this is the case with all software limiting tools, and is nothing unique to do with RTSS, which are never perfectly smooth the way double buffering is. When the video is perfectly smooth, all framerate measurement tools show a variance which is not there. When the tools show even frametimes, then the visuals are not smooth.

 

the variance is always there because framerates are not solid integer.

 

If there was a variance in frametime due to small differences in synchronization delays, then that would show up as animation errors due to delta time measurement, giving an unsmooth result, which is not the case. Typical game loops measure delta time from the beginning of the frame to the beginning of the next frame, which would typically begin after returning from present call, which is not identical to the common english term "presentation". So whatever variance is due to synchronization waiting is included in this measurement, and does not matter as long as the actual frametime is consistent, which vsync will ensure.

What these software tools do is insert themselves somewhere with a hook, do their own measurement, and add their own delay based on that measurement. I don't know how exactly this works, and it's probably different from tool to tool, as you point out RTSS even has different modes to configure. But I do know that I never see correct results from them, so there is an error in how they measure, which leads to errors in how long they wait, which leads to unsmooth presentation, which is again not meant in the sense of a call to the present API.

Not that games are always perfect, some implementations just are not smooth, likely due to errors in the game loop itself, or some bad implementation of framerate limiting with sleeping, such as is the case in the Unity engine. But this can usually be overcome by unlocking the framerate and forcing vsync, which leads to the topic of this thread, which is that double buffering is the only smooth way to do fractional vsync, such as 30fps on a 60hz monitor, or 40fps and 60fps on 120hz monitors, and double buffering cannot be easily enabled on later drivers and window due to some unknown override of how vsync works.