framerate Stutter with vsync (with possible solution?)

[immakinggames]

So I've noticed that even the simplest of projects run into micro stutter (fullscreen and windowed) when vsync is on with my Windows 8 machine. I've tested projects with FRAPS to confirm this is a real issue and not something wonky with getFPS or anything.

Unfortunately this is a big problem for me because my project MUST have a fixed timestep and forcing off vsync seems like a messy solution to this problem.

Something I am looking into is Retroarch which uses SDL2 as well and runs at a consistent 60fps with my FRAPS test. I'm not particularly well versed in this area, but if Retroarch can avoid stutter on a win8 machine with SDL2, can't we also? Is this possibly unavoidable with Lua?

[rmcode]

I don't think Lua plays a role in the whole vsync deal. If it really is an issue with SDL you could report it.

Just out of curiosity: Why does your game need to have a fixed timestep?

[immakinggames]

realtime online multiplayer with physics.

[T-Bone]

Doesn't sound like you need a fixed timestep to me. There's no way you can guarantee it, even if vsync worked for you. For example, some computer might have poor drivers, not having vsync support at all. Other computers might have their displays set to different refresh rates. And other computers may be too weak to keep up the desired framerate.

I think the solution you really want is to only run the sensitive code every 1/60 second (for example). It could look something like this (untested):

Code: Select all

function love.load()
    time = 0
end

function love.update(dt)
    time = time + dt
    while time > 1/60
        time = time - 1/60
        -- do time sensitive code here
    end
end

function love.draw()
    -- draw stuff at whatever framerate the computer can handle, vsync or not
end

Something like this will do its best to run the sensitive code at 60 FPS, and in case the computer is weak, the relatively slow drawing step will run less often in relation to the sensitive code, which will run multiple times per cycle in an attempt to keep up. And in case you're drawing faster than 60 FPS, the sensitive code still only runs 60 times per second.

This is also just one solution. The optimal solution for you will depend on exactly what your sensitive code is. If your sensitive code is computationally heavy, you could put it in a thread of its own and use love.timer to make sure it runs close to a desired framerate. Then, the "main thread" can be used only to create a UI that's as responsive as possible on whatever computer it runs on.

Finally, I want to mention that my old Ubuntu box could under no circumstances handle vsync; it caused massive lag on everything if any window had vsync on. An option to disable vsync is therefore always a good idea for any "serious" game.