# Variable-step update() in game loop is falling behind, how can I get around this?

I'm working on a minimal game engine for my next game. I'm using the delta update method like shown:

void update(double delta) {
// Update code that uses delta goes here
}


I have a deep hierarchy of updatable objects, with a root updatable that contains several updatables, each of which contains more updatables, etc. Normally I'd just iterate through each of the root's children and update each one, which would then do the same for its children, and so on. However, passing a fixed value of delta to the root means that by the time the leaf updatables are reached, it's been longer since delta seconds that have elapsed. This is causing noticable desyncing in my game, and time synchronization is very important in my case (I'm working on a rhythm game).

Any ideas on how I should tackle this? I've considered using StopWatches and a global readable timer, but any advice would be helpful. I'm also open to moving to fixed timesteps as opposed to variable.

• Would be handy to know the language and platform here as I don't think this is a purely abstract problem. – Kylotan Jun 28 '11 at 23:18
• The time continuous is sampled in every iteration: this means that the time is "freezed", in "updating" sense , for the whole duration of your tree walking. This is proven to work for small intervals so the entire process have to be short. If you see someting going wrong probably the updating is taking too long. – FxIII Jun 29 '11 at 13:10

It's not clear why this should be a problem. If the delta is the time between updates, then it doesn't matter if it's called 1ms late providing it's consistently called 1ms late, which would appear to be the case. It's also not clear how you are observing that this is a problem given that presumably there is no visual output until the whole lot has returned.

It's also hard to imagine any time-based game that has an update() so slow that it takes even 1ms to update the object. What are you doing in these updates?

I would suspect that your delta calculations are simply wrong in some other way. Could you post a simplified main loop showing how you are obtaining this value?

I guess you have to have a fixed delta time for all your update scene class. It doesn't matter if the accual time is passed while you were processing previous nodes, but it's important that all your nodes move step forward with same measure.

in general you can update your scene using two different methods:

1. one is to have all objects in your scene to be in same time frame at the end of update call. It doesn't matter if they are updated 2 miliseconds or two hours, the only important thing is to have a snapshot of your game objects at specific time T. this way you can have show your gamestate, since in every picture all objects should be in same time. for example you can't imagine picture of a man being chased by a lion and say "hey that picture is wrong the man and lion are 2 seconds out of sync!"
2. you can update object in your scene asynchronized. I'm not much of an expert in this feild myself but I know there are some simulations based on async updates in different node. I've just seen this method once used and it was to optimize simulation speed in Connway’s Game of Life. it's called hashlife. but still to give user the simulation results the application would continue simulation untill all the cells reach some specific generation and then show the results.

Now back to your problem, I assume you have some problem with syncing audio and video in your game. As kylotan suggested there should be something wrong with your delta time calculator. then again I guess you can somehow predict how much you update call going to last (for example if you are running your game at 60fps, you may assume each game cycle last around 0.016 seconds) and just play music with that much difference with your accual game time.