Chief Blur Buster wrote:VSYNC ON does input lag, though it does stable frame times by its own nature -- the VSYNC timing forces a fixed wait-time period regardless of frame times.
Are you 100% sure on that one? There's many games out there that seem to render more frames while the current frame is still waiting for the vblank. What then happens is that those frames are pilling up in buffers. Furthermore, they are rendered as fast as possible, until all buffers are filled.
I think we're both right, "depending":
AFAIK -- turn off multicore rendering in Source engine games, and you should get fixed-latency input reads in Source engine games during VSYNC ON. Or even, in much older games such as GLQuake.
It certianly varies from game to game. But clean double-buffered-ONLY VSYNC (no extra buffers) with input reads occuring right after page flips, ideally serve to create a fixed latency, by providing the metronome of input reads. If it's done in this cycle: Input read [instant], Render frame [takes time], Wait for vsync [takes time], Display rendered frame [instant], rinse and repeat -- input reads then practically occurs at the same time as VSYNC. So in this case, you have a predictable fixed lag, even if more laggy. But if the input read (i.e. in another thread) occurs immediately after the render, but before waiting for VSYNC, then the latency of input reads would jitter around depending on frame render times -- despite having a fixed framerate! Varying input lag at a fixed framerate is more annoying than a slightly larger but fixed (stationary) input lag.
Even if you're at 60fps, input lag that vary in a 1/60sec window, can throw off aiming -- people can compensate more easily for a predictable fixed lag (e.g. the "predictable lag" of steering wheel response in racing games). Varying input lag is much easier to see when a game suddenly flips between 30fps and 60fps, but varying input lag can still occur even at a fixed framerate. The higher the framerate (e.g. 120fps@120Hz) the input lag variance window during consistent framerates, would be smaller (a 1/120sec variance window), but can still be noticed. The varying input lag behavior is a bigger problem at 60fps.
I wonder if any framerate limiters does creative methods of rendertime-lengthening (e.g. slows down rendering of fast-to-render frames) as an alternative workaround for those particular games.
There are occasional situations (not at FPS tournaments though!) where slightly more input lag is desired to make the input lag fixed/predictable/consistent.
In car racing games the steering wheel is naturally laggy like a real car, but at least it is a predictable lag, and you can train yourself to it. It's when the lag varies that it's harder to train to.