# How can I handle rendering on multiple monitors with differing refresh rates?

What's the best way to deal with a situation that may arise, where a user has two or more monitors with different resolutions and vertical sync intervals?

This would apply when a game has a fixed timestep, and is running in windowed mode: if one monitor has a frame rate of 60.056, and the other has a frame rate of 59.94, vertical sync will ultimately fail to do its job, if the game window is moved from the primary screen to another.

Temporal aliasing will also occur, as the timestep is not properly attuned to the other sync rate. How do games typically deal with this issue, if at all?

• What is -exactly- what you're trying to do? – Panda Pajama Nov 19 '13 at 2:04
• @PandaPajama I'm trying to allow the player to move the game window between screens smoothly so that A) no tearing occurs at any point and B) no frames are repeated at any point. I guess logic is independent from that, so I'll reduce the scope of my question to just rendering. – NmdMystery Nov 19 '13 at 2:10
• You will only get repeated frames if your game logic runs slower than your rendering code. At 60 logic fps, on 60.056 graphics fps, in average you will get one repeated frame every 18 seconds. This takes 0.017 seconds, and will most likely be unnoticeable. If you DEFINITELY MUST have no repeated frames, you can have your game logic at a much faster framerate. Say 200fps. You will waste a lot of processing and get lots of dropped frames, but you won't get repeated frames, which seems to be your purpose. – Panda Pajama Nov 19 '13 at 2:35
• This is of course valid for a world with discrete time steps, which encompasses the vast majority of game code. If you can consistently calculate the state of your game world for an arbitrary time n in less than O(n) complexity (optimally O(1)), then none of what I said applies. Interactive simulations don't tend to work like that though. – Panda Pajama Nov 19 '13 at 2:39

Game logic steps do not have to be synchronized with display logic, even if you're using a fixed timestep.

Consider a gameloop like:

var time_per_step = 1 / 60 -- for 60 -logic- steps per second
var prev_time = get_time() -- in seconds

while true do
var curr_time = get_time()
while prev_time < curr_time do
do_step()
prev_time = prev_time + time_per_step
// optional: curr_time = get_time()
end
draw()
end


It doesn't really matter how long your draw() calls take. As long as your do_step() takes less than time_per_step, your game logic won't fall behind.

• How about tearing? Is the solution to differing refresh rates up to the vendor, or is there an efficient way to render at the correct time on both screens without experiencing temporal aliasing on one of them? – NmdMystery Nov 18 '13 at 17:56
• This solution is compatible with vSync. I used 60 logical frame steps per second, but you can pump that up or down as much as you want. – Panda Pajama Nov 19 '13 at 0:08
• My point is that with this gameloop, your game logic will always be up to date with the real time clock. As such, if your drawing logic is not exactly in sync with the game logic, this algorithm will repeat or drop frames as needed in order to keep up with the real time clock. Whether this is acceptable or not is up to you to decide – Panda Pajama Nov 19 '13 at 0:59
• So I have to choose between repeated frames and tearing, essentially? No other alternatives? – NmdMystery Nov 19 '13 at 1:05
• Well, but that's by definition. If you want X logic frames per second on Y graphic frames per second, for X != Y, you're either going to have to make logic keep to graphics (repeated and dropped frames) or graphics keep to logic (tearing). The other alternative is force logic to run at graphics speed, which will lead to temporal aliasing. No rocket science here. – Panda Pajama Nov 19 '13 at 1:32