Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411283 Posts in 69325 Topics- by 58380 Members - Latest Member: bob1029

March 29, 2024, 12:17:06 AM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsDeveloperTechnical (Moderator: ThemsAllTook)Academic Papers on Game Loops ?
Pages: 1 [2]
Print
Author Topic: Academic Papers on Game Loops ?  (Read 2421 times)
qMopey
Level 6
*


View Profile WWW
« Reply #20 on: September 13, 2018, 11:48:35 AM »

Ah vsync. I don’t really know anything about vsync. What’s the point or general gist from your guys’ perspective? I thought screen tearing is sort of a non-issue due to drivers double buffering.
Logged
goob256
Level 2
**



View Profile WWW
« Reply #21 on: September 13, 2018, 03:03:57 PM »

My game supports a -vsync command line switch. If I run with vsync on (default) it looks really smooth, but my eye thinks there might be a doubled up update from time to time. If I run with vsync off, it runs at 500-1000 FPS and there is a lot of tearing going on so it looks bad. I think you'd have to check on various systems. This is on Ubuntu with Intel graphics, running GNOME so there is compositing enabled which might affect things.
Logged
LittleTwig
Level 0
**


View Profile
« Reply #22 on: September 13, 2018, 10:49:00 PM »

I thought screen tearing is sort of a non-issue due to drivers double buffering.

It's literally the opposite. Tearing is caused by the double buffer. It occurs when the buffer swap happens, while the monitor is in the middle of rendering. V-Sync waits until the monitor is done and then swaps the buffers.
Logged
Crimsontide
Level 5
*****


View Profile
« Reply #23 on: September 14, 2018, 06:24:28 AM »

Its not the double buffer that causes the tearing.

Ok, way back in the day when we had CRTs, you had to send the data in sync with where the electron gun was firing at.  If you got out of sync, you would have 1/2 the image from one frame and the other 1/2 from a different frame.  Obviously this would cause a discontinuity, known as tearing.  So to avoid this you would wait for the CRT vertical synchronization signal, where the electron beam would travel from the bottom right of the screen to the top left (it would be off during this time), and update the backbuffer in that short window of time.  Doing so would ensure no tearing.  But this was a short window of time, and rendering can take a while, so they introduced double buffering.  One buffer would be used as the frontbuffer (ie. the source of the data where the CRT was currently reading from), and a backbuffer to render to.  Then when rendering was done, a switch of the pointers would make the backbuffer the frontbuffer and vice-versa.  This 'flip' obviously had to be done during the vsync to avoid tearing.

This works great if you monitor refresh rate is in sync with rendering, but causes a problem if it does not.  If you finish a frame just after the vsync, you have to wait till the next vsync (might be a full frame in worst case) before you can start rendering again.  So to fix that we added triple buffering.  One buffer to render to, one to wait for the next vsync, one to be displayed.  This maximizes rendering time, the render never has to wait on vsync, and removes tearing.

The other problem with vsync is that if the rendering speed differs from the monitor refresh rate, you can get micro-stuttering otherwise known as frame jitter.  This is where adaptive synchronization comes in (gsync for nvidia, freesync for AMD).  When a frame is ready the video card sends it right away, no vsync at all (since modern LCDs don't need it).  So there's no tearing or jitter.  Its really the best of all the solutions.

Course in the absence of adaptive synchronization, the next best solution IMHO is just to use triple buffering and ensure you render faster than the monitor refresh rate.  Now in the pro/competitive scene is was common to turn off vsync.  This was mainly because most games tie input processing with rendering and simulation, and so the faster the game rendered, the less input latency you would have.  How much this actually buys you really depends on how the game loop is constructed.
Logged
LittleTwig
Level 0
**


View Profile
« Reply #24 on: September 14, 2018, 06:35:35 AM »

Single buffer caused flickering, which is different to tearing.

Single buffering results in flickering (where scan-out sends part of frame which is in the process of being rendered to the monitor), double buffering without waiting for vertical sync results in tearing (where scan-out switches from one complete frame to the next in the middle of a frame rather than between frames).
Logged
Crimsontide
Level 5
*****


View Profile
« Reply #25 on: September 14, 2018, 08:48:59 AM »

Single buffer caused flickering, which is different to tearing.

Single buffering results in flickering (where scan-out sends part of frame which is in the process of being rendered to the monitor), double buffering without waiting for vertical sync results in tearing (where scan-out switches from one complete frame to the next in the middle of a frame rather than between frames).

Regardless of what you want to call it.  The problem is not the number of buffers, the problem is updating the screen mid refresh.  Adding more buffers gets you more performance, at the cost of added latency.  You can have 1 buffer or 50 and you'll still get artifacts if you don't use vsync/adaptive sync.
Logged
LittleTwig
Level 0
**


View Profile
« Reply #26 on: September 14, 2018, 11:45:41 AM »

You are nitpicking for no reason..

Fact is that the double buffer wasn't introduced to remove the tearing. I mean you even agreed that the fix to tearing is vsync and not double buffers, so why are you arguing in the first place?

I merely corrected "I thought screen tearing is sort of a non-issue due to drivers double buffering."
« Last Edit: September 14, 2018, 02:07:26 PM by LittleTwig » Logged
Pages: 1 [2]
Print
Jump to:  

Theme orange-lt created by panic