Physics bounce bug

[tentus]

This one is fun, could anyone confirm this for me?

Download my game, load up a level, and start moving the avatar. Now grab the window and move it a little, but take your time, maybe three seconds. Release the window, and observe that physics objects which were in motion change position, moving significantly upwards.

For me, this is a game-breaking bug, I can't have physics objects just being wherever they feel like. I'd love to know if this is restricted to my computers or what.

[Taehl]

Love pauses execution when the window is grabbed, but the timer keeps counting. What's happening is the delta-time is getting huge, so you have one love.update(dt) which makes the physics need to really, really strongly compensate.

Long story short: Prevent dt from getting too large. Like, the first line in love.update() could be dt = math.min(dt, .5).

[tentus]

Cool, that mostly fixed it. Thanks for the help!

[bartbes]

Love pauses execution[...]

Hah no, windows does.

[Jasoco]

Love pauses execution[...]

Hah no, windows does.

They all do.

In Linux it pauses when you drag the window.
In OS X it pauses if you press and hold the Close X or the Minimize button.
On Windows it does the same as Linux. (Pausing when the window is being dragged)

This was discussed elsewhere. In the thread with the game where you're in an office building running. It was discovered that "pausing" the game by exploiting the bug would allow you to have a high score because the level was basically skipped entirely for the time you held the button/window.

Apparently when this bug is exploited, Update and Draw stop executing, but since a lot of games rely on the game's love.timer.getTime() variable, it causes problems.

I suggested instead of referring to love.timer.getTime() you keep a separate gameTime variable in global space that gets added to in the update. Then refer to that instead.

This would go in love.update() after being declared in the love.load() function or root of the main.lua file. Anywhere that would make it global:

Code: Select all

gameTime = gameTime + dt

From then on, instead of referring to love.timer.getTime(), just refer to gameTime. Plus, you can just set gameTime to 0 when you start a new game or new level or whatever works for you.

Don't know how this would apply to physics modules though. So, do what Tahel does too just to be safe. Since Physics uses dt, you'll want to cap it (dt) off so it doesn't return anything too big.

[kikito]

Wasn't there a "the screen has been grabbed/released" callback? If they exist, it should be possible to use them to handle this dt situation a bit better.

[bartbes]

In Linux it pauses when you drag the window.

I'm pretty sure I can drag my windows without the game stopping.

I suggested instead of referring to love.timer.getTime() you keep a separate gameTime variable in global space that gets added to in the update. Then refer to that instead.

The thing is, dt gets absurdly high, so perhaps you're talking about something else after all?

Wasn't there a "the screen has been grabbed/released" callback? If they exist, it should be possible to use them to handle this dt situation a bit better.

Kinda hard for a callback to run when code execution has been paused.

[Jasoco]

In Linux it pauses when you drag the window.

I'm pretty sure I can drag my windows without the game stopping.

I suggested instead of referring to love.timer.getTime() you keep a separate gameTime variable in global space that gets added to in the update. Then refer to that instead.

The thing is, dt gets absurdly high, so perhaps you're talking about something else after all?

Well, dt is calculated by the time between frames and when the game gets "paused" like that, the frames stop so yes, the time gets high. That part of the post was referring to that other game. The second part of the post suggests Taehl's suggestion of also capping the dt to keep it from going over what it shouldn't. (Which for a 60FPS game should be something between .004 and .02 seconds give or take.)

So using both together should help prevent most problems. Though a callback would be nice to have too. You could set the game to paused (Actual paused based on how you handle a pause action) when you grab and unpaused when you let go providing there are two capturable events. (Grab and release) For instance, in my Adventure engine I use the "lost focus" callback to open the menu. i.e. I simply set all the same variables pressing Escape would do.

Funny, I never knew the bug existed until that other game (Sorry, I need to go learn its name, lol) came along and someone pointed it out.

And after a test with a fresh project, I discovered that when the game is "frozen" like this, the Run, Update and Draw functions don't fire at all. But since love.timer.getTime() is based on how many seconds since launch, which is basically Now_Time - Load_Time, and getDelta() is based on what getTime() is on the previous frame subtracted from the current one, and since the frames don't fire when frozen, of course dt will get too high.

For a 60FPS game, it's probably safe to cap it at 0.029 using math.min(0.029, dt).

[bartbes]

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

[tentus]

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

Eh, it's a faulty behavior. Even if it's unavoidable, it's a bug. Especially since it is somewhat avoidable by capping dt.