DT and Dropping Frames

General discussion about LÖVE, Lua, game development, puns, and unicorns.
Post Reply
User avatar
dizzykiwi3
Citizen
Posts: 54
Joined: Tue Jan 14, 2014 2:03 am

DT and Dropping Frames

Post by dizzykiwi3 » Fri Sep 22, 2017 5:19 am

Hello all

I recently released a game of mine, and it has been great! However, someone who did a youtube let's play of it ran into an issue. In their words:

"I recommend looking into enabling a "frame-skip" option for your game, otherwise anybody capturing your game at 30fps is going to run into the same slow down that we experienced during the video...I've been told in the past it's a very simple thing to enable, and ensures the game looks great in anyone's video, regardless of the framerate they capture at."

I made the foolish foolish mistake of not considering dt when I developed the game. Vsync was always on and I assumed everyone would be playing at 60fps.

So I have some options I'm weighing.

1. Firstly, is the 30fps capture software really the issue? I'm hesitant to believe it's the capture software as in the video the game wasn't locked consistently slow, it would just dip into pockets of being slow. So can the issue be solved by simply reducing the number of particles on screen for instance? To just make the game run faster? Or to include lower graphics quality settings?

2. If not, should I attempt to incorporate dt into every timer and variable change in my code? or

3. Should I attempt a frame skip as mentioned here. Would that solve the issue they mentioned?

Any help would be much appreciated! Apologies if my wording was unclear or off.

User avatar
ivan
Party member
Posts: 1530
Joined: Fri Mar 07, 2008 1:39 pm
Contact:

Re: DT and Dropping Frames

Post by ivan » Fri Sep 22, 2017 5:58 am

1.Generally you don't want to have any slowdown, especially for games where timing is important.
The point is that the gameplay and timing should be the same regardless of how fast your computer is.
2.Using variable DT is less CPU intensive, but Box2D (love.physics) should be updated using a constant interval.
Inny's example is correct:

Code: Select all

accum = 0
interval = 1/60
maxframeskip = 10
function love.update(dt)
  accum = math.min(accum + dt, interval*maxframeskip)
  while accum > interval do
    accum = accum - interval
    -- update
  end
end

User avatar
dizzykiwi3
Citizen
Posts: 54
Joined: Tue Jan 14, 2014 2:03 am

Re: DT and Dropping Frames

Post by dizzykiwi3 » Fri Sep 22, 2017 9:59 pm

ivan wrote:
Fri Sep 22, 2017 5:58 am
1.Generally you don't want to have any slowdown, especially for games where timing is important.
The point is that the gameplay and timing should be the same regardless of how fast your computer is.
2.Using variable DT is less CPU intensive, but Box2D (love.physics) should be updated using a constant interval.
Inny's example is correct:

Code: Select all

accum = 0
interval = 1/60
maxframeskip = 10
function love.update(dt)
  accum = math.min(accum + dt, interval*maxframeskip)
  while accum > interval do
    accum = accum - interval
    -- update
  end
end
When doing inny's method, I turned off vsync and noticed a stuttering. Is this method not going to be as smooth as with vsync on or is that an issue with my code?

User avatar
ivan
Party member
Posts: 1530
Joined: Fri Mar 07, 2008 1:39 pm
Contact:

Re: DT and Dropping Frames

Post by ivan » Sat Sep 23, 2017 8:22 am

Small correction, it should be "while accum >= interval"
Out of the box, this method is less smooth than using variable dt.
It is more stable though if you plan to use love.physics.
You can play around with the interval variable: interval = 1/targetfps
So if any frame takes longer than 1/targetfps there will be stuttering and dropped frames.
To play nice with vsync make sure to prevent overdraw due to dt<interval. In short - you dont need to redraw unless you have taken at least 1 update step. Just store the step/tick number when you draw so that you dont redraw the same frame twice.

Code: Select all

targetfps = 60
accum = 0
interval = 1/targetfps 
maxframeskip = 10
frame = 0
function love.update(dt)
  accum = math.min(accum + dt, interval*maxframeskip)
  while accum >= interval do
    accum = accum - interval
    frame = frame + 1
    -- update
  end
end

lastdrawn = 0
function love.draw()
  if lastdrawn == frame then
    return
  end
  lastdrawn = frame
  -- draw, possibly using linear interpolation:
  -- lerp = accum/interval
end

User avatar
dizzykiwi3
Citizen
Posts: 54
Joined: Tue Jan 14, 2014 2:03 am

Re: DT and Dropping Frames

Post by dizzykiwi3 » Sun Sep 24, 2017 3:38 am

ivan wrote:
Sat Sep 23, 2017 8:22 am

To play nice with vsync make sure to prevent overdraw due to dt<interval. In short - you dont need to redraw unless you have taken at least 1 update step. Just store the step/tick number when you draw so that you dont redraw the same frame twice.
Doesn't returning from love.draw just cause it to draw nothing though, rather than draw the same frame?

User avatar
ivan
Party member
Posts: 1530
Joined: Fri Mar 07, 2008 1:39 pm
Contact:

Re: DT and Dropping Frames

Post by ivan » Sun Sep 24, 2017 5:37 am

dizzykiwi3 wrote:
Sun Sep 24, 2017 3:38 am
Doesn't returning from love.draw just cause it to draw nothing though, rather than draw the same frame?
Yep, you're probably right. To be honest I don't really use love2d that much,
but the technique should still work if you render the frame to canvas.

Post Reply

Who is online

Users browsing this forum: No registered users and 4 guests