Is vid_vsync wrong?

[Baker]

DarkPlaces, all the qw clients and DirectQ have independent timing between client and server.

Short version: 72 fps is Quake standard. 60 Hz is common display rate. You can't get 72 fps with 60 fps. Any deviation from 72 fps messes with Quake physics like jump height and such. Vid_vsync (swap control) actually makes CPU wait, truly lowering fps and messing physics (subtly, but it can matter -- in rare cases, break map design stuff).

http://www.opengl.org/wiki/Swap_Interval

I haven't tried to implement this, but I've studied the DarkPlaces implementation (Quakeworld has this by necessity, since the ability to function as client and server wasn't actually a feature of Quakeworld but added on by the community), studied the code and read about everything MH has ever had to say about this.

Is video sync "bad"?

Quake only operates correctly at 72 frames per second. And 60 Hz monitors are common.

If you use swap control, it doesn't just slow down rendering ... according to the above link ... it actually makes the CPU wait. You literally are getting 60 frames per second. Which is less than 72 frames per second. So let's say a certain single player map has a jump that is manageable at 72 fps ... it might be harder or in some very rare cases impossible at 60 fps.

More likely, it is the vertical jump you can't quite pull off. Maybe some barely manageable place you can jump up simply cannot be done at 60 fps in single player (where client + server are one). If you want an example of one map that has this as potential issue, see Trinca's Forgotten Tomb. Any slightly lower physics frame rate and you cannot get out of the start area which requires you to jump up to take a "wind tunnel" to the main map.



http://www.quaddicted.com/reviews/trincasp2.html

This means that 72 frames per second physics might be nearly impossible to pull off with vid_vsync? Maybe this is why I can't recall seeing vid_vsync anywhere in the DarkPlaces menu?

[andrewj]

This is more an issue of the physics being frame-rate dependent (a gross bug that continued to exist even in Quake 3), right?

Personally I would fix the physics to make it frame-rate independent, with a bias toward slightly higher jumps rather than slightly lower jumps. I have noticed that in DarkPlaces I can jump up a bit higher than in other engines, maybe that's why.

As for vsync, I don't think it's bad -- it is necessary to prevent the shearing effect. It doesn't matter too much IMO that the CPU has to wait, as there is not really anything else it can do (except maybe some sound mixing) .

[metlslime]

framerate independence is a good feature, i support it.

However, it's wrong to say that only 72 fps is "correct" quake gameplay -- almost nobody was getting this framerate in 1996 (i got about 30-40 fps on my pentium 166), and yet the game wasn't broken then.

It may be accurate to say 72 fps is "optimal" quake gameplay, though it only really matters for MP. Single player maps should be more tolerant (both of the players and of their hardware/software); with the exception of maps specifically designed for speedrunners/trickjumpers.

[Spike]

any map/mod that is broken with vsync enabled is simply a broken map, sorry.
If you're running on a laptop, you will want vsync, because allowing the cpu to idle between frames will give longer battery life (and quite possibly less cooling issues too).

Really though the optimal framerate is some round multiple of the (nq) server's tick rate, as well as some round multiple of the video refresh rate (0.5 can also be considered round). It'll only be perfectly smooth when both of those are achieved - but if you can only achieve one, multiples of the video refresh rate is how it must be. server tick rates can be interpolated a lot more gracefully.

With NQ engines, the client's framerate really doesn't matter, so long as the server is ticking over at a suitable interval, because *everything* is interpolated anyway. If you run two server frames while the client runs a single frame, the client should be able to interpolate it smoothly. If it can't then its an interpolation bug. The higher the better, really. 120, 180, 240. All are good framerates with a 60hz monitor. The *client* framerate won't affect anything.
With QW engines, the client traditionally lacks any interpolation. The servers tick over at most 72 times per second, and you get booted if the interval between input packets is faster than 72 per second. The lack of interpolation almost mandates a multiple of 72hz for smooth video updates, while the server and physics greatly favour 72fps client->server input updates. Which puts you at a disadvantage if you run at a different refresh rate (say 60hz) as you _will_ get jerky movement of ents+other players, and smaller jumps.

Darkplaces implements a fixed refresh rate to resolve minor variations within physics systems (eg: ODE objects jitter like crazy and sometimes spontaneously jump across the room with variable framerates). Presumably it uses 72hz physics because quake limited to that as a max, but really its best to use a multiple of whatever your monitor is running at (so long as it can actually be achieved).

If an unmodified engine is modified to run faster than 72fps, plats can think they get blocked mid-way and fail to work. I don't remember the reason for this.
NQ engines send out a new update EVERY server tick, you don't want to increase the framerates too high (in multiplayer) because now you're spamming the network like crazy.

[Baker]

The host_frametime -- the time slice or however one prefers to think of it -- should in theory be frame rate independent.

Really, I'm wondering why changing the fps changes the physics at all. Yet it does.

Must be some other factors that the engine server timing isn't taking into consideration. Or the id1 progs. Or probably both.

[The inner mysteries of Quake ....]

[Spike]

framerate dependance comes from the fact that acceleration and movement is not atomic. specifically, that when you apply gravity, and then move, slower frames will have more gravity than faster frames.
if you say you have two fast frames for the total duration of a slow frame with everything else the same, the short frames may be able to move up then down where the long frame moves down.
The strength of gravity is the same, your velocity_z is the same in both situations, its just that with one you managed to apply more of the move *before* gravity was applied.

The easy solution is to apply half of gravity before the frame, and half after the frame, preventing it from rounding up nor down.

Note that this applies with all velocity changes, just that gravity is the most measurable.

[mh]

These two links are good reading:

http://www.niksula.hut.fi/~hkankaan/Hom ... avity.html
http://gafferongames.com/game-physics/f ... -timestep/

What I'm currently using is a slightly modified version of the Gaffer on Games article - I don't bother with handling the less than 72 fps case (a few things get simpler this way and I run so fast that it rarely happens anyway). This has evolved another step or two in as-yet unreleased code - there, Host_Frame never returns early and both client and server events are based on a time elapsed since they last ran. That fixes up some instability problems encountered on some machines where sometimes two server timeslices would pass before running.

My theory is that 72 fps was chosen because it was the common refresh rate on old CRT monitors at the time. Just like modern games tend to lock at 60 fps (or some multiple) - no other reason, really.

I'm with Metl that 72 fps shouldn't be considered "optimal" - there's an Abrash talk from 1996/97 where he makes mention of "40 fps at 640 x 480" so I use that as a ballpark guideline. I'd actually prefer to run my physics at around this rate, or maybe a little higher (40 or 50 divide nice and evenly into 1000 too, which helps a lot with millisecond timers), but I'm aware of the general assumption that it runs at 72 so don't want to deviate from that.

I highly doubt that Quake was seriously tested at anything above 50 fps back in 1996 - especially so because the original physics was designed on a software renderer which ran like mud for such a long time during development.

It's interesting that older versions of Direct 3D (9 and before) had a D3DPRESENT_DONOTWAIT flag, which in theory would return immediately if the hardware was waiting on a vsync interval, so you could do some useful work (or just yield the CPU) during that time period. It was supposed to be supported by AMD/ATI but I never got to test it; it definitely never worked on NVIDIA so I never really bothered with pursuing it any further. It would have been good for running physics at 72 fps with vsync enabled though.

I'd add a multiple of your mouse polling rate to the conditions that Spike mentioned.

[leileilol]

[Spike]

more thoughts:

if you're running the video at 40 fps (which is a better 'optimal' value if you ever use millisecond timings anywhere), and the server is running at 72 fps, then you basically skip almost every other frame. but its a low framerate and you can expect big jumps, and the fact that its moving every single frame will help cover the fact that its not moving smoothly.
if you're running the video at 72 fps and the server at 40 (without interpolation) then your ents will move almost every other frame, but not quite. you'll see other things (like view angles and particles) moving more smoothly, and it can be quite jarring.

a higher server rate will also reduce apparent latency (assuming your connection can cope).

Also, if your engine uses millisecond precision, you should be using 77fps instead of 72, as it divides more cleanly. You could instead use a different numerator from 1000, of course, but then you have to apply some sort of numerator/denumerator for all time/seconds values too.

You also have the issue that whatever framerate the server is running at, you cannot possibly expect it to have 100% reliability with packet timings, especially over the internet, so the actual server intervals doesn't really matter - your interpolation *has* to cover timing issues and should easily be able to stretch to other frequencies too.

If monsters are stepping at 10hz, you probably want to use a framerate that is a multiple of that, also.

And yes, you want a multiple of the mouse sampling frequency also.

So really... Just fix the physics and make some decent interpolation and then it really doesn't matter what framerate your server or client runs at, so long as its not faster than your clock code can accurately measure.

[mh]

To be honest, if you're using a millisecond timer you should be thinking milliseconds per frame rather than frames per second. So pick 12, 13 or 14 and measure based on that - 14 is a decent approximation to Quake's default 72 (it's about 71.4), 13 comes to about 77 and 12 to about 83 - all are good enough numbers. Either way you'll probably get complaints from the ultra-trads who won't settle for anything but 72 ("it wus good enough fur mah granpaw, it wus good enough fur mah paw, un it's gunna be good enough fur me!").

Anyway, that becomes not "if (realtime - oldrealtime < 1.0 / 72.0)" but "if (realtimems - oldrealtimems < 13)" - or whatever.

[qbism]

[leileilol]

i'll also throw out there 320x200 (default resolution) operated at 70hz refresh

Doom was all 35hz to sync with 70hz

[mh]

That code is basically correct and was derived from the Gaffer on Games article I linked. There's a bit further cleaning needed to be done in terms of interpolation and some framerate-dependent effects (particles and dlights), and it's a good idea to remove all occurrances of the host_frametime global and instead pass the correct frametime as a param to each function that needs it.

Interesting to note that id already had the #ifdef FPS20 stuff in there which was very similar...