"transfer time is irrelevant"
[Proceeds to explain the cases where it's relevant]
Different LCDs are capable of different things. If you send it an extremely small frame (such as 800x600 16kcolors) then it doesn't need to wait for the entire panel worth of data to be transmitted before it has data with which it can write to the bottom row. Then the added latency is up to to the specific monitor. If it has a lightning fast rescaler and can blot every scanline together fast enough, you've saved time. I have a monitor for which this is the case. Running at 120fps 60hz 800x600x15bpp(16bpp) is noticeably more responsive than 120fpz 60hz 1680x1050x24bpp.

tl;dr: It depends on your monitor. Transfer time is still a hard limitation in addition (actually max() in the case setsul described) to whatever the panel itself is capable of.

Don't use triple buffering in DX games. DX doesn't support classical (low-latency) triple buffering. (post-DX9 might, but I wouldn't know.) http://www.emutalk.net/threads/14075-DirectX-multiple-back-buffer-question >DX can support more than 2 buffers, but the order of buffer swapping is fixed (always flipping in a circular matter), not flexible. I am wondering if someone knows a secret way to do so.

Addemendum:

http://i.imgur.com/jjE3q2K.png

Based Setsul

>FWIW, most of the arguments in this thread are intimately tied to how idTech/GoldSrc/Source are designed, which might explain your impression that:

No, they're tied to how PC hardware sync in general works. Universally. You'll only find "good" video/audio timing on old consoles such as the NES and SNES, where games were intimately designed around hardware timing.

It's also important to use the best monitor connection you have. HDMI 1.0 is supposed to saturate at 24-bit 1080p60hz (sometimes I read 1600x1200x60hz which is slightly more), which means that it's constantly transmitting frames, so transmitting a single frame will take 1/60th of a second, increasing "how far in the past" the frame already is by that much. I'm not sure exactly how each protocol works, but that should be a hard limitation. Newer versions of HDMI and DisplayPort provide much higher bandwidth, which should let a single frame be transmitted during less time, and if the protocols are any good at all they should already do that.

If you can't then running at 800x600 fullscreen should actually decrease lag too.

"classical" triple buffering also adds input lag but only when there would otherwise be noticable tearing.

Thanks for noting the important distinction that DX triple buffering has, however.

Quoting myself:

If you have 60fps on a 60hz monitor, your base latency is 0 to 1/60th of a second (0~16ms). If you have 120fps on a 60hz monitor, your base latency is 0 to 1/90th (0~11ms) of a second.

The actual rate of displayed frames is a hard limit of 1/60th of a second (16ms), and the game's rendering rate is another up to 1/fps on top of that, since they don't sync with eachother (and when you do sync them with eachother/vsync it raises your latency floor)

Exactly 60fps on a gsync/freesync monitor would be better than 120fps on a normal 60hz, unless said monitor has higher processing latency or is set up incorrectly.

Anyway, you have all these interlocking rates at which things are sent off to other systems in your computer. The general flow is input -> game -> render -> monitor. The render -> monitor stage is infamous for all sorts of crazy convolution.

When you have a monitor that runs at a set refresh rate, there's no way to render the same number of frames and make sure you still have the lowest possible latency. The reason is that, abstractly speaking, the monitor has to look at the last frame that was rendered, and if it's rendered at the same rate, it's going to generally be half a frame behind. If it's rendered at a higher rate, that window decreases.

If you run at a slightly higher framerate, it makes the latency window increase up to the length of a game frame, go back to 0, and decrease again. It looks like this:

http://i.imgur.com/RebCGsf.png

(Keep in mind that the game update has its own latency, since it needs a consistent input state for its entire duration, it has to sample input at its beginning)

If we lived in a perfect world, the game engine could tell how far behind the monitor it is, and adjust. But we don't, so increasing the framerate dramatically or using a gsync/freesync monitor is what we've got.

they have less friction on the desk but they weigh more

Yes, bad QC.

tell aimbot devs that it's optimal if they aim exactly two degrees off-center when nospread is enabled because it maximizes the number of pellets that hit

watch them fuck it up and their hacks become useless

tbh I never understood why it was so much more common to "bust" CS cheaters despite the game being easier to silently cheat at. I always assumed that TF2 cheaters stayed away from comp more than CS cheaters did, guess not?

lol setsul

i might actually like the tires change you considered for mid

diagonal FoV so i can play on 5:4 and not get shit on when?

orange is "normal"

yellow is what's bad

Excellent changes Crash.

The first thing you should do is start airstrafing around corners during rollout. The second thing you should do is realize that everything else "bunnyhop"-like is so random that it's worthless since you can't build up speed anyway.

@itsnechum: Try this:
http://teamfortress.tv/thread/20219/detail-sprite-commands