Vsync is used to get rid of the screen tearing effect that occurs when the game updates the screen with a different rate than is the physical refresh rate of the monitor. So if you disable vsync the game may look smoother because the frame rate won't be clipped to the refresh rate of the monitor but you will get tearing, especially if the display changes a lot between frames. So you should have an option to disable/enable vsync in your game so that people who want maximum FPS will be able to disable it...

That's wrong Et.

If your monitor is running with a refresh rate of 60hz, the ideal game situtation is to run the game at 60fps, waiting for vsync. There is no better looking solution as frames always appear in whole, and always are evenly spaced. With vsync off you will see tearing. If FPS is higher than refresh the tearing gets worse if you see more than 2 frames in a refresh. If FPS is lower than refresh you get tearing without using vsync, and when using vsync you'll get unevenly spaced frames. Sometimes having a solid 30 fps rate (vsync timed) is better than having a 35 or 40 rate, because frames are evenly spaced. The next step is 15 fps, but 15 fps is so enough that it is worth having uneven frames to get 20 or 25 fps.

Yep using triple buffering allows you to generate frames as fast as possible without "wasting" time for vsync to complete. But it still makes sure that you don't render more frames than refreshes.

Ok, with double buffering, you are drawing to a buffer, and then fling the buffer to the screen. This removes flicker, because you don't see anything getting drawn. I think that ties into vsync. If you fling the buffer over to the screen in one big go, it's less likely you'll catch the screen at a "bad time" and form tearing...I think...thus it's better not to vsync, cause that'll just slow your prog up and accually cause uneven frame rates, since there is no way your prog will ever match the timing of vsync.

Also, you are limiting frame rates yourself, so if you were to vsync, you'd mess that up a bit, since your timing wont be equal to vsync's timing.

One last note for 3D games: If your game runs at 60fps without vsync, please don't vsync. It'll slow your game down(reducing the number of polys you can fling), and since you're already at 60fps, you aren't likely to cause tearing. If you're game is running higher than that, add more polys adn enjoy your no-vsync-ness

I should have extended that to say "but the monitor will only display one whole frame". BUT I figured

that covered for that little bit of misunderstanding... guess not.

Same for me - but the problem with vsync() for me is that it fscks up the screen update frequency... it stutters like hell whenever I try to use it, so I avoid it wherever possible and let my video card drivers worry about it instead. I usually add a command line option or similar for the people who want to use Allegro's vsync() though...

The ideal will be fps = refresh rate, but with high resolutions this can be hard to reach.

But more than this isn't interesting. It's because the video can't show all the frames, so you waste your cpu doing unnecessary memory copies and causing some unwanted effects.

The advantage of vsync() is that you don't need to use a timer, if your system is fast enough to blit the image. The program will run at constant speed (fps=refresh rate)

^__^

The reason it's worse is because not everyone's refresh rate is 60. On some systems, it could be 120 or so.

Timing by vsync is OK assuming you are using a system like the one I posted before that allowed for adaptive "dt" frame lengths between an interval. If you can lock your logic rate exactly to your FPS then you are being as efficient as possible.

Unfortunately when using the Allegro timer system, this is not possible, at least without emperical nature in the code -- having to guess the current FPS based on an average, and using that as dt.

If you can use a high-performance counter, then what you do is use vsync, and as long as your dt's are reasonable, then lock your game to vsync. When dt's become bad, you need to sleep (extremely high FPS) or frameskip (extremely low FPS). How high is high depends mostly on preference, and how low is low depeonds on how you've coded your game logic (usually it is your collision detection or integration method that drives this choice)

"allegro's" vsync is handled by the card where ever possible.. Otherwise, its a timer and some code.

I've noticed that when running one of my programs in Linux (Debian) that uses vsync to prevent shearing, there is a very visible shearing artifact which looks like a line between two frames (above the line is one frame and below the line is another). This line appears to be stable, but slowly moves up the screen, which means that the internal vsync timer is slightly faster than the monitor's actual refresh rate. The program has the ability to be configured so that waiting for vsync is turned off. When I turned it off, the shearing changed. It was now all over the place, but because it moved around, it wasn't as noticable than a line that stayed in almost the same place.

However, in Windows, vsync seems to work fine, and when I turn off vsync, the same thing happens when I turn it off in the Linux version (although I only tested the Linux version on one machine and I did not test the Windows version on that machne, so it may be the hardware and not Linux).

Apparently, some cards have the ability to generate an interrupt whenever the electron beam of the monitor reaches the end of the frame (the start of the "vertical blank"). Alas, not all cards suppport this, and as a substitute, a slightly inaccurate timer has to be used. Considering how long ago it has been since the days of 16-bit "home computers" such as the ST and Amiga (where vertical-blank interrupts were part of the hardware), it still amazes me to see that even today, there is no standardized way that works accross all graphics cards of preventing shearing on a PC. Vertical Blank Interrupts should have been supported as standard in all graphics cards ages ago.

AE.