ezQuake: Just-in-Time VSYNC
Posted: 06 Jan 2014, 22:32
The discussions here by Mark and Ahigh prompted me to find a semi-modern PC game that used just-in-time rendering, and I came across a post by Tonik, one of the programmers of ezQuake, documenting the game's vsync lag fix:
http://www.quakeworld.nu/forum/topic/24 ... g-solution
The whole thread is interesting, but the important part is here:
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.
At the time (2007), rendering times may have been an issue, but now it's relatively easy to peg the game at 1000 FPS, so I wanted to see how this compared to VSYNC off.
I'm using a CRT, so I tried several different resolutions and refresh rates: 800x600 at 160 Hz, 1260x945 at 120Hz, 1600x1200 at 96 Hz, and finally 2560x1920 at 57Hz.
Playing at 160Hz with VSYNC off, hitting 1000 FPS (with a corresponding mouse polling rate), the immediacy is exhilarating. I'm not sure I could distinguish 1000 FPS from 500 or even 300, so I'd need to do some ABX testing, but it's scary good. Tearing is not an issue here. I suspect this would sound crazy anywhere other than BlurBusters, but I still want a higher framerate; I can distinguish individual frames during fast mouse movements.
ezQuake's VSYNC fix is best implementation I've experienced. Tonik actually challenged responders to check whether or not they could tell a difference in that thread. The testing cfg file is no longer there, but I can see how at lower mouse sensitivities, you might not be able to distinguish. Fast mouse flicks still feel slightly dulled.
That slight VSYNC lag remains regardless of the refresh rate, so as those rates decrease down to 57 Hz, the tradeoff is how annoyed you are with the screen tearing. I should have tried something between 57 and 96, but I found at 96+ Hz, tearing is unobtrusive. At 57Hz, the tearing is pretty conspicuous, and VSYNC on looks much better.
So if you have your old Quake files, grab ezQuake here and try it out:
http://ezquake.sourceforge.net/
http://www.quakeworld.nu/forum/topic/24 ... g-solution
The whole thread is interesting, but the important part is here:
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.
At the time (2007), rendering times may have been an issue, but now it's relatively easy to peg the game at 1000 FPS, so I wanted to see how this compared to VSYNC off.
I'm using a CRT, so I tried several different resolutions and refresh rates: 800x600 at 160 Hz, 1260x945 at 120Hz, 1600x1200 at 96 Hz, and finally 2560x1920 at 57Hz.
Playing at 160Hz with VSYNC off, hitting 1000 FPS (with a corresponding mouse polling rate), the immediacy is exhilarating. I'm not sure I could distinguish 1000 FPS from 500 or even 300, so I'd need to do some ABX testing, but it's scary good. Tearing is not an issue here. I suspect this would sound crazy anywhere other than BlurBusters, but I still want a higher framerate; I can distinguish individual frames during fast mouse movements.
ezQuake's VSYNC fix is best implementation I've experienced. Tonik actually challenged responders to check whether or not they could tell a difference in that thread. The testing cfg file is no longer there, but I can see how at lower mouse sensitivities, you might not be able to distinguish. Fast mouse flicks still feel slightly dulled.
That slight VSYNC lag remains regardless of the refresh rate, so as those rates decrease down to 57 Hz, the tradeoff is how annoyed you are with the screen tearing. I should have tried something between 57 and 96, but I found at 96+ Hz, tearing is unobtrusive. At 57Hz, the tearing is pretty conspicuous, and VSYNC on looks much better.
So if you have your old Quake files, grab ezQuake here and try it out:
http://ezquake.sourceforge.net/