Porting to just-in-time VSYNC ON: discussion and feedback

[pisto]

Hello.
I took interest lately in tear free and low latency gaming. I am not myself a progamer and I have laughable hardware at disposal, but I am the maintainer of a mod of Sauerbraten: Cube 2 (a Quake-like game, so I'm told), and there's a moderate demand in the community for a more low latency implementation of the engine.

I am posting here because I need some feedback on my work from people with some experience and good, varied hardware and OS. I need subjective impressions on mouse responsiveness, and maybe hints on how to objectively measure the lag, and any kind of feedback you feel like to give.

I am attempting just-in-time VSYNC ON. I prefer this instead of VSYNC OFF because it provides an implicit way to get good vsync timestamps, on all platform and with a well standardized API, and I suppose that being vsync a hotly requested feature it is probably well supported by most drivers. If a frame is late for vsync, I switch to VSYNC off on the fly to avoid discarding the frame in its entirety: I am not sure that this is well supported widely, so please test!

How to test the thing

To test, please install Sauerbraten, then install the mod (instructions in the archive). Start the game, press t (for chat/console), and type the following commands:

Code: Select all

/vsync 2
/showfps 1
/map ot

You should now be in a simple scene. This is the meaning of the numbers in the lower-right corner:

• fps: frames drawn (should match your monitor refresh rate)
• lag x(y): x measures the lag between game state read and frame display with VSYNC, y show the time wasted in waiting from VSYNC
• miss x(y): x is the number of VSYNC misses, y is the number of the just-in-time logic resyncs, which most probably cause microstutters.

The time spent waiting for vsync is completely wasted, but it is necessary to avoid tearing. A too high value increases lag, but a too low one causes vsync misses and consequently tearing again, or timing logic fuckups that require a resync and so microstutters. You can adjust it with the variable "jitvanticipate", in nanoseconds:

Code: Select all

/jitvanticipate                 //shows the current value on the console, default 1500000 (1.5 ms)
/jitvanticipate 1000000         //set it to 1 ms

You may lower the graphic settings from the main menu (hit ESC). Also a play test on a real server would be nice (again, main menu).

With

Code: Select all

/vsync 1

the engine does not try to move the frame draw close to vsync, but the engine still runs while a frame is waiting to be shown, because the implementation is multithreaded (one engine thread, one drawer thread). It should still be an improvement over standard one engine update - one frame drawn. You may test that aswell.

You can test /vsync 0 as a baseline VSYNC OFF implementation. You can limit the fps with "/maxfps <value>".

[flood]

a good way to measure your program's input lag is to enable the operating system cursor and draw a box that follows the cursor. move your mouse around and see how they track each other


with vsync off, at high framerate, the box and cursor will track perfectly at the top of your screen. at the bottom of the screen, the box will lead the cursor by 1 refresh period (16.7ms for 60hz).

with vsync on, the box will lag behind the cursor. if you track the motion with your eyes, you'll see
either
(b is box, c is cursor)
1 frame lag: bbbbbccccc
2 frame lag: bbbbb_____ccccc
3 frame lag: bbbbb__________ccccc
when the cursor is moving right.

when I was playing with this on linux, I recall the vsync lag is 1 frame on intel graphics and 2 on nvidia graphics

with the just in time technique, you can reduce up to 1 frame of input lag