External factors breaking ingame things?

[Sarcose]

Hey guys. I've been noticing that when I drag the window of my game, it breaks the collision detection for my shitty little platformer, by causing the hero to fall through the floor. I assumed that would be something I could deal with as I learn more about what I'm doing. Then today I had Tiled open, and everything started getting really wonky -- collision wasn't running properly, and the player was stuttering all around as if velocity was being applied to it over and over (there is a redundant velocity application in that it uses a collider:move (in hardon collider) check to continually check for ground, as I haven't looked further into the library to find a better implementation). I was completely panicked until I realized that closing Tiled fixed the problem.

Any clues as to the possible source of either of these problems? I'll upload my project but I was hoping this was a common problem for newbie lovers considering the project started from a tutorial.

My code is spaghetti and I'm sure you will despise it if you try to look too far into it. The little version number commenting practice at the top is surely very cringe-worthy too. I have yet to learn version control and multiple source files.

[TurtleP]

One thing I do in my projects to prevent the first issue is:

Code: Select all

function love.update(dt)
 dt = math.min(1/60, dt)
 --other code
end

I've never used anything other than my own physics module so I probably can't help you with the tiled issue

[raingloom]

I'm having no problems running your demo on Linux (using i3 for window management). Scaling, translating or focus changes don't seem to affect physics.
I suspect that whatever your OS uses for window management disables rendering/updating when moving or resizing windows and when Löve gets to update it again, the delta time is huge, so your physics go crazy.
Try logging or graphing your fps and/or update delta time and see if there is a correlation between your problem and any lag.

[Nixola]

Windows locks LÖVE when moving the window, so that's your issue. As TurtleP, the only way to prevent this is limiting dt, although I'd limit it to 1/30 or 1/20 or something, to allow people to play at full speed even if they can't run the game at full FPS.

[Jasoco]

Agreed. It's the best way to make sure. Windows pauses the runtime when moving the window and OS X pauses it when pressing down on the X, _ and + buttons (But not when moving the window.) And I suspect both as well as Linux pause it when resizing.

Just limit dt and don't base anything important to timing on the running os.time or love.timer.getTime and instead have your own timer internally that bases itself on the passed dt. (Anecdote: A while ago someone created a Runner game that based its level length on the system timer, so if you held the mouse down on the titlebar/buttons to pause Löve's execution, you could beat any level by holding it down for a few seconds. Had it been based on an internal variable instead, that wouldn't happen.)

dt = math.min(1/15, dt)

(Where 15 is the minimum framerate you'd want. I think 15 is reasonable. Note that if the FPS actually goes below 15, then there'll be visual slowdown, but really, that's a worst case scenario.)

[Sarcose]

Thanks, guys. That's some really useful information to know, I appreciate it.