We often neglect to get too involved in the discussion of what options people should always enable when they play games. Rather, we tend to focus on what we test with. Honestly, our recommended settings for playing the games we test would be very similar to the settings we use to benchmark with one very important exception: we would enable triple buffering (which implies vsync) whenever possible. While it's not an available option in all games, it really needs to be, and we are here to make the case for why gamers should use triple buffering and why developers need to support it.
Most often gamers, when it comes to anything regarding vsync, swear by forcing vsync off in the driver or disabling it in the game. In fact, this is what we do when benchmarking because it allows us to see more clearly what is going on under the hood. Those who do enable vsync typically do so to avoid the visual "tearing" that can occur in some cases despite the negative side effects.
We would like to try something a little different with this article. We'll include two polls, one here and one at the end of the article. This first poll is designed to report what our readers already do with respect to vsync and double versus triple buffering.
{poll 134:300}
After reading the rest of this article, our readers are invited to answer a related poll which is designed to determine if arming gamers with the information this article provides will have any impact on what settings are used from here on out.
First up will be a conceptual review of what double buffering and vsync are, then we'll talk about what triple buffering brings to the table. For those who really want the nitty gritty (or who need more convincing) we will provide follow that up with a deeper dive into each approach complete with some nifty diagrams.
Facebook
Twitter
RSS
184 Comments
View All Comments
DerekWilson - Wednesday, July 1, 2009 - link
"skipping" doesn't occur in games like it does with a video -- there is not a set number of frames that must be rendered in a set amount of time. The action happens independently of the frames rendered in a game, while for a video you there is an exact framerate that needs to be maintained in order to see smooth motion as it was captured.in the old days, console games would tie the game timer to framerate which was always set to vsync. If frame rate dropped from 60 FPS to 30, the game would actually slow down (when too much action was going on on the screen). Modern PC games do not rely on framerate to time their game, in stead framerate is a snapshot of the game at a certain time.
if you drop all but the most recently completed frame, then you are just doing triple buffering the way this article describes.
ufon68 - Monday, March 28, 2016 - link
This not completely accurate.While usually, and for a good reason, physical simulation indeed "ticks" independent of FPS, the actual gameplay logic is usually tied to the frames being displayed.
You don't see the game slowing down or speeding up because the simulation takes into account the FPS speed, ie. it multiplies everything by the delta time which is the time it took to tick the last frame.
For instnance to translate an object along a vector at a certain speed, you move it every frame by: Direction * Speed * DeltaTime (DeltaTime being the time it took the game to tick the last frame in seconds, given a constant fps[just for simplifacation purposes, the fps can move up and down and this will still work] of 10, the DeltaTime is 0.1 for this given frame/tick)
So it's not correct that what you see are snapshots of what's going on in the game world, it just gives you that impression by doing this neat trick.
VinnyV - Monday, June 29, 2009 - link
I just wanted to say that I really appreciate this article. I think I just went from understanding about 10% of what is usually discussed on this site to about 11 or 12%. Thanks! Please post more articles like this!iwodo - Monday, June 29, 2009 - link
I see this as an Direct X Problem only? May be we should call Microsoft to improve on it... ( Too Late for Direct X 11?? )Dospac - Sunday, June 28, 2009 - link
Derek, it would be interesting to get to the bottom of the multi-GPU input delay issue as well as devise a quantitative way to test the delay with various setups. It's confounding that this hasn't been investigated sooner and been sorted out. The potential PQ improvement is well worth your efforts. Thank you!DerekWilson - Sunday, June 28, 2009 - link
getting to the bottom of why delay happens conceptually isn't that complex -- there are a lot of issues in interGPU communication and synchronization that can cause issues.quantitative testing is possible but pretty expensive ... i'll see if i can convince Anand to invest in the equipment :-)
DerekWilson - Sunday, June 28, 2009 - link
Added a note at the end of the article to try and help clear the air about the confusion over triple buffering as a page flipping method and flip queues (render ahead) with three buffers.I also wanted to note that this topic is not just confusing for gamers -- game developer do not always get their labeling right and sometimes refer to flip queues a "triple buffering" incorrectly.
I do apologize for not addressing this issue at publication, but I hope this helps to clear the air.
Touche - Sunday, June 28, 2009 - link
Have you seen this?http://msdn.microsoft.com/en-us/library/ms796537.a...">http://msdn.microsoft.com/en-us/library/ms796537.a...
http://msdn.microsoft.com/en-us/library/ms893104.a...">http://msdn.microsoft.com/en-us/library/ms893104.a...
DerekWilson - Wednesday, July 1, 2009 - link
What they are showing is 1 frame render ahead with vsync. In MS DX terms, this is a flip chain with 2 back buffers and a present interval of one.This is them calling it triple if uses three total buffers. This is still a flip queue and should be referred to as such to avoid confusion.
mikeev - Sunday, June 28, 2009 - link
Add me to the list of people who tried triple buffering but had to turn it OFF due to the input lag.I ran the test in L4D anyway. It was unbearable. I couldn't hit a thing. The input lag was actually noticeably less with double buffering + vsync ON.
Maybe I'm doing something wrong, but my results do not jive with this article at all.