Page 1 of 1

Substeps and performance: game logic in tick callback.

Posted: Tue Dec 23, 2014 1:56 pm
by Goran
Given a call like stepSimulation(delta, 7), where delta is 1/60f, I assume that there would be only one substep, and if I'm running my game logic in the simulation tick callback, that logic would only run once for this frame.

However, if I start doing something fairly expensive in my game logic, and the frame rate drops as a result, that delta would be higher on the next frame, and bullet would run multiple substeps on the next frame, which would in turn execute that expensive game logic more than once per frame, which would lower the frame rate, which would run more substeps, and so on, until I pass over maxSubSteps, at which point I start loosing time.

Is that correct?

Re: Substeps and performance: game logic in tick callback.

Posted: Tue Dec 23, 2014 2:36 pm
by c6burns
Yes.

Re: Substeps and performance: game logic in tick callback.

Posted: Tue Dec 23, 2014 7:35 pm
by lunkhound
The spiral of death. Kind of a big problem with the fixed-size time steps approach.

I've used variable time steps to avoid this on past projects. You can't let the steps get too big though, or things tend to blow up.

Re: Substeps and performance: game logic in tick callback.

Posted: Wed Dec 24, 2014 1:36 am
by Basroil
You can also try to split your logic depending on temporal resolution needed. For example, AI pathfinding can usually be updated as slow as 1Hz without issues (assuming walking/running speeds), while interaction events and animations usually need to be per graphics frame or else things seem sluggish.

Re: Substeps and performance: game logic in tick callback.

Posted: Wed Dec 24, 2014 9:33 am
by Goran
lunkhound wrote:The spiral of death. Kind of a big problem with the fixed-size time steps approach.

I've used variable time steps to avoid this on past projects. You can't let the steps get too big though, or things tend to blow up.
Yea, I think I'll follow the same path.

Thanks everyone!