Allegro's timers don't have a very high resolution, so it sounds about right. Then again... I've never had a timer that limited my FPS, just my logic. You might be doing something wrong.

That's surely not the problem. I tried commenting out all logic and the game keeps running at 64 fps. And if I remove the "while (speed_counter > 0)" loop, it runs at 700 fps.

Just so the game is more smooth and responsive...

As I discussed in another thread, you don't need to render beyond the monitor's refresh rate to have a smooth and responsive game (in fact this degrades responsiveness because you waste rendering time at the expense of processing gameplay). You can run a triple-buffered render loop in one thread and the game logic in another. By doing this, you're capped at rendering at the rate beyond which no one can tell the difference. Instead of the spare CPU time being shared by game logic and redundant rendering, any surplus gets completely dedicated to game logic, making it much smoother than a single-threaded approach. All you need to figure out is multithreaded programming (handy if you know already) and highly accurate timing. Both of these are usually platform-dependent (especially the latter).

By the way, that method in the Allegro FAQ is a bit outdated. It assumes you can set an arbitrary frequency, which is not the case except for DOS. Windows, Linux and any other multitasking OS take control of the timer interrupt and set it to something like 50, 60 or 100 bps. The OS's timer interrupt handler is used in preemptive multitasking and to supply a fixed low-resolution timer service to applications that may need it. Allegro uses this to simulate DOS-style arbitrary frequency timer interrupts.

The reality is that we shouldn't program games the way we used to - with absolutely everything synchronised to just one thing - such as a timer or screen refresh. So we need to separate game logic from rendering by multithreading. By triple buffering, the rendering thread synchronises itself to the screen's refresh rate. You could synchronise the game logic to something - either using the same thread as the render logic or by using the OS's timer service. But this makes for jerky gameplay because when all threads have nothing to do, the process will sleep until the OS's next multitasking 'heartbeat', even if some work must be done before this (and the OS's heartbeat is not synchronised with the monitor refresh rate). For this reason, something has to keep the game process alive. This is achieved by keeping at least one thread busy. Since we can't keep the rendering thread busy when it's synchronised to the refresh rate, the only other choice is the game logic thread. This is a big reason why we've moved away from fixed-resolution timing and integer-based geometry to delta timing and floating point-based geometry (another reason being that 3D is way less deterministic in its rendering times than 2D, so we need to cut down the choppiness by eliminating synchronisation waiting).

Just on a side note, it was mentioned in the other thread (see above) that the reason games don't take this multithreaded triple-buffered approach is that they're developed with benchmarking in mind. In my opinion, the best form of benchmark is not the number of frames per second, but the time it takes to actually render a frame. Unfortunately, the meat-head masses out there (i.e. those that own powerful computers but couldn't tell the difference between 1 and 0) prefer a metric that favours higher numbers rather than lower numbers.

I think it would be interesting actually to benchmark a game against itself on the same computer... The game could run in two modes - multithreaded triple buffered and single threaded double buffered (or whatever mode doesn't wait for vsync). Both modes would show frames per second, which would be the number of times the game logic executes every second. Using the former mode, if rendering fps is almost always at the monitor refresh rate, then gameplay fps will be much higher than that of the latter mode.

Sounds interesting. Threads flagged