Hi all,
Fixed time step is used for physic update, is it better to do all using fixed time step ?
Is it better to do variable time step and have a fixed time step update function ?
Thanks for the help
Fixed-Time step only for physics ?
Did you read the classic "Fix Your Timestep!" article yet? If you still have questions after reading it, post again.
Physics: fixed (or variable if you know the framerates will always be within some reasonable range and your integrator is fairly good)
Rendering: variable (or fixed if you know you're always going to be vsync'ing and within the ms budget)
GUI: probably same rate as rendering, but could be fixed.
Game logic: Probably same rate as physics, but in some cases could be variable.
Typically, if you're trying to make something deterministic, it should probably be fixed.
If using fixed physics/logic and variable rendering, you'll probably need interpolation for the data that goes into the renderer.
I prefer using fixed time steps for everything except rendering, rendering is just interpolating between the most recent two time-steps.
the real time can vary a lot, sometimes you can have some multi-gpu system where you can push 4 frames into a queue in no time and then wait for 66ms to push another 4 frames, sometimes some hard disk or antivirus or even some DRM driver can stall your game for 500ms and then you go on with 10ms frames.
and everything beside linear motion behaves differently with just simple lerping, on the other side, complex interpolation is usually also just approximated and yet might take a lot of time while you might not need it with high framerates (so it might result in lower fps without any benefit).
and worst of all, you cannot test all special cases. imagin a monster that guards a path, now some players use a time-freeze tool to stall the cpu for 500ms and next frame he jumped past that guarding monster... or you test your physics puzzle on a nice and fast quadcore and it works, but some player has a dualcore low end cpu with an overpowered gpu and his your puzzle is a game breaker.
it's just a lot of head ache and wasteful to have a dynamic update for anything but rendering, but even for rendering you should try to average the frametime and even balance the frametime, a stable 30fps feels better than 60fps with jittering frames (e.g. due to multi gpu).
the real time can vary a lot, sometimes you can have some multi-gpu system where you can push 4 frames into a queue in no time and then wait for 66ms to push another 4 frames, sometimes some hard disk or antivirus or even some DRM driver can stall your game for 500ms and then you go on with 10ms frames.
and everything beside linear motion behaves differently with just simple lerping, on the other side, complex interpolation is usually also just approximated and yet might take a lot of time while you might not need it with high framerates (so it might result in lower fps without any benefit).
and worst of all, you cannot test all special cases. imagin a monster that guards a path, now some players use a time-freeze tool to stall the cpu for 500ms and next frame he jumped past that guarding monster... or you test your physics puzzle on a nice and fast quadcore and it works, but some player has a dualcore low end cpu with an overpowered gpu and his your puzzle is a game breaker.
it's just a lot of head ache and wasteful to have a dynamic update for anything but rendering, but even for rendering you should try to average the frametime and even balance the frametime, a stable 30fps feels better than 60fps with jittering frames (e.g. due to multi gpu).
Fixed-timestep everything is simple, classic, and best. Preferably synced to video refresh.
I've learned not to bother with variable timesteps or interpolation. It's a lot of complication for little/no benefit. If you can't quite keep up with 60 fps, you get stuttering. You can smooth it out by skipping a few renders, but if there's more than~30ms lag, let it freeze (unless it's network multiplayer). If it keeps happening it'll look jumpy, so drop your framerate or turn off some effects; 30 fps is better than 55 fps.
If input timing is crucial, you could run several physics updates per render frame, or if possible factor the input event timestamp into your calculations.
I agree with Hodgman. Keep in mind that this has nothing to do with if your game is single/multi threaded. This is only a way of saying: "Do a for loop in my game with the fixed step being the index of the array!". If your index is out of bound, you'll explode your array (simulation/logic in this case).
You can increment the index doing: CurrentArrayIndex += FixedTimeStep.
If you have to ask, and want a rule that just works without having to think too hard, then use a fixed timestep.
if you understand the underlying system, can figure out what problems and benefits you might get, then a variable timestep might be better. it will depend on the game and platform.
I use a variable step so that I always have an integer number of physics steps per render update - but that integer is adjusted to keep the physics step itself reasonable. I have no need for determinism, am confident that my simulation is well behaved for the range of timesteps that can occur, and as a result don't need to interpolate between physics frames (which can simplify debug output too). This is for my PicaSim flight simulator.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
