Should I use DT with physics? (resolved)

Hey everyone,

I have a game where I set physics to framerate independent. I apply impulses without dt (as they are a one shot and dt doesn't matter). When I apply forces, I use dt (ex. Apply Force (Gravity*self.mass*dt at angle). I thought this is correct. According to the article written by Ashley on dt every behavior with the exception of physics has dt built in.

But, as it turns out, after running some tests, it seems to me dt is built in- contradicting the manual. If you use dt on forces, everything is messed up if you adjust timescale or have a drop or increase in frame rate.

Does anyone know if this is a bug of some kind or are you not supposed to use dt when applying forces?

----------------------------------------------------------------------------------------------

CONCLUSION:

Do not use dt when applying forces. (using dt on an impulse basically turns it into a force)

dt is applied internally during the physics update when using stepping mode: frame rate independent.

If you are using the default stepping mode then the physics updates once per frame and assumes 60 frames per second. If you are running only 40 FPS then your game will appear to be in slower motion than on a 60fps machine.

----------------------------------------------------------------------------------------------

Physics is Box2D and is not part of the C2 internal systems. Box2D has it's own timestep system.

Physics is Box2D and is not part of the C2 internal systems. Box2D has it's own timestep system.

jayderyu - So, Does this mean I shouldn't use dt when applying forces, torques etc?

Ashley ? could you help me out with this one? Do I use dt with physics? And... can I force a max frame rate. Why would my computer cap the fps to 40 most of the time but cap at 60 the other times. Can I set that cap manually?

From the manual

Physics Actions

Set stepping mode

Choose whether the Physics time step uses dt (delta time, for Framerate independent) or a fixed value. By default it uses a fixed time step to eliminate any randomness or instability coming from dt, ensuring simulations are exactly reproducible every time. Set to Framerate independent to adjust the time step according to the framerate, which can cause the same simulation to have different results if run twice. Note even when in this mode, the behavior clamps the maximum time step to 1/30 (about 33ms, equivalent to 30 FPS) to prevent the instability that can result from large time steps. For more information see Delta-time and framerate independence.

From the manual

Physics Actions

Set stepping mode

Choose whether the Physics time step uses dt (delta time, for Framerate independent) or a fixed value. By default it uses a fixed time step to eliminate any randomness or instability coming from dt, ensuring simulations are exactly reproducible every time. Set to Framerate independent to adjust the time step according to the framerate, which can cause the same simulation to have different results if run twice. Note even when in this mode, the behavior clamps the maximum time step to 1/30 (about 33ms, equivalent to 30 FPS) to prevent the instability that can result from large time steps. For more information see Delta-time and framerate independence.

Thanks, but if you read my post you would know I had read the manual. dt does not work as expected when used in a time-frame independent way. This means the manual is either right and I found a bug, or the manual is wrong and does not reflect how things are actually working. Either way it probably needs Ashley's attention. I cannot actually conduct a meaningful scientific experiment without being able to control max framerate and nobody has been able to tell me if that is possible.

I quoted the manual to show that using dt within physics will have the opposite effect as using dt in other circumstances..

Using dt has the disadvantage when using physics that the same actions can give different results..

Exactly like what you said in your first post..

The fixed timerate that is build in in the physics behaviour makes the result predictable..

So using dt with physics will probably have the opposite effect you are aiming for, just like it says in the manual..

I couldn't explain it better myself, still can't, but if you'd rather read my words than the manual, there you have it..

LittleStain -Small variations occur when using dt (Like really, really small). In a physics simulation puzzle game this small fluctuation in dt can produce a chain of events that compounds to produce a drastically different result than was acquired last time the exact same thing was done. In these types of games, using time frame independent physics doesn't make sense.

dt is calculated based on how long the last frame took. The current frame might not take that long - but in the end it averages out to 1 every second. The variation from frame to frame could yield results that vary, but we are talking minute fractions of 0.02 (depending on framerate). In reference to the above situation, this could be undesirable. But in a game such as asteroids with physics, this variation in dt is largely irrelevant. As far as the game goes and feels everything is still "predictable".

My tests involve a simulated force of gravity acting on an object and an impulse based jump. The degree of variation in using dt in time-frame independent physics in my test is relative to what dt is and not a small difference. In other words, as the framerate increase, the force of gravity acting on the object increases over time. As frame rate drops, the force of gravity lessons over time. This indicates that dt is already applied to the physics internally and needs not be applied again. If you cut frame rate in half, gravity decrease by half.

When running framerate dependent physics, frame rate only affects our perception of time passing but doesn't affect the actual game. If you apply dt to this model of physics you can get the same result as was described above, though "time" to reach max height after impulse was different, the height was still the same. I used impulse vs force to be able to compare maximum height obtained when applying a force in the opposite direction. I did this to take "human perception of what is happening" out of my experiment.

If you remove dt from timeframe independent physics calculations within the event sheet, you get the expected results; that is, regardless of framerate, the object reaches the same "highest point" in the same "real time" after leaving the ground under an impulse and affected everytick by a constant force.

This is in CONTRAST to what the manual states, indicating either an error in the manual, or an error in the implementation of physics in construct. My hunch is that the manual should be changed to reflect the actual state of box2d in construct.

....and by the way, just for clarification... I have worked with box2d outside of construct2 in other applications (XNA in C#, Unity in C#, Torque C++) and I have also read most of the box2d manual and understand the API in addition to reading a lot of the source code and understanding the theory behind collision detection in box2d. I have rolled my own collision detection before. Don't think I am speaking out of ignorance. I posed this problem as a question because I believe Ashley is a very competent programmer (and a wizard) and I looked for input and guidance before outright saying I found a discontinuity between Box2d/Construct2internal/Construct2 Manual in case I am wrong/confused. The more time passes and the more I tinker with this the more I believe that If Ashley says to use dt in events with timeframe independent physics then there is a "bug"; If he says not to use dt then the manual needs to be updated for clarification.

I would find it odd that I am the first to find this problem but it seems that may be. In any case it is really difficult to test due to lack of frame rate control. I had to spam thousands of objects in order to get a drop in framerate to test changes.

Also I may have found a bug in timescale and physics (when timescale is 0, force is still applied everytick in a building manner, such that when timescale becomes greater than 0 all the force added to the object over the last frames is added all at once in one frame... but I need to run further tests.