LÖVE

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.

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:

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?

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.

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?

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.