OK, so as I understand it, what is being discussed here is at what point in time a frame was rendered between the time the last frame was displayed on the screen and the next is displayed on the screen. With V-Sync on, I suppose it is rendered closer to when the last frame was displayed, but with it off it is rendered closer to when the next frame is displayed, since it is continually overwriting the buffer. With hardware that can always render at least as fast as the refresh rate, the difference between these times would depend on how much faster your hardware can render than the refresh rate (note that when it is slower, with V-Sync on it is still waiting for the frame to finish rendering, so it didn't have a new frame to display on the next refresh). It would also depend on how the game is coded, because some games may render at different times than other games in that time between each refresh.
At worst, the difference between these times could be 1/(refresh rate), but at best there could potentially be no measurable difference between V-Sync on and off (if it is always finishing rendering the frame just before the next refresh).
Post has been edited 1 time(s), last time on Apr 19 2012, 3:26 am by ShadowFlare.
None.
Most everyone uses triple buffering. That means you store 3 frames ahead of time. If you're at 60 fps, that's 50 ms. If you're at 200 fps, that's 15 ms.
If I'm wrong (which I may be) just know this: people can tell the difference. All of your explanations on "but this is inconceivable" don't really do anything when I can seriously tell the difference between 800 fps input lag and 60 fps input lag on most games. To me, it's a fact, and there are thousands of others who agree with me on the matter. I would say millions, but it's likely they don't care, or are not using their computer for time-sensitive material in an urgent fashion.
Really? Triple buffering is off by default in CCC. Your post succinctly explains the issue well, though. As a fighting game enthusiast who has a horrid reaction time, I can verify that the statement "input lag doesn't matter because it's small relative to reaction time" is utterly bullshit.
None.
I think we're on the same page here shadowflare:
Let's say you're not using triple buffering at all (if I even understand the concept correctly). the image on the screen from 0 ms to 16 ms doesn't change. if it takes 5 ms to draw a frame (200 fps), the frame will be drawn at 0-5 ms if vsync is on, and at 10-15 ms if vsync is off.
I really don't know enough about the subject to make informed decisions, other than the fact that I already know the results.
"Parliamentary inquiry, Mr. Chairman - do we have to call the Gentleman a gentleman if he's not one?"
I don't know if it is common, but I know some games essentially only poll input at every refresh cycle. I'm not completely sure of what effect that has in relation to the topic. It's possible that V-Sync may not have any noticeable effect other than eliminating tearing if the game was going to display the same frame regardless of what time it rendered it to the buffer or how many times (assuming a system fast enough to keep up).
Post has been edited 1 time(s), last time on Apr 19 2012, 10:19 pm by ShadowFlare.
None.
I don't know if it is common, but I know some games essentially only poll input at every refresh cycle. I'm not completely sure of what effect that has in relation to the topic. It's possible that V-Sync may not have any noticeable effect other than eliminating tearing if the game was going to display the same frame regardless of what time it rendered it to the buffer or how many times (assuming a system fast enough to keep up).
Yeah, for example SC2 only takes input during v-sync once per frame. So v-sync also syncs input to framerate.
None.
Which seems to be the obvious way to do it, really. What's the point of drawing something and sticking it in a buffer to display later if the card is completely able to handle the workload closer to the time it needs to display the frame?
None.
Yeah, most games poll input once per frame. Fighting games deviate from this to allow multiple directional inputs to be input in the same frame (or that's the reason I assume is true). VP polls at 100Hz when it displays at 60FPS, for instance.
Which seems to be the obvious way to do it, really. What's the point of drawing something and sticking it in a buffer to display later if the card is completely able to handle the workload closer to the time it needs to display the frame?
Because it is not possible to tell ahead of time precisely how long it will take to draw the frame.
None.
Which seems to be the obvious way to do it, really. What's the point of drawing something and sticking it in a buffer to display later if the card is completely able to handle the workload closer to the time it needs to display the frame?
Because it is not possible to tell ahead of time precisely how long it will take to draw the frame.
Sure, but why would you bother keeping this old stuff around in the buffer when you could just overwrite it with new stuff?
None.
that... kind of defeats the purpose of running at 60 fps.
"Parliamentary inquiry, Mr. Chairman - do we have to call the Gentleman a gentleman if he's not one?"
I don't see how. Have 3 buffers: current (what the monitor is showing), next (what the monitor will grab from next) and active (what the graphics card is drawing to).
Graphics card can constantly draw to the active buffer and every time it complete a frame, move it into the next buffer. When the monitor needs to draw the next frame, it locks whatever is in next, copies it to current and draws it.
None.
Graphics card can constantly draw to the active buffer and every time it complete a frame, move it into the next buffer.
How many frames does this graphics card draw per second?
"Parliamentary inquiry, Mr. Chairman - do we have to call the Gentleman a gentleman if he's not one?"
