The overhead from these function calls is so small that I can't measure it.

I don't use these high precision timers for game speed, but to give some time back to the OS, more precisely the time remaining to the next frame when all the work has been done for this frame. In that context it is very reasonable to ask for precision of 1ms.

True, but for a CPU intensive game only. My game is expected to use only very little CPU, even at higher logical speed. I just like to be nice with my game, and I like to save my laptop from using power when it is not really necessary.

Theoretically, yes. That's what I thought before. Then I just saw that my program would use much more CPU than expected, and that's where I started my investigations. So my finding is that calling timeBeginPeriod(1) when using rest(1) solved the problem essentially.

I don't know what other side effects the timeBeginPeriod(n) would have. I would definitely not like to have it influence other timers around. So I think that calling timeBeginPeriod(1) only increases precision, so it doesn't harm. Calling it with other values might decrease precision in case the application has called timeBeginPeriod(1) before. I would not appreciate such a behaviour...

Edit: Before calling timeBeginPeriod you have to use timeGetDevCaps to determine valid values. The following code is from MSDN:

#define TARGET_RESOLUTION 1         // 1-millisecond target resolution

TIMECAPS tc;
UINT     wTimerRes;

if (timeGetDevCaps(&tc, sizeof(TIMECAPS)) != TIMERR_NOERROR) 
{
    // Error; application can't continue.
}

wTimerRes = min(max(tc.wPeriodMin, TARGET_RESOLUTION), tc.wPeriodMax);
timeBeginPeriod(wTimerRes);

I haven't looked into how timers are created in allegro, but if it is using timeSetEvent it will be affected by timeBeginPeriod also. So it might also be a good idea to put a call of timeBeginPeriod(1) into allegro's init_timer() function?

I'll look into the code this weekend, and I'll test calling timeBeginPeriod(1) from within init_timer().

OK. So here's my findings:

When I call timebeginPeriod(1) in the beginning of my program, or inside install_timer() then overall CPU usage increases (sometimes drastically). So some objections made are valid: requesting higher accuracy does cost something.

So then I tried some other places to put this call, but the only place where it does good - and really decreases CPU usage - is inside of the implementation of rest(), which is exactly what I requested some time ago.

Evert: Should I send you the code again, this time with some improved error handling? It is not much, only checking the return value of timeBeginPeriod() to decide if timeEndPeriod() has to be called or not.

The function 'timeSetEvent' is not used in allegro. What is used is a call to 'SetEvent' using 'timer_stop_event = CreateEvent(...)' in wtimer.c:222. As far as my program has shown, the call to timeBeginPeriod(1); added in tim_win32_rest(...) does not affect that. Well, calling timeBeginPeriod(1); from my main program has some effects, so that might have undesirable influence here.

This is the updated code section in wtimer.c:

Maybe I should also send this to the mailing list (AD)?

Done.

I have tried that. The overall performance decreases actually, which surprised me of course. Explanantion is probably that the call does have some side effects, which cause more overhead in other functions. So that's the reason I have left it at putting the calls into rest() only.

Finally I got some test project together, which contains my current game framework including the game loop. This can serve as performance benchmark (how many balls do use how much cpu time), but also as an example of a game framework and a game loop. Basically, the game loop is taken from Lennart Steinke's book 'Spieleprogrammierung' in bhv Verlag.

There's a MSVC7.1 project file included, but no makefile (the last makefile I have written is 8 years ago...), and you have to include the allegro library to the linker statement (because I'm using my allegro project file, which inplies automatic linkage in the Visual Studio). If someone has a working makefile, you might post it here, so I can include it in the archive eventually...