I have some experimental code that seems to eliminate the notorious "vsync lag". Everyone's welcome to test this.

Instructions:
1. Download http://zquake.frag.ru/misc/ezquake-gl.exe and run it. This is a current cvs build so you're welcome to compile one yourself if you're paranoid.
2. Type show vidlag (scr_newhud must be enabled for this to work)
3. Run around and take note of your video lag. Yes, there is some video lag even with vsync off. *
4. Now enable vsync (type vid_vsync 1) and see your video lag (which we can call vsync lag now) soar. But don't abandon hope yet, for Tonik is coming to save you!
5. Type cl_vsync_lag_fix 1 and watch your vsync lag drop to ~1ms.

This may or may not work for everyone. So please tell me what results you got.

(You may notice that there's another new cvar, cl_vsync_lag_tweak. It's hard to explain what it does so to avoid confusion please leave it alone for now.)

* The non-vsync lag value you will see is an estimate. It's not possible at this moment to calculate the precise value.

UPDATE: It's pointless to try this if you have vsync forced off in video driver settings (if vid_vsync 1 doesn't snap your "show fps" to the monitor's refresh rate, then you do). 'show vidlag' will report 0.0 ms in this situation, but that value will be totally bogus.

Don't acutally know what this does.

But with my settings i have 0.2 - 0.5 in ms
vsync on, 0ms

sounds cool, look forward to taking a look at the code in svn for this, is it cross platform code for all GL renderers?

It's #ifdef _WIN32 #ifdef GLQUAKE for now, but it should be possible to make it work on any platform/renderer

Works for me.

vidlag with vid_vsync 0: 3.2ms
vidlag with vid_vsync 1: ~14ms
vidlag with cl_vsync_lag_fix 1: ~1ms

So what exactly does it do? Does vsync still work, without calculating frames into buffer beforehand?

vsync still works, but the processing of each game frame is timed in such a way that the scene is rendered just in time for the vertical retrace, so that SwapBuffers() fires without waiting.

If your system can sustain a solid 500 fps or so you're still better off without vsync; however vsync might be a better solution for lower end machines where you get tearing otherwise, or for LCDs @ 75 fps (cl_independentPhysics 1, vid_vsync 1, cl_vsync_lag_fix 1)

I've been using 308 fps, but I suppose my system could easily go higher... What are the benefits of 'even higher' fps, why 500 or so and why's that better without vsync? Questions, questions...

better interpolation the higher fps you have

The benefits are getting less and less noticeable as fps increase. I'll be surprised if you can feel the difference between 500 and 300 fps. > 500 fps is probably pure placebo land

By the way, this build also fixes the bug that made independent physics jerky at low (as in 100-200) fps.

is that good?

It's no difference. By the way how come you get these values phrenic? 0.2ms non-vsync lag means you have 2500 fps 8-[]

it definatly eliminates tearing. and looks smooth

normal lag 3ms
vid_vsynch 9ms
cl_fixvsynch 0ms


my specs
tft 1024 1068 75hz
154 unstable fps

dosnt wrk for me: nvida 7900gt amd x2 4200+

When i dont use vid_vsync i get 0.2 - 0.4 ms "lag" when i use vid_vsync 1 i get 0 ms and the movement gets slow and inresponsive, even with cl_vsync_lag_fix 1

One strange thing though is that i get like 100 fps more with this client than 1.8.2. How come?

jOn, please try http://zquake.frag.ru/misc/placebo-jOn.cfg (this is a customized version of placebo.cfg.

The rules are simple: it chooses a random setting for vsync and lets you guess

If you think vsync is on (you should be able to tell by 'slow and inresponsive' movement), press F1
If you think vsync is off, press F2

Tell me what statistics you got.

Ill look into it l8r, tnx

Does it matter if sync is always off in control panel, seemed to wrk in qw anyhow.

Then it doesn't matter

Ok! :-) and yes i had that fps

OK, I'm really curious to know what cl_vsync_fix_tweak does. When I set it to 0, vidlag is very minimal with vsync. With it set to 1, vidlag is at 1. It seems like vidlag just uses this value when vsync is on ?

Interesting stuff. I normally run qw at 800x600@160hz with vsync off and get around 500-1000fps, depending on the room I'm in. When I turn vid_vsync on at 160hz, cl_vsync_lag_fix 1 has no noticeable effect on the lag from vsync. When I drop down to 75hz and toggle the command, the change in video lag is very noticeable. However, it sort of feels like the game gets situationally jerky to fast movements... but I suppose that could be because I'm used to 160hz and 500+fps .

PlaZmaZ, cl_vsync_fix_tweak is a safety margin to avoid skipping of frames.

The essense of the vsync fix is that "the processing of each game frame is timed in such a way that rendering finishes just in time for the vertical retrace and SwapBuffers() fires without waiting."

My code keeps history of the render times of the last 5 frames, and it uses the maximum of these in calculating the right time to start processing the new frame. But if rendering takes longer than expected (say you were facing a wall and then turned around, render time soars), SwapBuffers will be called too late and it'll have to wait a whole new monitor refresh cycle until the next vertical retrace. You may notice occasional fps drops if you set cl_vsync_fix_tweak too low.

So cl_vsync_fix_tweak 1.0 ensures that rendering ends (on average) 1.0 ms before vertical retrace ends.

Do you actually feel the difference, or are you just judging by the vidlag display?

I've been testing cl_vsync_lag_fix with the placebo cfg but even at 60 Hz (vsynced), although I feel I can tell the difference, I get a lot of wrong guesses :-/ But that may have some correlation with the fact that after 10 years I still suck at quake, so I'm very interested in input from a pro

Tested this one too. I run my qw 77fps/154fps on 150Hz monitor refresh.

Vsync disabled: Well, nothing to tell here, works good

Vsync enabled: Obviously limited to 77/150fps on 150Hz monitor, the mouse felt really strange and it was really hard to make small corrections... felt like there was lots of sensitivity when trying to move mouse a bit.

Vsync enabled + fix: Same applies here conserning fps. However, the mouse feels "considerably" better even though it feels a bit sluggish still. Also got some strange side-effects probably due to fps-i enabled physics, like jerkyness when moving from time to time. Might be something else if I used 154Hz refreshrate and 154fps maxfps.

Vsynd disabled + fix: Feature seems to be disabled = no change to normal vsyncless operation.

Exactly the same here.

Did some 'placebo' testing 20 times and scored 18:2
Both times I guessed wrong were when vsync was off - i.e. I could always tell when vsync was ON and guessed correctly, but a couple of times when it was OFF I convinced myself incorrectly that there was a slight lag and hence hit F1.

For anyone else considering testing vsync, I always find DM3 bridge is a good place for this.

The fix for jerkyness at low fps with independent physics seems to work though.

One strange thing I noticed however was that my conchars isn't getting picked up in this build (or maybe it's reading from one in another directory). I still use the oldschool method of modified conchars.pcx in gfx.wad normally....

edit: Oh, one more thing. I noticed that SHOW VLAG reports 0ms with vid_vsync 1, even if vsync isn't actually enabled (i.e. it's forced off at driver level and framerate remains unlimited). Any reason why the value changes from the normal ~0.3ms I get with vid_vsync 0?

FPS 217 unstable @ 60 Hz TFT

The usual vidlag is ~2.3 ms and with vsync it raises to ~15 ms. The fix gives a vidlag of 0.2 ms, which is however unplayable. I've checked it with the placebo-jOn.cfg and got every single guess right (out of 30). :/

Aha, it seems we've got a problem here. My code can't detect the situation when vsync is forced off in the drivers and continues to apply the 'fix' happily. But in this case, it is useless at best.

I found it strange that jOn reported '0ms' lag, but I convinced myself he was referring to the 0.x (occasionally 1.x) values that I get here.

What I can't figure out yet is why you and jOn are getting that input lag with vid_vsync but without cl_vsync_lag_fix, if it's disabled by the drivers it's not supposed to affect anything (other than the 0ms vidlag display which in this case is totally fake)

EDIT: jOn: "and the movement gets slow and inresponsive" <-- oh, slow as if sensitivity dropped 2x? Is that what you get, HangTime?

That sounds like the problem I get every now and then in ezQuake, vsync off (but never with zquake, it seems). Never figured out how to avoid it, I have no freaking idea how that can be caused by vsync which is disabled by drivers :/

Do you get solid 60 fps with vsync?

No, it actually does say 0.0ms (fluctuating to 0.1ms occasionally) According to that stat, I have less VIDLAG with vsync enabled than I do with it disabled.


Nah, it's not a sens change. It's as if I'm pulling my mouse along by a spring or something, or dragging it through treacle. The actual sensitvity is the same, doing a 180 flick turns me 180 degrees, but it just isn't responsive. It almost feels like the screen keeps turning after I've stopped moving the mouse.

OK, then it's not what I thought.

Do you ever get tearing? Say with vid_displayfrequency 75, cl_maxfps 80? Does QW's vsync change anything then?

Yeah, with vid_vysnc 0 I get tearing sometimes if using e.g. 75hz 75fps
With vid_vsync 1 there is no noticeable tearing