What is the point of this? IMHO game should render as much FPS as it can.

QueryPerformance* (Windows) and gettimeofday (Linux) should give enough accuracy.

As far as I know, macros completely ignore namespaces.

Depends - you might have a prediction/interpolation system.
And you might have different things update at different rates.

This is the reason for not using logic updates, not a reason for drawing less frames than you can.

I haven't seen any commercial game where you can limit CPU usage/FPS, but it sounds reasonable.

No, but many games, commercial and otherwise, do not eat 100% CPU just because they can. If they only need 50% of the CPU to do everything they need, they only use 50%. Of course most of those games aren't written in Allegro since the poor timer precision pushes most people into a busy wait.

That said - your idea is nice. I would happily sacrifice FPS in many things if I could trade for the fan never coming on!

Yes, I misunderstood you somewhat. I think we all essentially agree - drawing more frames than the viewer will see is bad, not keeping gameplay rate consistent if you don't get a particular specific framerate is bad.

DAMN! My post dissappeared for that logging off thing! OK, in short:

A frame rate limiter is necessary not only for heat problems but also for protecting high-precision calculations and gameplay. In my game I use one which defaults to "min2/max59" and user-adjustable through settings file(I don't have a menu yet) I just tried setting them to "min2/max15" and CPU_Usage started fluctuating between 8-13% on my system. I'm sure a laptop user wold appreciate that(when it becomes a real game that is!) I don't have much experience with laptops but hearing a whooshing sound while you are listening to enemy footsteps should be an annoying thing!

Tech point: My algorithm is about the same with that(with a different formula) It waits for the necessary amount of time if it goes too fast, and it slows down time to avoid stupid(and not funny) things when the speed goes too low.

EDIT:

Yes, it is! Noone acts like Flash Gordon in my game. And you can't eat 15 bullets in one single frame!

Forgot to say, my game is 3D(without OL) and usually uses very tiny floats. My fps_controller is designed to handle that. Also it looks like our (purpose for) min_fps handling is different. Still 25 min_fps might cause an inconsistent speed, but again that depends on your game. I don't read input while waiting because keyboard_buffer and mouse mickeys do that for me. Movement keys are not buffered but they are pressed for long periods due to nature of their task. These work excellent for my game's needs and they might be useful with/without changes for yours too.

My algorithm is basically this:
- If new_ticks < expected then wait(expected_new - new_ticks)
- If new_ticks > max_new then timer = (prev + max_new)

The second should be the very first thing in logic and used carefully since it messes with the timer directly.

OK, this is what I use. It is not compilable and probably the funniest code snippet ever seen but it shows the stuff clearly(just spread them around in a nice OOP way). You will see that it halts both the logic and render, that is what I need and most probably what you need too. I believe it will suit your needs without much modification, if any. There is no div_by_zeros, no roadrunners, no artillery_turned_to_UZIs! I know some games where you can do the last thing for two seconds if you press screenshot button for a few seconds!

As I said, it is not a compilable program and just shows the technique. Starting the timer is pretty obvious and most probably something you already know, so I excluded it only to make the file look simpler(right after install_timer is fine) Likewise, the msec_per_tick and ticks_per_sec should be defined by you. I mean if you want to use 100 ticks per second, add:
#define TICKS_PER_SECOND 100
#define MSECS_PER_TICK 10 // or (1000 / TICKS_PER_SECOND)