Ideally, your game logic should not even be aware that there is rendering going on - let alone take into account the rendering of frames! Determine, for all objects in your game, the next time they should be updated, and once that time is reached, update them.

while( game_running() ) {  while( next_update_time() < time() ) update();  if( render_required() ) render();  else sleep();}

EDIT: for instance, for 30Hz, update() will increase next_update_time() by 33ms every time it is called.

On the other hand, your rendering system is aware that updates are going on, and you can always take into account the time since the last update happened to interpolate values using the velocity and position of objects. But this will only affect the position of rendered objects, and has absolutely no impact whatsoever on the actual positions of objects.

Hi, this might help:

frequency = 50; //50 Frames Per Second for example

long timelastcall = getTickCount() //get current time

while(!GAME_OVER)
{
if((getTickCount()-timelastcall) > 1000/frequency)
//1 second = 1000 milliseconds
{
game_logic();
timelastcall = getTickCount();
}
presentation();
}

This loop performs game logic updates at a rate of 50 times per second.
Then performs as much rendering as possible.


I'm wondering does any1 know how accurate the - ctime clock() function is for
timing game loops, thanks!

Yeah, your right, the loop would render the same frame multiple times, you could place a sleep in the loop if you didn't want to render the same scene multiple times.

The renderer is called as often as possible, but the game logic is updated based on a frequency. This means that your game will run the same speed regardless of the system its run on.

The advantage? Not that I've used it but you can use a percentage parameter to the renderer fuction that will allow you to specify what percentage of the current update's rendering is complete. This will allow you to perform fine interpolation so not all the frames in a given update look alike.

I'm a relative newbie too, im getting this info from a book- Core Techniques & Algorithms In Game Programming, its pretty good.

Main Loop with Fixed Time Steps - nice IMHO
I'm using a simple

I got the impression that ToohrVyk was talking about threads, ie letting the renderer or the updator running in it's own thread. If not then that's another idea that I know people (atleast some) have used ;)

Nope, you're pretty close to the mark, moleary.

As it turns out, there are about two distinct categories that modern game logic timing, or game state updating as I like to call it, falls under: fixed update with variable render, and variable update with variable render. (There is also fixed update with fixed render, but that breaks down in your initial scenario when the processor can't keep up with the timer. Definitely not an option -- usually never is). It's practically imperative that you separate your game state updating from your rendering -- i.e., the game state updating handles everything in your game world, usually checking user input and updating positions and animation frames as necessary, and the renderer just throwing all the polygons and pixels at the screen.

Fixed update with variable render can be implemented in several ways. ToohrVyk's method is an example of this: as long as game state updates are needed (next_update_time is less than the current time, or "we've fallen behind"), it performs them; otherwise, it renders. This method only fails if the time for the game state update is longer than your target update rate, but this is almost never the case and can be compensated for. Another way that the fixed update / variable render method can be accomplished is by setting a callback timer in another thread that calls a function you create every x milliseconds. This function increments an update counter variable that says "we need to update the game state x times". (In most cases you want this counter to be 0 or 1, but during heavy render it can grow). Then in the main loop, you have a sub-loop that updates the game state and decrements the counter each time until it reaches 0. The effect of this is the same as with ToohrVyk's.
The advantage of fixed update with variable render is that you can leave your objects' update methods the way they are, with a specific distance moved each update frame, animation changes every x frames, and so forth. As you noted, all objects do run at the same frequency in this method; this is typically not a concern. Here's my generic, flexible sample of fixed update, variable render:

const int UPDATE_FPS = 160;const int RENDER_FPS = 60;int next_update_time = time();int next_render_time = time();while (game_running == TRUE){    while (next_update_time <= time())    {        UpdateGameState();        next_update_time += (1000 / UPDATE_FPS); // this assumes time() returns milliseconds    }    if (next_render_time <= time())    {        next_render_time = time() + 1000 / RENDER_FPS; //as with update        RenderDisplay();    }    else        Sleep(0); //or whatever function yields the current timeslice}

Note: there's an eensy-weensy bug in this: when you reach the maximum value an int can store, next_update_time and next_render_time will do weird things and the engine will do weird things. Fixing this is left as an exercise for the reader :)
You might say, "But isn't that fixed render also, because the render frame rate is fixed to 60 FPS?" Not quite. Rather, the render frame rate is capped at 60 but can vary downwards (and will during hard-to-render scenes); whereas the update frame rate takes priority and is made always to stay at 160.

Variable update with variable render is slightly more intuitive, but also slightly more difficult. Basically, you keep track of the time it took to complete the last frame (total time for everything, update and render), and update each object's position and animation based on that. For movement, for example, each object has a base speed in units distance per units time; then when you update the object, you multiply that speed by the number of units time it's been since the last update. In this method, the game state update and the render generally happen in the same loop -- it's easy to intertwine them, but I would prefer to keep them in separate objects and/or function calls that are indeed differentiated between at the basic level. Here's a generic sample of variable update with variable render:

float last_time = time();float this_time, frame_time;while (game_running == TRUE){    this_time = time();    frame_time = this_time - last_time;    last_time = this_time;    UpdateGameState(frame_time); //use the frame time to calculate movement, etc.    RenderDisplay();}

time() should have a resolution of milliseconds at least, and preferably greater.

Note that jerkiness can build up in either of these cases, but there's not a lot you can do about it, because it's a product of longer render time. The time it takes to render a frame is the time it takes to render a frame, and the game state update time is usually much lower than this (run a profiler on your code and you'll see what I mean).

Hope all that helps,
Twilight Dragon

EDIT: sirGustav's method (posted while I was formulating mine) is an example of variable update, variable render.

EDIT2: major bug fixed in fixed update, variable render code...sorry

Quote:Original post by matches81
What I don´t like about doing more than one call to update() is that it might take quite some time to do an update() on every object if you have many of them and the player doesn´t care

It really depends on your implementation of update(). The code above is a framework that can indeed be adapted to perform one update for every 33ms (what the OP was trying to do), regardless of rendering (such as the code that might be running on a very simple server). However, I generally use it combined with a priority queue sorted by the update times for all objects in the game:

update() dequeues an object and calls its update() function
next_update_time() returns the scheduled time for the first object in the queue

Also, I didn't suggest multi-threading, because I find it makes data coherence harder to implement because of concurrency, but if you can provide said coherence then you might want to consider it.