This is why delta time accumulator is preferred over using clocks, something like this would be best:
reply float accum = 0;
while (running) {
poll_input();
poll_network();
accum += delta_time;
while (accum >= tick_time) {
accum -= tick_time;
update_ui(tick_time);
update_anims(tick_time);
if (!paused) {
update_entities(tick_time);
}
}
render();
}the notion of using time directly in gamedev has always confused me; it feels like the correct answer should be to simply have a notion of turns, and a real-time game simply iterates over turns automatically. And then so many turns are executed per second
replyIt's a simulation; why should clock time be involved to begin with? The only things that should care about clock time are those that exist outside the sim, e.g audio
Simulation can proceed in logical time but animation is necessarily tied to wall clock time in order to be perceived as smooth and consistent by a human viewer.
replyIn that case, animation belongs to the same category as audio — it exists outside the simulation state.
replyBut I’m not 100% that’s even true; in the context of replay, I imagine it’d be more appropriately part of the sim for it to scrub properly.
In the context of networked games with client-side prediction, I think it’d probably be key frames tied to logical time and intermediate frames tied to wallclock
That's exactly how I do it. Makes the most sense to me.
replyThis gets bugged if it takes longer than one tick to run an iteration of game loop. Afaik the typical solution is to have a maximum number of iterations that you'll run and reset accum if it exceeds that.
reply