Separate System for VSync

[orchid kraken]

Are there ways to have a specific system be VSynced? Setting QualitySettings.VSync forces the entire simulation system group to be vsynced together with all system groups beneath it, but given how flexible the system groups are it could be nice to have stuff that affects rendering separate from systems that read input or variable rate stuff.

[bronze lance]

Why not just use the FixedStepSimulationSystemGroup? It's like FixedUpdate for DOTS, not sure why you would want some sort of VSync instead of this, but perhaps I don't understand the question.
https://docs.unity3d.com/Packages/com.unity.entities@1.2/api/Unity.Entities.FixedStepSimulationSystemGroup.html

[orchid kraken]

FixedUpdate runs at a fixed framerate. VSync syncs to your screens refresh rate.
Input can in theory be updated outside both.

[bronze lance]

Well then something janky as: https://docs.unity3d.com/Packages/com.unity.entities@1.2/api/Unity.Entities.VariableRateSimulationSystemGroup.html 🤔
And set the variable rate to either your FPS if its lower then VSYNC or to VSYNC, if that's possible, haven't tried.
Still, your bunching up calculations this way, making your game spikey, so it's weird either way.

[orchid kraken]

Basically, if vsync is on, the entire SimulationSystemGroup will be synced to that, meaning that you can't have anything polling input at a higher framerate.

Not using vsync but setting variable rate simulation would also not work since the way it matches the screen's refresh rate is different than just counting fps. Or at least that's my understanding of it

Essentially, one might want:

• FixedUpdate: Game Logic calculations that work best when calculated at a fixed rate
• RenderUpdate: Any calculations only tied to rendering that shouldn't be done more often than the screen can refresh
• InputUpdate: If somebody moves the mouse and clicks three times while moving it within 1 frame, then each position clicked at matters, even if the rendering doesn't update between every clicked position

[bronze lance]

I still don't know what you want.
If you enable QualitySettings.VSync, and have VSYNC set on 60 FPS, your game and every system runs on 60 FPS or less, if your game is too slow to get to 60 FPS.
If you have 30 FPS, your FixedUpdate will run twice each frame, but your RenderUpdate and InputUpdate only run once each frame.
But it seems like you don't want to VSYNC, but read the monitor's refresh rate, and only do RenderUpdate on that refresh rate? Is that correct?
If so, why is VariableRateSimulationSystemGroup not the solution if you set that to 60, or w/e your monitors refresh rate is?

[deft barn]

why would you have simulation running outside of refresh rate of monitor?

[orchid kraken]

Input feel. Basically same reason some users prefer having vsync off

[deft barn]

so let them have vsync off then

and get their beloved 250fps

people with 250fps are probably having freesync monitors anyway

so vsync must be turned off

[orchid kraken]

but then all calculations I do for rendering specifically will needlessly be done multiple times per shown frame

[orchid kraken]

tbf, true

[deft barn]

you could just constraint PresentationSystemGroup then

just add your rate manager

which detects when a frame should be ready

and see how it works for you

[orchid kraken]

O, let me try that actually, I haven't seen if that works

[orchid kraken]

Hmm, yeah, it doesn't work, all internal rendering stuff still happens separate from that on every unity frame

So for gpu instancing for example you'd see flickering

[deft barn]

Rendering is probably part of c++ side

so what you might want is to just run simulation at 250 fps

while leaving actualy fps to whatever value vsync works at

probably going to be confusing compared to other apps

but with those new frame generations, it's getting common I guess

[orchid kraken]

Tbh, for the current project it's probably not going to be worth it, but for something like a rhythm game it might be a lot more vital

[deft barn]

there isn't much to it actually

[orchid kraken]

Though I just found OnDemandRendering, so that might be exactly what I'm looking for

[deft barn]

implementation of what you want is very modular

and most likely will end up in less then 300 lines solution

[earnest stream]

for such a situation one could capture inputs on a separate thread perhaps