framerate Stutter with vsync (with possible solution?)

Questions about the LÖVE API, installing LÖVE and other support related questions go here.
Forum rules
Before you make a thread asking for help, read this.
Post Reply
immakinggames
Prole
Posts: 22
Joined: Sat Jun 01, 2013 4:40 am

framerate Stutter with vsync (with possible solution?)

Post by immakinggames » Wed Mar 25, 2015 12:26 pm

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?

User avatar
rmcode
Party member
Posts: 454
Joined: Tue Jul 15, 2014 12:04 pm
Location: Germany
Contact:

Re: framerate Stutter with vsync (with possible solution?)

Post by rmcode » Sat Mar 28, 2015 12:18 am

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
Prole
Posts: 22
Joined: Sat Jun 01, 2013 4:40 am

Re: framerate Stutter with vsync (with possible solution?)

Post by immakinggames » Sat Mar 28, 2015 1:46 pm

realtime online multiplayer with physics.

User avatar
T-Bone
Inner party member
Posts: 1492
Joined: Thu Jun 09, 2011 9:03 am

Re: framerate Stutter with vsync (with possible solution?)

Post by T-Bone » Sun Mar 29, 2015 9:45 pm

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.

Post Reply

Who is online

Users browsing this forum: No registered users and 78 guests