How can I fix the maximum FPS to 72?

[warmachine79]

Hey guys, in order to play with my Pimax Crystal Light on 72hz stutter-free, I want to lock/limit the DCS FPS to 72. However, the game menu only allows 5 fps increments. Any ideas? 

[YoYo]

14 minutes ago, warmachine79 said:

Hey guys, in order to play with my Pimax Crystal Light on 72hz stutter-free, I want to lock/limit the DCS FPS to 72. However, the game menu only allows 5 fps increments. Any ideas? 

But why do you want to lock DCS to 72 FPS if it's a 72 MHz refresh rate for googles?

If you have a GPU that can generate more FPS in VR mode, you will always have 72 FPS, not more as a fixed value. No need to lock it.

I have set 72 MHz in VR which is achievable with my GPU and I have a constant 72 frames, also over Berlin. In DCS I have the FPS slider all the way to the right in the settings.

[Dangerzone]

1 hour ago, warmachine79 said:

Hey guys, in order to play with my Pimax Crystal Light on 72hz stutter-free, I want to lock/limit the DCS FPS to 72. However, the game menu only allows 5 fps increments. Any ideas? 

I've found RivaTuner to be my best option.

I've also found it helps change the yellow and red 'cpu bound' to the green 'gpu bound' status in the DCS FPS inspection. (With the exception of the stutters that I still haven't been able to overcome). 

However different people for some reason report different results with limiting the frames. For some like me, it greatly improves the experience. For others, it creates more complications, so give that a shot and see whether it makes it better or not for you.

I've been trying to figure out what the difference is between those who limiting works for, and those it doesn't, but haven't found something yet. For me - I'm 13900 on 4090 with 64GB RAM.

Other options for you are to use DCS to limit to 75FPS (and let your headset do the rest), or lock it in with NVIDIA Cpanel. But as mentioned, I've found RivaTuner works the best for me, but may not hurt to try all options as YMMV.

Edited June 5 by Dangerzone

[actually_fred]

RTSS affects your mirror window - it does not directly affect your headset. There’s a fair chance it’s placebo, but if not and the mirror window ends up somehow linked to the VR display, it likely varies depending on your vsync settings, your monitor refresh rate, and if your monitor supports Variable Refresh Rate

when RTSS and similar non-VR tools have any non-placebo effect on VR, it’s by tying the game to your monitor timing rather than the headset timing, leading to at a minimum microstutters, but can also lead to motion prediction issues, and larger stuttering and tracking issues.

Edited June 6 by actually_fred

[Dangerzone]

25 minutes ago, actually_fred said:

RTSS affects your mirror window - it does not directly affect your headset. There’s a fair chance it’s placebo, but if not and the mirror window ends up somehow linked to the VR display, it likely varies depending on your vsync settings, your monitor refresh rate, and if your monitor supports Variable Refresh Rate

when RTSS and similar non-VR tools have any non-placebo effect on VR, it’s by tying the game to your monitor timing rather than the headset timing, leading to at a minimum microstutters, but can also lead to motion prediction issues, and larger stuttering and tracking issues.

I'm curious about this. In my case it's definitely not a placebo. I can literally be in my headset - see what DCS is doing - while DCS is still running set the FPS limit in RivaTuner, come back and see a significant difference in what I experience in DCS plus what the DCS FPS Window is telling me.

If this is not supposed to have any impact - I'm very keen to find out why it does - as anything I can do to remedy the issues DCS is having another way - I'm all up for learning more.

However if I change RTSS to 60FPS - it definitely locks my DCS Frames to 60FPS in VR. 

My best guess is that there's some sort of over-rendering happening with DCS behind the scenes, and limiting it to 72FPS helps DCS to not 'race ahead' - but all I know is what I've done from experimentation - I'm no expert at this. 

Are you saying we should be enabling VSYNC for the VR mirror / monitors sake instead? I don't believe I have any VSYNC enabled. The only limitor there at present is Rivatuner?

I'd be happy not to have a mirror at all on my desktop - if it meant better experience in VR, but I don't think that's possible?

[The_Nephilim]

5 hours ago, warmachine79 said:

Hey guys, in order to play with my Pimax Crystal Light on 72hz stutter-free, I want to lock/limit the DCS FPS to 72. However, the game menu only allows 5 fps increments. Any ideas? 

well if you could lock it at 72 you would still run into issues. I have read that it is best to lock it about 10-20FPS above your lowest FPS and if need be you can round it off. I found it best just to set the Hz rate of the VR and let the Game just run full out.. but if you are able to maintain a set FPS like 85 or 90 fps consistently you could lock it above your Hz rate and probally be fine..

 

What are your specs and Headset and such?

[Qcumber]

If you lock at 72fps you are likely to get microstutter. I have tried various forms of locking fps over the years and none make any difference in terms of performance. 

[Dunska]

For me, by far the best results are from locking at 72 fps in NVCP and leaving DCS at the default (180 fps).  I tried leaving it unlimited and also forcing it to 72 fps in DCS (by manually modifying the options.lua to set "maxFPS=72") but still had micro-stutters.  Limiting to 72 fps in NVCP and setting that in the headset (Pico 4 with Virtual Desktop in my case) gave me the best results.

[actually_fred]

10 hours ago, Dangerzone said:

I'm very keen to find out why it does

 

10 hours ago, actually_fred said:

when RTSS and similar non-VR tools have any non-placebo effect on VR, it’s by tying the game to your monitor timing rather than the headset timing, leading to at a minimum microstutters, but can also lead to motion prediction issues, and larger stuttering and tracking issues.

RTSS and similar tools literally modify the 'send this to my *monitor*' thing, which is not used for VR. The game will usually render to the mirror window in a way that just tells windows "here's a frame, display it whenever you're ready, or don't" - the game doesn't wait for it to display. A forced limit or forced vsync forces the game render to wait for the next permitted frame time *when sending to the monitor*. When not placebo, this limits the entire game, so it ties your VR headset to your monitor's behavior, which is bad.

It's placebo when the game more thoroughly decouples VR from the monitor behavior.

Edited June 6 by actually_fred

[actually_fred]

Anyway, the actual way to limit the game to 72hz in VR:

- set headset to 72hz

- turn off 'turbo mode', 'prefer framerate over latency', and any similar options in the headset software and any third-party mods. Note that if you're using mbucchia's quad views layer (you probably don't need it on the pimax), it turns on turbo mode by default

If that's not sufficient, test disabling all mods with https://github.com/fredemmott/OpenXR-API-Layers-GUI. If you have > 72hz with all mods disabled and it set to 72hz in the pimax software, contact pimax support.

The *only* way to get correct frame pacing is for it to be dictated by the headset/runtime, not the game or any third-party software, as it should match the display panel timing.

Edited June 6 by actually_fred

[Dangerzone]

12 hours ago, actually_fred said:

 

RTSS and similar tools literally modify the 'send this to my *monitor*' thing, which is not used for VR. The game will usually render to the mirror window in a way that just tells windows "here's a frame, display it whenever you're ready, or don't" - the game doesn't wait for it to display. A forced limit or forced vsync forces the game render to wait for the next permitted frame time *when sending to the monitor*. When not placebo, this limits the entire game, so it ties your VR headset to your monitor's behavior, which is bad.

It's placebo when the game more thoroughly decouples VR from the monitor behavior.

That's definitely not true in my case. If you are right - then there's a connection between you and I that is missing. 

To clarify though - and maybe this is where the miscommunication is: The problem isn't that I'm getting over 72FPS without limiting it - the VR does indeed limit the frames still to 72 as you say - so I agree there. (So if you think we're saying RTSS is needed to limit the FPS to 72 in the headset - that's not what I'm saying). What I'm saying is if I use RTSS and set 72FPS - I get a far more stable 72 fps with far less drops than compared to if I wasn't using RTSS. 

Now as for the part that RTSS only affects the monitor - if I change RTSS to 60fps - according to what I understand from what you've written - this should only change the mirror window to 60fps?  That's not the case - what I observe is immediately after changing this setting, my VR drops to 60fps. As such - I can only conclude that RTSS does indeed force a limit on DCS's FPS in VR.  This isn't placebo - I'm viewing the DCS's actual FPS  counter in VR - and I also see the effects visually well. I can lower this significantly more to 30fps or less - and the effects are even more obvious.  

Obviously I have no intentions to lower FPS that far - but for the sake of this exercise to test if your theory is correct that VR isn't affected - and I can conclude it definitely is affected by RTSS. The headset can't go above it's refresh rate - but RTSS is definitely affecting the frames that the HMD is delivering. Not only visually - but I can see this also reported in DCS's FPS dialog as well. 

The main reason to limit FPS to 72 using RTSS in VR isn't to lower the FPS to 72 because it's rendering more than 72fps- but rather because doing so gives a clear change to the amount of stuttering and CPU binding that is going on. I don't know the reason for this. Maybe the 72FPS isn't being fully limited correctly with Pimax software, or DCS has some HID interrupts coming in the wrong place that causes issues that manually setting RTSS to 72FPS helps as a workaround. I suspect DCS since this was working smooth on the previous version of DCS but the latest updates cause issues. (And rolling back to previous version works fine again).  The reasons I can only guess - but the effects are plainly obvious. For me - without RTSS I'm removing my headset after 10 minutes with a headache due to the very obvious and significant stuttering. With RTSS at 72 - the major stutters have gone (the odd micro stutter remains),but I can play for hours. 

I also just tested again too - running with no limit gives me 72fps in VR with significant stutters. (72FPS dropping to around 60FPS as reported by DCS as well as is plain to see - no placebo). I see CPU Binding flash between yellow and green in the DCS FPS window as well.  Then, setting RTSS to limit to 72FPS, the DCS FPS window shows a green 'GPU Bound' the majority of the time, with the occasional stutter - and I see a more consistent 72FPS in the DCS FPS window - I definitely see far fewer stutters.

Cheers

DZ

Edited June 7 by Dangerzone

[Qcumber]

4 hours ago, Dangerzone said:

That's definitely not true in my case. If you are right - then there's a connection between you and I that is missing. 

To clarify though - and maybe this is where the miscommunication is: The problem isn't that I'm getting over 72FPS without limiting it - the VR does indeed limit the frames still to 72 as you say - so I agree there. (So if you think we're saying RTSS is needed to limit the FPS to 72 in the headset - that's not what I'm saying). What I'm saying is if I use RTSS and set 72FPS - I get a far more stable 72 fps with far less drops than compared to if I wasn't using RTSS. 

Now as for the part that RTSS only affects the monitor - if I change RTSS to 60fps - according to what I understand from what you've written - this should only change the mirror window to 60fps?  That's not the case - what I observe is immediately after changing this setting, my VR drops to 60fps. As such - I can only conclude that RTSS does indeed force a limit on DCS's FPS in VR.  This isn't placebo - I'm viewing the DCS's actual FPS  counter in VR - and I also see the effects visually well. I can lower this significantly more to 30fps or less - and the effects are even more obvious.  

Obviously I have no intentions to lower FPS that far - but for the sake of this exercise to test if your theory is correct that VR isn't affected - and I can conclude it definitely is affected by RTSS. The headset can't go above it's refresh rate - but RTSS is definitely affecting the frames that the HMD is delivering. Not only visually - but I can see this also reported in DCS's FPS dialog as well. 

The main reason to limit FPS to 72 using RTSS in VR isn't to lower the FPS to 72 because it's rendering more than 72fps- but rather because doing so gives a clear change to the amount of stuttering and CPU binding that is going on. I don't know the reason for this. Maybe the 72FPS isn't being fully limited correctly with Pimax software, or DCS has some HID interrupts coming in the wrong place that causes issues that manually setting RTSS to 72FPS helps as a workaround. I suspect DCS since this was working smooth on the previous version of DCS but the latest updates cause issues. (And rolling back to previous version works fine again).  The reasons I can only guess - but the effects are plainly obvious. For me - without RTSS I'm removing my headset after 10 minutes with a headache due to the very obvious and significant stuttering. With RTSS at 72 - the major stutters have gone (the odd micro stutter remains),but I can play for hours. 

I also just tested again too - running with no limit gives me 72fps in VR with significant stutters. (72FPS dropping to around 60FPS as reported by DCS as well as is plain to see - no placebo). I see CPU Binding flash between yellow and green in the DCS FPS window as well.  Then, setting RTSS to limit to 72FPS, the DCS FPS window shows a green 'GPU Bound' the majority of the time, with the occasional stutter - and I see a more consistent 72FPS in the DCS FPS window - I definitely see far fewer stutters.

Cheers

DZ

It would be worth measuring this. If locking fps to 72 appears smoother then you would expect to see a tighter distribution of frametimes. I have been working on this using XRFrameTools and hope to publish my updated spreadsheet soon. 

 

 

[actually_fred]

10 hours ago, Dangerzone said:

Now as for the part that RTSS only affects the monitor - if I change RTSS to 60fps - according to what I understand from what you've written - this should only change the mirror window to 60fps?  That's not the case - what I observe is immediately after changing this setting, my VR drops to 60fps. As such - I can only conclude that RTSS does indeed force a limit on DCS's FPS in VR.  This isn't placebo - I'm viewing the DCS's actual FPS  counter in VR - and I also see the effects visually well. I can lower this significantly more to 30fps or less - and the effects are even more obvious.  

You seem to have skipped or misread this section twice - note 'non-placebo effect':

On 6/5/2025 at 8:29 PM, actually_fred said:

when RTSS and similar non-VR tools have any non-placebo effect on VR, it’s by tying the game to your monitor timing rather than the headset timing, leading to at a minimum microstutters, but can also lead to motion prediction issues, and larger stuttering and tracking issues.

RTSS is not capable of modifying framerate in a way that respects VR panel timing; all it can do is delay the game loop based on non-VR data.

If you are getting a smoother result with RTSS, it is because is most likely it's delaying it enough to entirely miss a panel refresh, effectively adding a 1 frame delay with out-of-date headtracking. If this is the case, the root cause would either be DCS having unpredictable CPU load or over-optimistic wait time prediction in the pimax software.

For this kinds of issues, Turbo mode has its' own problems, but is a often a better workaround, at the cost of increased GPU load (but not higher per-frame load) - the 'real' fix is to report the problems you're having to pimax and ask them to improve their runtime - in particular the implementation of xrWaitFrame.

Edited June 7 by actually_fred

[Dangerzone]

On 6/7/2025 at 8:49 PM, actually_fred said:

You seem to have skipped or misread this section twice - note 'non-placebo effect':

RTSS is not capable of modifying framerate in a way that respects VR panel timing; all it can do is delay the game loop based on non-VR data.

If you are getting a smoother result with RTSS, it is because is most likely it's delaying it enough to entirely miss a panel refresh, effectively adding a 1 frame delay with out-of-date headtracking. If this is the case, the root cause would either be DCS having unpredictable CPU load or over-optimistic wait time prediction in the pimax software.

For this kinds of issues, Turbo mode has its' own problems, but is a often a better workaround, at the cost of increased GPU load (but not higher per-frame load) - the 'real' fix is to report the problems you're having to pimax and ask them to improve their runtime - in particular the implementation of xrWaitFrame.

My apologies. You are right. I misread that twice. Thanks so much for your patience and pointing it out, and again my sincere apologies. 

Thanks for the info on turbo mode too. I wasn’t aware that could help with this issue so will investigate that too. 
 

Cheers!

DZ

[actually_fred]

5 hours ago, Dangerzone said:

Thanks for the info on turbo mode too. I wasn’t aware that could help with this issue so will investigate that too. 

Two contrasting approaches: RTSS is 'delay stuff', Turbo Mode is 'remove delays'. Both can increase latency, but 'remove delays' is usually the better of the two

Reason that 'remove delays' can be bad for latency is say you want 1 frame per second, and it takes 100ms to render a frame. Say your next frame is due at exactly 10:00:00

The theoretical ideal time to start that frame is 09:59:59.900 - in practice, most runtimes will aim to start a little earlier, say .895. If the game says 'ready to start the next frame' at .801, the runtime may introduce a .094 delay.

Turbo mode gets rid of that delay, so your frame will be ready at .901, but it will still be displayed at the next panel refresh at 10:00:00.000 - so it will be 99ms out of date. Another frame will be ready at 10:00:00.101, but that will be discarded, with the goal of making another for 10:00:01

With RTSS or non-VR tools, when they have any effect on VR, you'll still have whatever delay the runtime wants (which will change), but also whatever delay RTSS inserts, and RTSS has no idea about when the next panel refresh rate is. Usually this is either 'no effect' or 'adds an extra 1 frame of delay'.

[Dangerzone]

8 hours ago, actually_fred said:

Two contrasting approaches: RTSS is 'delay stuff', Turbo Mode is 'remove delays'. Both can increase latency, but 'remove delays' is usually the better of the two

Reason that 'remove delays' can be bad for latency is say you want 1 frame per second, and it takes 100ms to render a frame. Say your next frame is due at exactly 10:00:00

The theoretical ideal time to start that frame is 09:59:59.900 - in practice, most runtimes will aim to start a little earlier, say .895. If the game says 'ready to start the next frame' at .801, the runtime may introduce a .094 delay.

Turbo mode gets rid of that delay, so your frame will be ready at .901, but it will still be displayed at the next panel refresh at 10:00:00.000 - so it will be 99ms out of date. Another frame will be ready at 10:00:00.101, but that will be discarded, with the goal of making another for 10:00:01

With RTSS or non-VR tools, when they have any effect on VR, you'll still have whatever delay the runtime wants (which will change), but also whatever delay RTSS inserts, and RTSS has no idea about when the next panel refresh rate is. Usually this is either 'no effect' or 'adds an extra 1 frame of delay'.

Thanks so much for that information. I'll definitely give this a shot. Also - just to confirm, when you say Turbo mode - I'm assuming that you mean Turbo Mode in OpenXRToolkit? Or is there another turbo mode setting/configuration that can be done that I'm not aware of? 

Thanks

DZ

[sleighzy]

7 hours ago, Dangerzone said:

Thanks so much for that information. I'll definitely give this a shot. Also - just to confirm, when you say Turbo mode - I'm assuming that you mean Turbo Mode in OpenXRToolkit? Or is there another turbo mode setting/configuration that can be done that I'm not aware of? 

Thanks

DZ

Turbo mode also exists (on by default) in Quad-Views-Foveated (QVFR) as well.

[Dangerzone]

@actually_fred - there's a new one for me. I've tested your recommendation with Turbo to on and I don't need to use the FPS limiter anymore to get a good experience. And you were right - if anything this has not only matched the FPS limiter in terms of a workaround but it's an improvement on what i was having - even less of the microstutters. Thank you!

2 hours ago, sleighzy said:

Turbo mode also exists (on by default) in Quad-Views-Foveated (QVFR) as well.

I may revisit QVFR at some stage. I turned it off due to "CPU Bound" issues I was experiencing to start with. Seems I have plenty of GPU overhead, but am severely limited by CPU. If that turbo mode does the same thing, then if I go back to using QVFR I may end up using it again. Thanks fort he suggestion!