Space.TimeStepSettings.TimeStepDuration is how many time units pass in a single time step. It should be a small value. The Space.TimeStepSettings.TimeStepDuration defaults to 1/60f. Don't change it at that value unless there's a good reason to change it.
The thing is that I don't know too much about changing the time step (is there any code example?)
It's a settable property:
Code: Select all
Space.TimeStepSettings.TimeStepDuration = value;
I tried to create "space.TimeStepSettings.TimeStepDuration += 1 / 320" still with lag and "space.TimeStepSettings.TimeStepDuration += 1 / int.MaxValue - 1" with my objects teletransporting and disappearing
The value defaults to 1/60f, so adding 1/320f to it won't really do much. The resulting value is around 1/50.5f.
Adding "1 / int.MaxValue - 1" results in a value of -59/60f. Negative values are invalid; the engine cannot simulate backwards like that.
and I programmed this setting at every game's "Update(GameTime gameTime)" call. I don't remember now, but i tried that StepDuration value with one that I got my physics stucked, not working. I guess it was "+= 2". How should I really configure that correctly?
The TimeStepDuration should not be continually changed. It can be set once and left alone. Attempting to add 2 every frame will result in rapidly increasing time step durations. A time step duration of 2 is way too long for any simulation, let alone 4, 6, 8, ...
But again, unless you know there is a reason to adjust it, don't change the time step duration away from its default of 1/60f.
So, is there any suggestion for what I could do? I was creating the game until today and I'll pause a little until find for this problem a solution, otherwise my game won't run if only with 60 boxes it already slows down. Thanks for any reply.
60 kinematic objects is an extremely small simulation, even for a low-end phone. It should not be slowing down. There is likely something else going on. If you can replicate the simulation and slowdown in a BEPUphysicsDemos demo, I could give you more specific recommendations.
But here's some suggestions:
1) If Space.Update(dt) is called to advance the game simulation, keep in mind that it can do multiple time steps in one frame. This is called internal time stepping; it helps make the physics simulation independent of frame rate. Space.Update() without a parameter only performs one time step.
A common problem is Space.Update(dt) being called with elapsed milliseconds as the parameter. Almost always, the intended value is elapsed
seconds, which is a thousand times smaller. By passing in elapsed milliseconds rather than elapsed seconds, the simulation will attempt to simulate more time steps. There's a configurable per-frame time step maximum that stops it from doing the full requested thousand updates per frame, but it will still make the simulation take a lot of time.
It is unlikely that this fully explains the slowdown unless you are testing on a very low end device (1ghz single core phone or worse).
2) Some NaN's or infinities may be sneaking into the simulation. Depending on the form of corruption, these will not necessarily crash everything, but they will still massively slow down the simulation. Make sure all the inputs to the engine are valid.
3) Grab a profiler or implement your own timing code and measure where the time is being spent.