5 replies to this topic

[dEVI]

First of all, I'm not a programmer, but I am a pro-player, and theres something that really annoyes me so I have to ask about it.

I play CS:Source, a HL2-based FPS-game, where its important to see the effects of e.g. moving your mouse as fast as possible on the screen. Playing with vsync on is good because you can make out fast movements better when each screen is drawn fully.

With double buffering, theres the problem that once your framerate drops under your monitor refreshrate, because the monitor will often have to redraw the 'front buffer', it will effectively almost halve your fps as the graphics card will remain idle _after_ having drawn the second buffer until the front buffer can be freed again.

Triple buffering works so that theres a third buffer to which the graphics card can start drawing the next frame in such a case.

What I have noticed is that when there is high load, it feels great. For lowfps, vsync simply feels much better. But when there is little load (and I'm assuming with vsync off fps>refreshrate) there is a lot of lag from moving my mouse. The way I understand this is that all the buffers are full, and my computer is again having to wait and draw screens at my refreshrate, only with a lag of 1/refreshrate.

But it should be possible to code this a lot better. I.e. having 3 buffers:
1) primary, 2) secondary, 3) drawing buffer. The gfx card would always draw to the drawing buffer. After finishing the screen, it would always (regardless of the monitor) transfer to the secondary buffer. The monitor would always draw from the primary buffer, then transfer the screen from the secondary buffer at vertical blank period. This way the monitor would always be drawing the most recent screen, and there should be no problems whether fps > refreshrate or fps < refreshrate.

Of course if it takes time to 'transfer' the screen, you can just have the primary buffer and two gfx buffers and implicate in practice the same thing.

[dave_]

Don't be daft. Where will the game draw while its transferring from the drawing buffer to one of the other buffers?

VSync on prevents tearing, shouldn't make any difference to making out faster movements. Its in your head probably.

The lag on moving your mouse is to do with the way the application is updating the mouse: synchronously with each frame.

When framerate drops below your refresh rate it can cause the displayed frame rate to halve again. Turn on triple buffering (if you've got an nvidia card its in the nvidia control panel). This should mean the updates can continue even if the frame is in use.

[dEVI]

dave_ said:

Don't be daft. Where will the game draw while its transferring from the drawing buffer to one of the other buffers?

Ah, I though this was obvious, as I tried to imply at the end. You should have the 'monitor' buffer and two 'gfx' buffers. The gfx card could always draw to the gfx buffer it didnt just finish drawing to. Then the transfer on vertical sync would be always from the newest frame.

dave_ said:

VSync on prevents tearing, shouldn't make any difference to making out faster movements. Its in your head probably.

Cant really fight this, if you dont notice it, you dont. I do.

dave_ said:

The lag on moving your mouse is to do with the way the application is updating the mouse: synchronously with each frame.

I dont understand this in the current context.

dave_ said:

When framerate drops below your refresh rate it can cause the displayed frame rate to halve again. Turn on triple buffering (if you've got an nvidia card its in the nvidia control panel). This should mean the updates can continue even if the frame is in use.

The whole idea of the post is that triple buffering sucks very much when there is little load and your game would be drawing more frames than are being displayed on the screen. This is dumb since it works optimally with doublebuffering, and it should be possible to have the same with 3 buffers as well. I was wondering why is it done so poorly.

[dEVI]

dave_ said:

VSync on prevents tearing, shouldn't make any difference to making out faster movements. Its in your head probably.

Besides, I think its obvious why it works so. When the screen is turning fast, two consecutive frames will look very different. Thus if the monitor is showing half of one and half of the next, itll be confusing to the eye. Vsync fixes that.

[GhostManZero]

dEVI said:

Cant really fight this, if you dont notice it, you dont. I do.

Well, if your refresh rate is 30hz, dont expect VSync to get FPS over 30. So for 30FPS, the mouse'd be updated 30 times a second. Dont expect it to be "fast", 'cos 30 times isnt always fast. However, if you set your refresh rate to like, 75hz, you'll get 75FPS, so your mouse will be updated far more times.

On a side note, however remember that "slowness" isnt always VSync trouble, but also the way the game handles the updates and the way the game draws itself.

dEVI said:

I dont understand this in the current context.

He means the mouse is updated once every frame, just like i explained above. That is, it's kinda impossible to update the mouse faster since:

A) the application is slowing down 'cos of the FPS ("not even threads can help you, kid...")

B) The application is using the graphics API (in this case, D3D9) and the input API (in this case, DI) to check when the mouse clicked or moved and where it clicked or moved too.

dEVI said:

Ah, I though this was obvious, as I tried to imply at the end. You should have the 'monitor' buffer and two 'gfx' buffers. The gfx card could always draw to the gfx buffer it didnt just finish drawing to. Then the transfer on vertical sync would be always from the newest frame.

That's just wrong.

All drawing buffers reside on the video card, there's no drawing buffer on the monitor, and the video card waits for the frame to draw on vsync, it cant draw anything else while drawing on vsync.
The only way to send graphics to the monitor is through the video card.

If you check Operating System Development Sites, their tutorials and documentation show that you gotta access the video memory in order to even print text to the screen.

VSync is not only used to prevent tearing, but also used to prevent the CPU from working too hard by limiting FPS.

Double-Buffering is possible 'cos it can still draw 30FPS if your refresh rate is 30hz, so basically it's like having a frame drawed for the first buffer then another frame drawed for the second buffer.

Something to think about it, quoted from Wikipedia:

"Another method of triple buffering involves synchronising with the monitor frame rate, and simply using the third buffer as a method of providing breathing room for changing demands in the amount of graphics drawn. This is the use of a buffer in the true sense whereby the buffer acts as a reservoir. Such a method requires a higher minimum specification of the target hardware but provides a consistent (vs. variable) frame rate."

"Advantage of triple buffering

If the system has three color buffers A, B and C, it does not have to wait to swap buffers. It can display buffer B while rendering into buffer A. When done rendering into buffer A, it can start rendering into buffer C immediately. When the monitor is in vertical blank, it can display buffer A and make buffer B available for reuse.

Limitations of triple buffering

If the system always renders buffers in less time than it takes to display a buffer once on the monitor, the computer will wait for the monitor regardless of how many buffers there are. In this particular case triple buffering has no advantage over double buffering.

Also, third buffer uses additional memory, which could be used for other data (like textures)."

[dave_]

dEVI said:

Ah, I though this was obvious, as I tried to imply at the end. You should have the 'monitor' buffer and two 'gfx' buffers.

You're still missing the point! How do you get this into this monitor buffer.
It still has to be transferred.

Edit: Ah yes, GhostManZero said it better.