// Time variables
double t = 0.0;
const double dt = 0.01;
double currentTime = SDL_GetTicks();
double accumulator = 0.0;

// Run until the user has requested a quit
while ( !quit )
{
double newTime = SDL_GetTicks();
double frameTime = newTime - currentTime;

if ( frameTime > 0.25 )
frameTime = 0.25;
currentTime = newTime;

accumulator += frameTime;

// Loop until we are ready to render, updating as we go
while ( accumulator >= dt )
{
update( dt );
t += dt;
accumulator -= dt;
}

// Get the time we use for interpolation
const double alpha = accumulator / dt;

// Interpolate the values
player.interpolate(alpha);

// Render the scene
renderScene();

}
return 0;
}

He is using fixed time steps (just look at JTippets post), which is a common way to avoid all the potential issues of just scaling everything by frame time.

Why? Think of throwing a rock and just updating velocity and position each frame. It would follow two very different paths on different machines. In a game it can make the different between throwing a grenade into a window or hitting the wall. Even the old X-Wing games had problems that led to fixed time steps. What happened? Because of issues like that, the "replay" of a mission would sometimes be completely different from what actually happened. Inconsistent time steps caused a missile to miss and suddenly there was a ship that should have been gone.

In short: update your physics in fixed steps and don't allow an arbitrarily large or tiny delta time. Unless you don't care about results being somewhat deterministic (which is often the case if your game is offline, non-competitive and has no replay function).

Of course it might seem like overkill for bomberman, considering there should be only simple and linear movement involved. Yet, it's probably better to get used to it on simple projects. Decouple physics and rendering. Generally there is absolutely no reason to run physics updates at maximum rate (ie. every single frame).

Trienco, did you look at his code? He may THINK he's doing fixed timesteps, but he's implemented it incorrectly.

#3: Fix your interpolation. You use “const double alpha = accumulator / dt;” If you were using floats, it should be, “const double alpha = accumulator;”.

It's not that his version is wrong. He is passing a relative percentage of one time step. The real problem I'm seeing is that the called function can only make sense of this value if it is aware of how long a time step is.

Point is: you can't say his alpha is wrong without knowing what his interpolate function is doing (at least "mathematically" a value between 0-1 actually does make more sense than an absolute time value).

I'm not sure where you see him capping the frame rate. He is capping the number of updates per frame,

which makes sense. If your game really stalls for such a long time, you don't want it to make a huge jump forward, taking an endless amount of time for the physics update and stuttering along for several frames until it finally caught up. The idea is that the game experience is ruined anyway, if a frame suddenly takes that long. Freezing and then continuing as normal is a much lesser evil than turning the game into a slide show and crashing the player into whatever he was headed for.

Besides: look at JTippets code. I don't think it's helping much if he does an implementation based on something a moderator posts and then having other people say "no, that's wrong" without going into any detail. That's just going to be confusing.

It doesn’t make sense, or it is somewhat subjective. I certainly would never take that route.

It causes the game to go into slow-motion which in itself causes problems, particularly for network games.