Page 3 of 4
Re: LÖVE framerate stutters?
Posted: Sun Oct 05, 2014 11:34 pm
by 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.
Re: LÖVE framerate stutters?
Posted: Mon Oct 06, 2014 3:06 am
by slime
Sapper wrote: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.
Re: LÖVE framerate stutters?
Posted: Mon Oct 06, 2014 4:38 am
by szensk
have you investigated if it's the garbage collector?
try 'collectgarbage(''stop")' at the start of your minimal test case.
Re: LÖVE framerate stutters?
Posted: Mon Oct 06, 2014 4:23 pm
by Sapper
slime wrote:Sapper wrote: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
)
Re: LÖVE framerate stutters?
Posted: Mon Oct 06, 2014 5:20 pm
by 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/
Re: LÖVE framerate stutters?
Posted: Mon Oct 06, 2014 5:40 pm
by bcolin
szensk wrote: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)
Re: LÖVE framerate stutters?
Posted: Mon Oct 06, 2014 5:54 pm
by Sapper
slime wrote: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)
Re: LÖVE framerate stutters?
Posted: Mon Oct 06, 2014 6:50 pm
by Robin
bcolin wrote:(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.
Re: LÖVE framerate stutters?
Posted: Mon Oct 06, 2014 9:04 pm
by 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.
Re: LÖVE framerate stutters?
Posted: Tue Oct 07, 2014 2:10 pm
by jjmafiae
Does this stutter occur elsewhere like in other games?