Use vsync event instead of a 16ms timer?

Question

I found that in game development, most people set a timer that gets triggered every 16ms to do the rendering.

As an Android programmer, I'm familiar with the Choreographer. You set a callback that will do the drawing stuff, and each time vsync happens, the callback is called.

I know the original use of vsync is to prevent modifying the buffer when the front buffer and the back buffer are being switched. But don't you think making the drawing/render code have the same period as the actual screen refresh rate (in an ideal situation) is better?

So is there any reason why people don't prefer the vsync callback or vsync event based design?

One reason I can come up with is that if a monitor is 75Hz, it will be too high-frequency to do the rendering, right?

Answer 1

There are various reasons not to use the vsync event nowadays.

Indeed, historically when the games had to sync with the refreshrate of the screen because the ‘redraw’ would be visible or cause a flickering screen. At the vsync/vblank interrupt the game would switch between two memory buffers to prevent this.

A few reasons not to use the vsync:

Physics engines like a fixed timestep. In order to keep up with everything happening, games are often designed with a fixed physics timestep in mind: 60 or 30 physics frames per second. This is independent of the vsync and makes the physics engine happy. See also fix your timestep for more insight in this.

system capabilities dictate the gamespeed Many modern games have complex subsystems and complex graphics. Often the framerate is dictated by the system capabilities. If the system (CPU and GPU) can keep up, the game experience becomes smoother. These framerates are independent of the refreshrates. This is the variable timestep.

Graphic cards can take care of vsync artifacts Many graphic cards have technology onboard to cope with the need for vsync artefacts (for example Nvidia has ‘adaptive vsync’). This allows modern games to try and pump out as many frames as they wish without worry.

Designed performance Often games are simply designed with a framerate in mind. On consoles you often see 30fps or 60fps fixed timesteps. This helps game designers to determine how much scenary or gameplay elements they can have to meet their vision. This means they know everyone playing the game has the same experience and know exactly where the limits of their game engine is.

There may be more but these I can think of right now.

Note that there may be combinations of the above- having a game fixed at 30fps may still mean that you keep track of variable timesteps because something may cause unexpected slowdown. Another common option is to have fixed timesteps for physics simulation and variable timesteps for graphics.

Finally some systems still use the vsync to time the timesteps. It is still a viable method if you can guarantee your game can cope with the required updates/or the system simply dictates that method. Your Android reference is a good example and a valid method.