Semi-fixed or Fully-fixed timestep?

Question

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?

Answer 1

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

Answer 2

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.