• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Satharis

Negatives to Triple Buffering?

2 posts in this topic

So both via Google and forum searching I've come up on wildly varying information about triple buffering and its impact, I'm trying to figure out what the legitimate information is.

I've read everything from it causing input lag(I don't see how it can) to even John Carmack tweeting that it is horrible and causes "lag and jitter" but again I don't see any reason why that would be. From an implementation standpoint it should always give higher FPS with vsync enabled(unless you're at the max fps for your refresh rate) correct?

I've also read conflicting information on whether D3D supports it, despite the fact dx11 and dxgi seem to be able to use more than one backbuffer and have different swap methods.

Guess my question is if there is any actual lag and what would cause that, along with how much of that is just misinformation.
1

Share this post


Link to post
Share on other sites

Why would it always give an FPS improvement?

Because with vsync if you can't maintain 60 fps you end up missing every other blanking interval, thus your fps gets locked to half because if you say are drawing every 20ms then you'd miss the first interval, and have to wait till 33.2 to begin drawing, since the back buffer would be sitting there full at the 20ms mark waiting for the next blank. Whereas with triple buffering it can start drawing as soon as it finishes that frame at 20 ms and ends up raising your FPS since you have the image finished in time for many more intervals.

Unless I'm mistaken there.

All buffering causes input latency. With show-A/draw-B, show-B/draw-A (double buffering), they GPU is one frame behind the CPU, which is adding 16ms input lag (@60Hz).
Tripple buffering is show-A/draw-C, show-B/draw-A, show-C/draw-B, meaning the GPU is two frames behind the CPU, creating 33ms of latency (at 60Hz).

I thought the entire idea behind input lag was the time you press a button till the time you see it on screen. In that case in a best case scenario its 16.6 ms of delay with vsync on since present blocks until the blanking interval, meaning if you hit a button at 20 ms after drawing the first frame in 10ms you would see the first frame at 16.6, then the game loop probably misses your input until the next go around(done drawing at 26.6, waits till 33.2 to show your action) and so on.

Then with triple buffering if you are at say 45 fps instead of 60 you'd go something like..

Draw first frame in 22.2 ms, miss first interval, immediately start drawing next frame, 33.2 presents frame, player sees it and presses button in same period of time, input is in at 36.6, frame is done at 44.4, wait till 49.8, get player input and action gets worked into next frame, see next frame at 66.6. So basically give or take 30 ms delay.

Compared to just pure vsync at 45 fps you'd get dropped to 30 and still get the input in the same period of time roughly since the input would be queued up. So I guess it shouldn't make your input latency worse nor improve it?

Unless I have that wrong, I'm bad at doing this kind of stuff in my head. I'm not actually totally sure of implementation details, I was assuming that vsync with two buffers will block a present call until the vsync whereas with triple buffering it will not block but it won't present the recently drawn buffer until the next blanking interval. Maybe that's wrong. I've never really checked the behavior.
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0