Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Use setFrameLimit and setVerticalSyncEnabled together  (Read 2644 times)

0 Members and 1 Guest are viewing this topic.

decoder

  • Newbie
  • *
  • Posts: 8
    • View Profile
Use setFrameLimit and setVerticalSyncEnabled together
« on: May 22, 2018, 06:01:06 am »
Can I use setFrameLimit and setVerticalSyncEnabled together after I'd created a window because I will be adding a vertical sync setting into my game, and I'm not pretty sure if setVerticalSyncEnabled will override the FPS that I've passed into the setFrameLimit.

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 10815
    • View Profile
    • development blog
    • Email
Re: Use setFrameLimit and setVerticalSyncEnabled together
« Reply #1 on: May 22, 2018, 07:30:04 am »
I think the tutorial state that you can't use them together and you can't. Doing so will cause issues as two different methods will try and limit the framerate.
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

decoder

  • Newbie
  • *
  • Posts: 8
    • View Profile
Re: Use setFrameLimit and setVerticalSyncEnabled together
« Reply #2 on: May 25, 2018, 11:14:04 am »
I want to add a setting to my game whether of not to turn on vertical sync, and I don't know if the frame limit set by the setFramLimit would be overriden if the vertical sync has turned on.

PepsiOtaku

  • Newbie
  • *
  • Posts: 1
    • View Profile
Re: Use setFrameLimit and setVerticalSyncEnabled together
« Reply #3 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.