Simulation breaks when dragging the window?

[Przemator]

Hi,

I have noticed that when using love.physics, when I click the window or drag it, the simulation breaks. I'm using Windows 7.

Below you may find a sample to test it. Just press the right arrow for the block to start moving.

Do you think it's a bug or am I doing something wrong? Is there a way to fix this?

Please note, that this "speed bug" also occurs in my game when running some other app in the background, then no mouse dragging is needed. It seems like when the CPU is split between LOVE and some other app, it messes up the physics code .

I have also raised a ticket in bitcuket:

https://bitbucket.org/rude/love/issue/4 ... ing-window

[qaisjp]

If you're using "dt", this is a bug.
If you're not using "dt", use "dt" for world:update(dt) and test again.

[Przemator]

If you're using "dt", this is a bug.
If you're not using "dt", use "dt" for world:update(dt) and test again.

Yep, I am using dt. I noticed many times how the "car" spontaneously loses half of the speed, especially at high speeds. This makes the game unplayable. Would be nice if you could test it yourself. Just fire the game, set the body to movement, then drag the window with the mouse, or just click the title bar.

[qaisjp]

If you're using "dt", this is a bug.
If you're not using "dt", use "dt" for world:update(dt) and test again.

Yep, I am using dt. I noticed many times how the "car" spontaneously loses half of the speed, especially at high speeds. This makes the game unplayable. Would be nice if you could test it yourself. Just fire the game, set the body to movement, then drag the window with the mouse, or just click the title bar.

I see, I go really really fast, drag the window and my speed gets depleted. Weird bug. Create some code to log the highest DT and check it.

[Przemator]

I see, I go really really fast, drag the window and my speed gets depleted. Weird bug. Create some code to log the highest DT and check it.

Hey, thanks for the suggestion. I made a csv log and wrote down the time, the dt and car position. I think I have nailed the bug, it is related to running world:update with non-typical dt values.

What happens is:
1. When the simulation runs normally, the dt is about 0.016-0.017 and all runs smooth.
2. When I grab the window, the game pauses execution, love.update is not being run.
3. When I release the window, the dt spikes to the amount of time I held the window (like 0.1 sec, 1 sec).
4. This is when the simulation breaks. The car speed drops dramatically in a single frame.

So I followed down that road and made two more simulations. This code:

Code: Select all

function love.update(dt)
	world:update(0.01)
end

makes the game run smoothly. When I grab the window, the simulation pauses, and resumes when I release it. This of course makes the simulation non-realtime, which is bad, but the speed is maintained.

So I figured, if this is what brakes the simulation, then I have to check what happens if I fire a high dt value:

Code: Select all

function love.update(dt)
	if love.keyboard.isDown("z") then dt2 = 0.1 else dt2 = dt end
	world:update(dt2)
end

Now, whenever I fire the Z key on the keyboard, it makes the car slowdown.

Conclusion? world:update(dt) is bugged when accepting higher dt values that usual, does not perform the correct simulation. I imagine that if I have a ball flying at constant speed, and I called world:update(5), this should result in 5 seconds passing in the world, without the ball changing it's speed.

I have to say I am pretty surprised that nobody raised this issue earlier, as dt spikes appear not only when you drag the window, but also when the CPU is busy, loaded, whenever there are frame skips.

I wonder if this can be fixed in the near future? As in my game objects travel at high speeds, the bug is VERY noticable and makes the game unplayable

[slime]

It's not really a bug - the main window/graphics thread will freeze in Windows when you move the window. Physics simulations cannot run consistently with a variable timestep between updates. You will need to use a fixed timestep for updating your world, by using an accumulator.

Example:

Code: Select all

local world_timestep = 1/60 -- update world at 60 fps
local world_dt = 0
function love.update(dt)
    world_dt = world_dt + dt
    while world_dt >= world_timestep do
        world:update(world_timestep)
        world_dt = world_dt - world_timestep
    end
end

[Przemator]

It's not really a bug - the main window/graphics thread will freeze in Windows when you move the window. Physics simulations cannot run consistently with a variable timestep between updates. You will need to use a fixed timestep for updating your world, by using an accumulator.

OK big thanks for your answer, Slime. In fact I already had this solution in mind as a form of "workaround". Unfortunately, nowhere did I find any info that I should not put dt inside world:update(). I think your function should be nested inside the world:update function by default. If I should not put variable values to world:update, then why does this function take a variable? I guess the timestep should be defined when creating a world then, and the the function run without the argument. Or, like I suggested before, nest your function inside.

[Puzzlem00n]

I had a similar problem long, long ago, although not with love.physics. Use slime's solution, definitely, but reading this may help you out (although, from your online status at the bottom, you might already be reading it): viewtopic.php?f=4&t=8740&p=53832

[qaisjp]

or set a max dt.

world:update( min(dt, 0.01))

[Przemator]

I had a similar problem long, long ago, although not with love.physics. Use slime's solution, definitely, but reading this may help you out (although, from your online status at the bottom, you might already be reading it): viewtopic.php?f=4&t=8740&p=53832

I think the online status refers to the whole forum, not the thread . Thanks for the link, I just read it. Regarding Slime's solution, I just applied it and there is one downside. From time to time (once in 10 seconds on average) the game get a bit choppy / laggy. When I removed the while loop and set world:update(1/60), everything runs smoothly. Of course, it will mean the simulation will pause in case of frame skips, but the lag is pretty bad with the while loop .

or set a max dt.

world:update( min(dt, 0.01))

I don't think this is a good solution. The trick is to send fixed dt to world:update(), because it breaks when you alter it.