frame rates and refresh rates

on the PC, if your FPS is higher than the monitor's refresh rate, you only get the refresh rate as the number of images presented to the player per second - right?

so if i'm at 172 fps (pulling a number out of thin air), and the monitor is at 60Hz, the player sees 60 images per sec - right?

so there's really no need to go faster than refresh rate? you're writing data to vidram that never gets sent to the monitor? overwritten before it ever gets read?

and refresh rates are typically some multiple of 30 Hz ?

I'm running caveman 3.0 on the new i7-6700K at 4Ghz and a GTX1080. with framerate limiter off, i show 62 fps. due to vsync no doubt.

i'm trying to figure out how to take advantage of these new speeds.

a standard game loop framerate limited to 60Hz or so would be nice. less work that fix your timestep, and no temporal aliasing.

game is currently coded for 15Hz update, so i'd have to mod all update code to run at a different speed. such as 30Hz or 60Hz. (or 120Hz ?)

game is currently coded for 15Hz update, so i'd have to mod all update code to run at a different speed.

Keep in mind that things are a bit different between windowed and non-windowed modes on all recent versions of Windows (Vista+). In windowed mode your app doesn't directly present to the screen: it presents to the compositor (DWM), and the compositors combines your window's contents with other windows and draws the whole thing to the screen. So if you run unlocked with no VSYNC in Windowed mode you won't see tearing, but you may see some juddering due to uneven frame times. In exclusive fullscreen mode your app "owns" the display, in which case the front buffer gets scanned out right to the screen. In this scenario you will get tearing if you don't enable VSYNC, and you can also see juddering due to uneven frame times.

One possible advantage of running faster than the refresh rate is that there may be less latency between input->display, at least if you're polling input and updating game state at the same rate that you're rendering. But that latency will be variable since you're effectively decoupled from the display rate of the monitor.

If you have vsync off as well and only seeing 62fps then the limit isn't vsync.

i'm pretty sure vsync is on.

sounds like you still need vsync on, to avoid tearing - correct?

and you can't really count on any specific refresh rate.

so the choices are decouple (a la fix your timestep), or limit rate to "fast enough" - whatever your definition of that is (30fps, 60fps, etc). no other options, right? - i can't think of any...

.

what about detecting the refresh rate, then using a variable framerate limiter to match the refresh rate, or half the refresh rate in the case of high refresh rates that the game just can't do?

that would let render run as fast a refresh (assuming it could do that), without the need for fix your timestep. you get a simpler loop, and no temporal anti-aliasing.

fixed timestep, with vsync on, a game would run at vsync. with vsync off it would run at max render speed with possible tearing. don't want tearing, so i guess keep vsync on.

keeping vsync on, it seems a basic game loop framerate limited to refresh rate yields the same results as fixed timestep, with less work. you have a multiplier for update based on refresh rate - sort of like ET in fixed timestep. but that's it. no current and previous states, no lerping location, orientation, and tween. and what you render is always the current state - no temporal aliasing. and you process input every render, and render after every update, so the player experiences minimum lag.

guess the big question is can DX determine the refresh rate with certainty?

It sounds like you're describing, in very long terms, what is actually the simplest game loop possible:

yeah - basically.

i've always used loops of the form:

while (! quitgame)

{

start timer

render

input

update

wait until desired ET has elapsed, such as ~66ms for 15Hz, or ~33ms for 30Hz, etc.

}

there was never any thought about "render as fast as possible", just "keep it from running too fast".

and frankly, i'm still not worried about rendering as fast as possible. i'd much prefer a lockstep loop that's "fast enough". especially given that it seems that the extra speed of fixed timestep gets limited by vsync and tearing issues.

in the end, neither implementation is that difficult to add. an extra location and orientation and 3 lerps (location, orientation, animation frame) per entity. a variable framerate limiter would need an ET value, just like fixed timestep. something like hard coded to 60Hz would be simplest.

i think my first step, while i wait for further opinions, will be to make the framerate limiter variable, and add a multiplier to update, so i can test it at 15, 30, 60 HZ etc. i may just code it to run at 60 or 30 hz and get on with life.

the ironic thing about the new 6700K GTX1080 runing both Skyrim SE and Caveman 3.0 is the number one thing i notice is i need better plant models! <g>. i don't really notice that one is vsync limited fixed timestep at 60Hz refresh, and the other is locked at 15Hz. but i don't plan on keeping caveman locked at 15Hz. 30 or 60 maybe. or fixed timestep, or variable framerate. actually 30 sounds easiest. should be fast enough, and gives you 33ms to do everything, better than just having 16ms to do everything.