Show Posts
1
Window / Re: Use setFrameLimit and setVerticalSyncEnabled together
« on: May 25, 2018, 08:50:32 pm »
I haven't posted here yet, but I've been playing around in SFML for a couple years now and this is kind of where I'm at with the whole Fps limit/VSync issue:
Say you have a clock, and both an update function and draw function in main() propagating to all of your game classes throughout each frame. The clock updates and passes along the delta time. With VSync off, you would basically be updating & drawing thousands of times without any limiting (dependent of course on the pc/graphics card). Most monitors are 60Hz, so you wouldn't need to output more than 60fps in most cases, but this should be treated as an unknown since someone could have a monitor that is 120Hz, 240Hz, or a variable refresh rate monitor (GSync etc).
Hz and fps are 1:1, so with this in mind, you don't need to output more than something like 240fps to account for all monitor refresh rates (even then might be overkill). variable refresh rate monitors are kind of a non-issue above a certain point because your eyes wouldn't be able to differentiate the difference anyway unless you're pushing out a lot of 3d graphics/shaders that could make the framerate vary drastically between frames.
This basically means that setFrameLimit should only be set once during initialization of your game. It's the maximum allowed framerate that should output so that you're not updating frames unnecessarily. Take Quake III as an example: That had a max of 90fps unless the limit was changed by hand via ini/console/hack or whatever it was.
Now if the delta time is factored into everything being drawn, and VSync is toggled, something magical happens: it serves only as the difference between a screen that tears (when the outputting framerate is larger than the monitor's allowed framerate) and doesn't tear (since both would be synced). This is basically what you want. Doing delta time properly is a topic itself, so there's a lot of additional nuance, but you basically factor the "target" framerate (60) into the frame time, set that to a double or float, and pass that to your update functions.
I can provide code examples if need be, but this method basically avoids setFrameLimit and setVerticalSyncEnabled from conflicting with one another (at least in theory). You can essentially do something like bind a VSync toggle to a keyboard key and output the framerate into the titlebar for debugging. What I do from there is set no fps limit during development (with the intention of setting it for releases) so that I can see at a glance if/how my code impacts performance.
Say you have a clock, and both an update function and draw function in main() propagating to all of your game classes throughout each frame. The clock updates and passes along the delta time. With VSync off, you would basically be updating & drawing thousands of times without any limiting (dependent of course on the pc/graphics card). Most monitors are 60Hz, so you wouldn't need to output more than 60fps in most cases, but this should be treated as an unknown since someone could have a monitor that is 120Hz, 240Hz, or a variable refresh rate monitor (GSync etc).
Hz and fps are 1:1, so with this in mind, you don't need to output more than something like 240fps to account for all monitor refresh rates (even then might be overkill). variable refresh rate monitors are kind of a non-issue above a certain point because your eyes wouldn't be able to differentiate the difference anyway unless you're pushing out a lot of 3d graphics/shaders that could make the framerate vary drastically between frames.
This basically means that setFrameLimit should only be set once during initialization of your game. It's the maximum allowed framerate that should output so that you're not updating frames unnecessarily. Take Quake III as an example: That had a max of 90fps unless the limit was changed by hand via ini/console/hack or whatever it was.
Now if the delta time is factored into everything being drawn, and VSync is toggled, something magical happens: it serves only as the difference between a screen that tears (when the outputting framerate is larger than the monitor's allowed framerate) and doesn't tear (since both would be synced). This is basically what you want. Doing delta time properly is a topic itself, so there's a lot of additional nuance, but you basically factor the "target" framerate (60) into the frame time, set that to a double or float, and pass that to your update functions.
I can provide code examples if need be, but this method basically avoids setFrameLimit and setVerticalSyncEnabled from conflicting with one another (at least in theory). You can essentially do something like bind a VSync toggle to a keyboard key and output the framerate into the titlebar for debugging. What I do from there is set no fps limit during development (with the intention of setting it for releases) so that I can see at a glance if/how my code impacts performance.