LÖVE framerate stutters?

[Sapper]

TBH I wouldn't rely on vsync. Some GPU's,Operating systems or driver setups wont sync correctly. This gets especially bad with monitors that have strange refresh rates from what ive seen. I usually disable vsync. If your game is being a total resource hog with vsync off you can always modify love.run, either to sleep for longer periods of time or change to a fixed timestep.

[slime]

either to sleep for longer periods of time or change to a fixed timestep.

Well, the OS system call that love.timer.sleep uses is inherently inaccurate (on Windows in particular.)
Doing a proper fixed timestep requires a lot more code complexity than the default variable timestep.

[szensk]

have you investigated if it's the garbage collector?

try 'collectgarbage(''stop")' at the start of your minimal test case.

[Sapper]

either to sleep for longer periods of time or change to a fixed timestep.

Well, the OS system call that love.timer.sleep uses is inherently inaccurate (on Windows in particular.)
Doing a proper fixed timestep requires a lot more code complexity than the default variable timestep.

Fixed timesteps arent really that complex, especially if you keep it all in love.run.
Heres one I just made. Probably not the best / most accurate timestep but it seems to look and play pretty smooth.
Love.draw is only called after love.run, helps with making collision resolution look good + dramatically lowers RAM and
CPU usage on my awful old computer.
(im not sure what the overhead would be but if you make targetTime global then you can change gamespeed on-the-fly)

Code: Select all

function love.run()
    math.randomseed(os.time())
    math.random() math.random()
    if love.load then love.load(arg) end
    local targetTime = 1/50
    local nextUpdate = love.timer.getTime()
    while true do
        if love.event then
            love.event.pump()
            for e,a,b,c,d in love.event.poll() do
                if e == "quit" then
                    if not love.quit or not love.quit() then
                        if love.audio then
                            love.audio.stop()
                        end
                        return
                    end
                end
                love.handlers[e](a,b,c,d)
            end
        end
	local ctime = love.timer.getTime()
        if ctime > nextUpdate then
	    local xtra = ctime - nextUpdate
            love.update() 
            love.graphics.clear()
            love.graphics.origin()
            love.draw()
            love.graphics.present()
            nextUpdate = nextUpdate + targetTime + xtra
        end
        love.timer.sleep(0.001)
    end
end

(shameless self edit: worrying about the overhead for one global variable is silly )

[slime]

You can't actually have a true fixed-timestep draw function though. There are so many factors (many of them external to LÖVE) that affect whether a graphics frame will hit the mark, that it won't be reliable at all. You'll definitely want a variable-rate draw if you have a fixed-rate update, if you want everything to be smooth.

This is a good read: http://gafferongames.com/game-physics/f ... -timestep/

[bcolin]

have you investigated if it's the garbage collector?

try 'collectgarbage(''stop")' at the start of your minimal test case.

Great suggestion, thanks!
Things get weird ...

- Disabling the GC suppress the stutter on my own program! (But now it eat all the available RAM until being automatically killed, so I think something must be very wrong in my code - or maybe love doesn't like having the GC disabled)
- Disabling the GC does not suppress the stutter on the stuttertest (on machine with ATI card)
- I don't reproduce the stutter on my office computer (win8 x64 without ATI card, it has a poor built-in graphic card)

[Sapper]

You can't actually have a true fixed-timestep draw function though. There are so many factors (many of them external to LÖVE) that affect whether a graphics frame will hit the mark, that it won't be reliable at all. You'll definitely want a variable-rate draw if you have a fixed-rate update, if you want everything to be smooth.

This is a good read: http://gafferongames.com/game-physics/f ... -timestep/

Yeah i know, i guess its not really noticable when youre dealing with 320x240 resolutions
On most computers variable-framerate drawing seems really smooth, its just on all of mine that the framerate
bounces around from 45 to 64
sometimes i wish i was back in the NES era, where the framerate was always a steady 60fps(if you were an assembly wizard)

[Robin]

(But now it eat all the available RAM until being automatically killed, so I think something must be very wrong in my code - or maybe love doesn't like having the GC disabled)

That's completely normal, and doesn't have anything to do with your code or LÖVE: of course the garbage is going to heap up if you don't collect it!

If the garbage collector is what's causing the stuttering in your code, though, you probably create and discard too many resources (like calling love.something.newSomething() every frame.

[szensk]

Stopping the garbage collector stopped the stuttering? Keep it stopped and call collectgarbage("step", 1) each update. I'd test it myself but I'm at school.

But as Robin says, make sure you are not creating objects each frame. Especially something that you don't need to recreate each frame.

[jjmafiae]

Does this stutter occur elsewhere like in other games?