goal: support for frame skipping, setting a maximum fps, and setting a minimum fps

Another idea:
Only support Settings::maximum_fps.
Don't make frameskipping and minimum framerates part of the API, but show users how to do them with a small demo program.
This is how my physics lib is. I only make complex / tedious things part of the api, and provide examples to teach all of the simple stuff.

About the accuracy, there's a way you can get a good dt every frame (like in doom3). I forget which book of mine it's in, but there's a way to read directly from an x86 system's quartz clock.

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.

Why? There is absolutely no use of drawing more visual frames than there are logic frames.

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

Then you can do all that without drawing the frame. Besides the completely valid reason that HoHo argues, many of us with laptops have a great dislike for applications that just use 100% CPU because they might as well. They make our laptops warmer, use the battery more quickly and cause fans to come on. I hate fans!

I also agree with fuzinavl that it does make sense to incorporate this stuff into OpenLayer, as I believe the remit of OL is "stuff that most people will find helpful"?

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.

> Then you can do all that without drawing the frame.

Sure, but I was saying you could have a system (not saying
it's particularly good or anything btw) where the logic update
computes new positions for, hmm, stuff. Any render till the
next update can then interpolate positions and draw them there.
You then have smoother movement (albeit with some delay) when
you have high framerate, without having more updates. IYSWIM.

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.

That'd be awesome

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!

Murat AYIK, what does proper frame limiter code look like?
Standard waiting loops don't return control to other things for brief times. Also, control must be returned on-time!

Everyone, the pseudocode for minimum_fps and frameskipping is posted above. You don't necessarily need to wait for OL to integrate it.

for my game, I'd:
----------------
min_fps = 25.0 because my collision detection code can't handle turns greater than 90 degrees. (max_rotation = six 360's/second) My graphics code is very lightweight.
----------------
max_fps = 60.0 because the fps counter code tests only once every 10 or so frames. What if the game usually runs at 85 fps, but whenever there is a collision, the framerate drops to 59? The user would get 2-9 frames of slowdown for every complex collision.
----------------
target_fps = 40.0 because that's what's visually reasonable (to me anyway)

so:
< 25 fps = state of slowdown
25 - 40 fps = state of frameskipping
40 - 60 fps = let it be
> 60 fps = forced down to 60 fps

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.

Could you post a simple working gameloop featuring your nifty fps control code?

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!

Gah! I'm going _tick crazy!! Makes total sense now.
I think a frameskip_below variable can easily be added.

curious:
1) how/when do you get timer_tick to update itself?
2) how do you get MILISECS_PER_TICK?

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)