const int UPDATES_PER_SECOND = 25;
const int TICKS_PER_SECOND = 1000; // GetTickCount() dictates 1000 ticks per second
const int TICKS_PER_UPDATE = TICKS_PER_SECOND / FRAMES_PER_SECOND;

So instead of SKIP_TICKS, we would just use TICKS_PER_UPDATE. This is clearer to me because I know what each number is measuring.

In the past I have used “FPS dependent on Constant Game Speed” (gameboy advanced 60fps) and “Game Speed dependent on Variable FPS” but I think now I want both to be variable! ie, a max display fps can be chosen and a max compute fps can be chosen (ie, 60fps display and 100fps if player accuracy is important). I think the source engine uses something like this (with compute capped to display) and that is the functionality I should aim for.

What would be the prospects of having several fps independant components? should I use semaphores and have the game objects independantly wait on results? – AI for example. or independantly different fps for input, ai, particles, physics, rendering? what could I expect from such an approach and how would I actually control such a thing?

thanks for the quick answer \(^o^)/.
Since i´m (not yet) at the point where i need a lot of physics operations, i
will leave my implementation as it is. But i like the idea of spreading!
I am updating my game state at 50fps now, and do rendering and collision detection as fast as possible. Works like a charm ^_^.
Can´t wait for your next article!

If your problem is purely a visual one (the rendering), then you should use collision prediction in your rendering, and interpolate accordingly.

There is one other solution though, but I haven’t yet written anything about it. If you use a physics engine, chance is that you need to do lots of iterations of that physics engine per update_game. What you can do is spread out those iterations while you render. For example if you need to do 20 physics iterations per update_game, you can spread those 20 iterations out while you render. This way your rendering can take advantage of more exact positions (provided by the physics engine), but your game still runs at the normal update_game rate. Hope this is a bit clear, or else I’ll see if I can write another article .

Great article, it helped me a lot to get some things straight for my game.
One question though..if i have very fast moving objects, how can i detect collision when checking only like 25 frames per second. It works when i do collision detection every loop (outside the update loop) and also using interpolation/prediction. But I really dont like this solution, because collision is now being checked for each time i render to the screen. Any suggestions?

Thanks in advance and sorry for my bad english (i´m german) ^^

the GetTickCount() is an example of a typical function which returns the number of ticks (usually milliseconds) since the app is running. In SDL for instance this would be SDL_GetTicks(). It is used to measure time within your application.