Simulation breaks when dragging the window?

[slime]

To clarify, you don't need a fixed dt for world updating to work, you just need a reasonably small and consistent one. As it gets larger, the simulation becomes less accurate.

hA6mN.png (3.52 KiB) Viewed 300 times

http://www.box2d.org/forum/viewtopic.ph ... 451#p33097

[Puzzlem00n]

I think the online status refers to the whole forum, not the thread .

Seriously? Well, that explains things.

Oh, and try this out if you'd like, bartbes gave me the idea long ago:

Code: Select all

function love.update(dt)
    local gdt = dt
    while gdt > 0 do
        world:update(math.min(maxframe, gdt))
        gdt = gdt - maxframe
    end
end

[Przemator]

To clarify, you don't need a fixed dt for world updating to work, you just need a reasonably small and consistent one. As it gets larger, the simulation becomes less accurate.

Slime, what you're showing is an example of a body with changing momentum. The bug I described affects even bodies moving at constant speed.

If theres a ball traveling at costant 30 m/s and we are using a constant world.update(0.01), everything will look OK. Then, if we insert a single update with a very large dt,like world.update(1), the speed of the body will change. I don't think this should happen. There are no collisions, no friction in my example. The body should not lose speed just by altering the update timeframe.

Please tell me if you agree. If not, then I should again say, that probably altering the dt between frames will influence the simulation.

[Boolsheet]

Welcome to the world of floating-point numbers and approximations. The Box2D engine has several limits to prevent the simulation from going out of control. One of those limits is the maximum movement per time step which is probably what you see here. If it only can go so far in one second, it obviously decreases the velocity.

I don't think that the default World update function should not be a wrapper for a fixed time-step enforcer. This can be very fragile and lock up LÖVE if the lover does not check for large values. I guess you could say that it should dismiss large values, but that seems to make the function unnecessarily complicated. I'd say the lover should have even more control by exposing the iteration counts.

The Box2D manual recommends to use a fixed time step in several places, this is not just a workaround.

[Przemator]

@Boolsheet: OK, I gave it a look and have found the place in Box2D manual where Catto says about the fixed time step .

Regarding the suggested solutions, I think both are flawed:

Code: Select all

function love.update(dt)
    local gdt = dt
    while gdt > 0 do
        world:update(math.min(maxframe, gdt))
        gdt = gdt - maxframe
    end
end

This is quite nice, although it does not guarantee a fixed time step. However, small variations probably won't break the simulation.

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

I used this function and my game started lagging badly. I think this might be caused by the fact, what the dt oscillates closely around the desired timestep, which makes some frames generate two world updates, and some zero. This makes the game switch between 30 and 60 FPS, which causes a laggy sensation.

I suppose this might help with the issue:

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 math.abs(world_dt - world_timestep) > world_timestep / 2 do -- run the loop if we are at least half a step behind
        world:update(world_timestep)
        world_dt = world_dt - world_timestep
    end
end

[Azhukar]

I've fixed dt spikes on window drag in my love.run function. That way you don't have to fix it in your update function.

viewtopic.php?f=4&t=11590&p=69780#p69780