Physics bounce bug

[vrld]

It's a bug in your game.
Engine wise:

There is nothing we can do!

[Boolsheet]

Now I'm curious. How is time advancing a bug or faulty behavior?

Besides capping dt, it's also possible to update it in small steps.

Code: Select all

local limit = 0.1

function love.update(dt)
    while dt > 0 do
        updateFuncs(math.min(dt, limit))
        dt = dt - limit
    end
end

Checking and limiting dt is always a good idea.

[Taehl]

(Which for a 60FPS game should be something between .004 and .02 seconds give or take.)
[...]
For a 60FPS game, it's probably safe to cap it at 0.029 using math.min(0.029, dt).

I would advise not capping it that low, because then any time the game dips under the full 60 FPS, the game will essentially start running in slow-motion. People with systems less powerful than the developer's will always see the game in slow-motion! It's better to cap it at something higher than that.

[tentus]

It's a bug in your game.
Engine wise:

There is nothing we can do!

I'm being unclear, I'm sorry. I do not expect anyone to do anything, the onus of dealing with this clearly falls on the Lover, not the Love staff.

That said, if we define a bug as a defect in software, then this is still a bug, even if there is nothing to be done. Love will (unexpectedly) apply an upwards force when players do an action that was not expected, which happens to be setup-dependent. Since we can't anticipate this behavior in the player, it falls to the Lover to compensate for this behavior, even though the weirdness is coming from Love. That's fine, but I'd still say its a bug in Love.

We should cast this as a feature!

[Taehl]

Technically, the objects aren't just being shoved upward. What's happening is that the physics thinks that all the objects are moving down extremely fast (due to the cumulative force of gravity over a long period of time), and thus has to make them bounce off of the floors really hard.

I'm pretty sure that's how it works, at least.

[Jasoco]

(Which for a 60FPS game should be something between .004 and .02 seconds give or take.)
[...]
For a 60FPS game, it's probably safe to cap it at 0.029 using math.min(0.029, dt).

I would advise not capping it that low, because then any time the game dips under the full 60 FPS, the game will essentially start running in slow-motion. People with systems less powerful than the developer's will always see the game in slow-motion! It's better to cap it at something higher than that.

You know, you're right. What would you suggest capping it at?

Maybe you could use an if statement to detect if dt is greater than say .5 (Half a second) and then if so, just cap it to .025. It won't matter since the dt is never supposed to go that high anyway and the only time it would is when you drag the window. So it would be safe that way.

Make sure the if/then is before anything else code-wise. I'd actually just put it in love.run right after dt = love.timer.getDelta(). And then just make sure to never place any game timing relying code directly on getTime(), instead use what I suggested by just adding to a variable called gameTime.

[Taehl]

I, personally, like capping dt to 0.04 (dt = math.min(dt, 0.04)). That's a nice, simple number, and it works out to an even 25 FPS - if the framerate is lower than that, then things will start moving in slow-motion. However, I consider that just fine since 25 FPS is where things start to get choppy, and the slowdown is actually helpful.

[Jasoco]

I, personally, like capping dt to 0.04 (dt = math.min(dt, 0.04)). That's a nice, simple number, and it works out to an even 25 FPS - if the framerate is lower than that, then things will start moving in slow-motion. However, I consider that just fine since 25 FPS is where things start to get choppy, and the slowdown is actually helpful.

Yeah, good idea. I mean, even the NES had slowdown back in the day when too many enemies were on screen, and Löve is way faster than an NES.

[miko]

It is no bug!
There is nothing we can do!

Is it based on real time clock? If so, hibernating/suspending the OS (like when closing the laptop's lid) would also trigger this "bug" (or "undefined behaviour", I would say). Also, what happens if you change the system time (changing date/hour)?
So, it seems, it is risky to depend on system time.