About setting custom "dt"

[misterspok]

I used search, and here I am

I use (for the time being) love.update(dt) function to run my custom physics. But it appears that "dt" in LOVE is not nearly a constant.
As far as my physics require precise delta-time setting (not ever-changing dt LOVE gives us) to run calculations, I have a question:

Is there ANY way to set my own constant delta-time?

As you may know, many dynamic physics calculations use Time. So I decided to use dt in my calculations, so I can update parameters in tiny instants of time, like 0.001 sec. But if you get delta-t values to change sporadically (difference between 0.001 and 0.002 is 100%!) all your math will collapse.

[micha]

You cannot directly control the frame rate. But you can ignore the framerate

Code: Select all

function love.update(dt)
dt = 1/60
[...]
end

However, I don't recommend that.

Can you specify, what you mean by "all your math will collapse"?

[qaisjp]

Basically he wants replays to be the same, so that if he does maths on whatever it won't be affected by using *dt.
i think? or maybe preventing large changes in delta time.

[Robin]

What you can do is this:

Code: Select all

function love.load()
    time_left = 0
    epsilon = 0.01 -- something suitably small, I dunno
    -- do other stuff
end

function love.update(dt)
    time_left = time_left + dt
    while time_left > epsilon do
        do_physics_update(epsilon)
        time_left = time_left - epsilon
    end
    -- do other stuff
end

[Davidobot]

You can use custom-dts for Bullet Time! As long as everything is dependent on DT you can do this:

Code: Select all

dt = dt/2 --Slows it down

or

Code: Select all

dt = dt*2 --Speeds it up

[misterspok]

Can you specify, what you mean by "all your math will collapse"?

Sure I can. Delta-V, that is calculated for the spacecraft, depends on propellant mass loss that craft uses to bun. Basically, it is the Tsiolkovsky's equation. To calculate maximum mass loss for given engine thrust I need delta-time (dt). So, as you can see, if dt varies between, say, 0.001 and 0.002, it means that during burn time engine thrust will sporadically increase/decrease TWICE the value.

If you add here a gravitational influence, to calculate how it changes the vertical speed of the craft you also need dt.

Sure, I can stop using dt, but how will I make physics calculations to correspond to what is going on on the screen then?

What you can do is this:
...

Yes, Robin, I see your point. Some elegant solution here But will it not lay an unwanted crapload of math on CPU, and thus continously drop framerate?

You cannot directly control the frame rate. But you can ignore the framerate

Code: Select all

function love.update(dt)
dt = 1/60
[...]
end

However, I don't recommend that.

Ignore the frame rate? That is interesting. But why would you not recommend that? I must try it and see

Edit Nope, the more the difference between dt I set and real dt, the more faulty math gets. Maybe I should forfeit the use of love.update function?

[qaisjp]

If you don't use love.update what can you use...?

[T-Bone]

Robin's solution is excellent. It's not that demanding on the CPU either. I'm not sure there can exist a better solution than that. Attempting to freeze the framerate is a significantly worse solution as it would slow down gameplay if the computer isn't fast enough (whereas Robin's solution simply makes the game laggier, not slower, and keeps the correct physics simulation).

I'm also curious why you would need to repeat the same simulation twice with exactly identical results.

[misterspok]

I'm also curious why you would need to repeat the same simulation twice with exactly identical results.

Well, the result is not identical! The timescale required to be identical. The result you get is continously updated vertical and horizontal velosities (pardon me, radial and tangential would be more accurate), altitude and distance. Also, during the burn, propellant mass will decrease, causing reactive acceleration to increase. That is why I need to repeat the same simulation continously, if I understood your question right.

Though I will try Robin's solution and report here as soon as I can.

Edit: Well, Robin's solution seem to work damn fine to me I got some legit results now. Now I just regret that I don't have enough programming skill yet to figure it out by myself Thank you.

[OmarShehata]

I'm also curious why you would need to repeat the same simulation twice with exactly identical results.

That's actually a pretty important thing, and it's why Box2d was written to be deterministic.



(pulled from the Box2d FAQ)

There's a lot of reasons to want the same input to give you the same output. Imagine you're designing a puzzle game. You've hand crafted an elaborate solution. Now the worst thing would be if the player could solve it just by repeating the same thing enough times until it happens to work. Besides, you usually want the simulation to play out for every player the way you designed it, so it wouldn't go off in any erroneous way.