# Semi-fixed or Fully-fixed timestep?

I am making an iphone shmup and am trying to decide what type of game loop to use. I want to use either semi-fixed timestep or fully-fixed timestep.

With semi-fixed timestep I will make zero or more update(FIXED_INTERVAL) calls followed by one update(dt) call where dt <= FIXED_INTERVAL per game loop. As I understand it the drawbacks with this method are that my physics update(dt) logic is going to be more difficult to program because I basically have to assume a variable dt for every update. And then I've also heard that each run of my game will be slightly different due to floating point values not being the same every time.

Then with fully-fixed timestep I am making zero or more update(FIXED_INTERVAL) calls followed by one interpolation(dt/FIXED_INTERVAL) call where dt < FIXED_INTERVAL per game loop.

So it seems like the big decision I really have to make is: do I want to tackle the challenge of implementing an update(dt) with a variable dt or do I want to tackle the challenge of implementing interpolation?

Now from what I've read the majority of people are saying to use fully-fixed and do the interpolation. But when I think about implementing interpolation it seems like I'd be a lot more complex than an update(dt) with variable dt. This is because if I use interpolation I have to remember both the previous state and the current state. So if I want to use interpolation I have to come up with an additional layer of indirection that abstracts out entire individual game states. Whereas with semi-fixed timestep where I don't have to use interpolation I don't have to come up with a game state abstraction because there's always only one game state and it's simply the "global arrays" that represent my enemies, and enemy bullets etc.

So what's the more practical choice: do I implement it semi-fixed knowing that my physics updates could get complicated with the variable dt. Or do I use fully-fixed and try to come up with a game state abstraction so that I can keep track of previous state and current state in order to perform interpolation?

• Covered pretty thoroughly here: gamedev.stackexchange.com/questions/1589/… May 16, 2011 at 1:53
• I've read that discussion and the links there multiple times. It is actually how I've come to this post. My question mainly has to do with how to implement game states in order to achieve interpolation - which is not covered at all in that discussion.
– Ryan
May 16, 2011 at 2:13

Fully Fixed

You loose most of the benefits of a fixed timestep when you throw in a variable step once each frame.

Noel Lopis has a great write up on how he implemented a fixed time step in his game Casey's Contraptions. As bonus to you he is an iphone developer, though his technique is not iphone specific.

Some highlights from the article

• Use a time accumulator.
• Use 120Hz physics rate for a 60Hz frame rate.
• Simulate one fixed step into future and use left over time accumulation to lerp drawing code between current physics state and future physics state.
• various gotchas

What you refer to as "semi-fixed" and "fully-fixed" timestep are, in my mind, both fixed timestep -- the dt that you are passing to your update call doesn't change between frames.

So, your question is actually "do I want to implement interpolation for the purposes of rendering?" The answer is: probably not.

Interpolation is something you would only want to do if your fixed update timestep is markedly different to your target render timestep. It's not uncommon for games that have a strenuous update phase to only call update at, say, 10Hz, but render at full framerate.

Since you're writing an iPhone shmup, neither your update nor your render need be particularly CPU intensive; you can easily lock your framerate to 30Hz or 60Hz, not bother with implementation, and still have a smooth-looking game.

• I don't get it. You're saying I can lock the big dt that i'd compute in my game loop - that my physics consumes? How do I do that? Can I do it with CADisplayLink? I mean, what % of CPU are you assuming I'm using? Should you really assume locked game loop dt?
– Ryan
May 16, 2011 at 6:25
• What I'm saying really boils down to this: do the least complicated thing that would work. May 16, 2011 at 11:01
• Elaboration: using a variable dt for update and render is the simplest thing that would work, but generally avoided when using physics engines for the instability it causes. Therefore, calling update with a fixed dt, and rendering at the same rate (while dropping frames if your update runs long) is generally the simplest thing that would work. Writing code to interpolate objects between update calls adds complexity to your code; complexity that you're adding to solve no problem in particular. May 16, 2011 at 11:04