I looked at this thread, and I found a lot of timer routines using QPC but there is no explanation about how to use these routines in the main loop.
My game must run at 60FPS, with options for reducing CPU ussage.
Can someone post a little example program using high resolution timer routines, and how to use them in the main loop?
Thanks in advance.

You should not use high resolution timers in main loops. They should be used for high precision timing - in games, mainly profiling. For game logic, use lower precision time functions, like timeGetTime() (returns milliseconds) on win32.

The reason is because most high resolution timing functions have... issues...
edit: updated RDTSC problems description
RDTSC: reports incorrect results on many computers (mostly dual-core systems), crashes on 486s and earlier, and the units change at run time due to power-management issues
(note: dual-core issue can be fixed for dual-core AMDs with a utility downloadable from their website)
QPC: slow; yields incorrect results on many computers; win32 only
gettimeofday: changes when system time changed; not sure what underlieing method it uses; many yield errors on some computers

And anyway, sub-millisecond precision for regular user interactions is pointless.

I'm going to need you to prove this.

But it leads to more accurate simulation of physics and other game functions.

These are completely non-issues

Orz: Wrong I'm afraid.

Gimme a few minutes to come up with references. Only some of the problems are documented on the web though. I have personally seen both QPC and RDTSC fail. I've never seen gettimeofday() fail, but that's because I primarily use windows.

Timers don't make physics calculations more precise; they just make physics more closely synchronized with real time. However, there's not point in synchronizing them more accurately with real time than the output devices (or the human perceiving them, assuming you're outputting to a human) can track. For instance, CRTs tend to only do a retrace every 8-20 milliseconds, rendering sub-millisecond synchronization for animations displayed on CRTs pointless. LCDs have different issues, which I'm less familiar with the precise numbers for, but they have multiple sources of timing issues; data rates for the digital cables and update rates for the LCs themselves. Either issue alone is enough to render sub-millisecond timing irrelevant for synchronizing LCD output. The human eye also introduces timing limitations, but these are harder to quantify due to variations depending upon which portion of the eye you are using (peripheral vision etc), individual variation between eyes and brains, and the nature of the visual stimuli.
Sound is a different issue of course, but one I know less about. However, it's usually buffered for several milliseconds in advance even in games, and much of the timing there is handled by the sound hardware and drivers.

About what? Be more specific.

Basically, I have tested high resolution timers using QPC on windows on many different PC's for my games, as has Mike Welch who I have worked with on Neon Wars. The results are consistently better than lower precision timing results in terms of smoothness and accuracy.

So, I am speaking from a practical and pretty experienced point of view here.

If you're using a delta-time method, you are basically using a Riemann sum to compute the position based off the velocity and acceleration. By using smaller deltas (smaller rectangles), your result is more accurate. Imagine: how accurate (*not* how smooth would it appear on screen) would the movements be if you used a 1-second timer?

You are totally high jacking the thread.

Oh, you're right. I sorta forgot about the question when orz posted his example of how to do it. Did you just add the example of how to use KittyCat's code, or was that there? Either way: Paul: read this, especially where he says "How to use KC's routines:"

The "proof" I promised:

(also, of course, the other reason I forgot to list originally: RDTSC is based upon processor frequency, which changes at run time due to power management features)

personal experience: my dual-core AMD had neither QPC nor RDTSC work correctly originally. Using KB896256 and another microsoft patch I can't find at the moment fixed QPC but did not fix RDTSC (contrary to the claims of the docs for the hotfixes IIRC). Using AMDs utility may have fixed RDTSC, but I haven't tested it enough to tell yet (only installed yesterday).

2nd-hand experience: Shizmoo Games (http://www.shizmoo.com/) told me in aproximately 2001 (my memory is a little fuzzy on the exact date) that they had switched from using QPC to using lower resolution timing functions because a significant numbers of their users had some flaw in their motherboards chipset that caused QPC to return bizarre results but left other timing methods functional.

documentation for dual-core &| multi-CPU issues on the web from major companies:

http://support.microsoft.com/kb/896256
Supposedly fixes issues with QPC and/or RDTSC; however, it did not fix RDTSC on my dual-core AMD.

http://support.microsoft.com/kb/909944

http://www.amd.com/us-en/Processors/TechnicalResources/0,,30_182_871_9706,00.html
Supposedly fixes issues with RDTSC; working so far for me, but only had it installed for a few hours now. Reports of crashes if both this and the above microsoft hotfix are installed.

documentation on the web from less well-known sources:

http://www.virtualdub.org/blog/pivot/entry.php?id=106
note the headline: Beware of QueryPerformanceCounter()

http://www.gamedev.net/reference/programming/features/timing/
in particular, note:

http://forums.seriouszone.com/showthread.php?t=44791&page=5
edit: note: that's a Croteam (developers of Serious Sam) developer posting there, talking about RDTSC (he likes QPC though)

Will update this to handle other posts while I was googling for that stuff

edit:

You're equating physics synchronization with physics accuracy. If you want more accurate physics on the same time measurement method while using a delta-based time, it's as simple as using two deltas of half the size. Time gets clumped, but physics accuracy is not lost.

I'll be honest. I don't care about all those references.. In my experience when testing on many different setups, it's the best choice.

I do. I don't know I quite trust the stuff about QPF, but the RDTSC references make sense. Actually, I'm going to do some experimentation when I get home: the original UT used RDTSC in its code, and it runs too fast on many systems I've played it on. I will disable CPU clock scaling and see what I get.

[append]
That's the first comment in the virtual dub blog post

Okay, so the best high-frequency counter is timeGetTime and gettimeofday, it seems. Yes, orz?

CGamesPlay: if you QueryPerformanceFrequency each time you get the timer it is good with frequency scaled processors

Gull: I'm sure that solves the CPU scaling problem, but not the others...

Personally, I like the timeGetTime/gettimeofday method. It's easier, after all

What is the precision of gettimeofday? If it is too low it won't look very good even if it is more reliable.

It's microseconds.

Ok....

I use timeGetTime() for game logic, and RDTSC for performance monitoring.

timeGetTime():
On all systems I've tested, has a resolution of at least 10 milliseconds; on many (all 2k&XP? not sure) it has a resolution of 1 millisecond. It's accuracy seems generally quite good for its resolution. 10 milliseconds is less than I'd like when use delta-timing, but good enough; 1 millisecond is plenty for delta-timing games. This function was reasonably fast on the systems where I tested it.

RDTSC:
Fast. Typically 10-100 cycles, depending upon CPU type. The problems this has render it useless on some platforms, but performance monitoring is non-critical on users systems, so you only have to worry about your own testbeds.

other timing methods:

allegro timer interrupts - I don't like the interface, but they seem to yield enough accuracy for timing game logic. I never set them to run over 200 hertz.

gettimeofday() - unixers seem to like it but docs claim that it's not monotically increasing, so I would avoid it for game logic. I'd like to do more testing on this - I don't know what the real-world speed, resolution, or accuracy is like.

SDL_GetTicks() - haven't checked the implementation, but I would guess it to be a wrapper for timeGetTime() on windows. If you use SDL this looks like a decent choice.

libc time(NULL) - very low resolution, but this is what I use when I can't find anything non-libc

libc clock() - documentation on this varies wildly and is contradictory.

QPC() - too buggy for game logic, too slow for profiling. However, unlike RDTSC its units are easily convertable to seconds, so I still occaisonally use it.

Oh, well, if the user is playing at the moment DST kicks in and he has his RTC set to localtime (for no reason at all), then the game would lag an hour

I tried to use these routines, RIchard helped me a lot, and he answered all my question but I could not make it work properly.
I am using devcpp since a few days ago and perhaps there is something wrong with my configuration, so can someone else try to compile this routines?

timer.hpp

timer.cpp

my loop

.
.
.
Well, this loops works OK at 60fps, but when some sprites disappear the FPS grows(the game runs faster), with few sprites my game runs faster and with more sprites it runs slower.
What can be wrong?
.
.
.
.
.
.

I disagree.

I agree.

.
.
.
[EDIT]
GullRaDriel I'll try that now, thanks!

Paul, did you try that change the 240 to 60 thing I mentioned?

From Pmask libray you have test.c and test2.c which use Orz's timing routines so all your need are filled .

Yes, I tried several times, but it allways run at 240 or more without reset_timer()
With reset_timer() it seems that works, but then timer.gfx_fps shows allways 0

I can't see how that would happen if you had no 240 references anymore.. but anyway, try Orz's code.

How should I use Orz's routines?
I need to see a main loop implemented with those routines to understand how they work.

Yeah, that's my timing measurement code. A few caveats:
1. the gettimeofday() implemenation there is bugged... just some easily fixed typos, fixed in my lastest version of that file (so far existing on my computer only...)
2. while that's in the PMASK download for use by the examples, I consider it to not be a part of the examples, not the library itself.

That was the title, but your original post said

So I posted code that demonstrated how to use a timer function in a games main loop, independant of whether that timer function used QPC. Though, for usage with QPC, its best with the ints changed to doubles. i.e.

edit: fixed a typo in the code (mispelled since as sicne in one case), added a value of ms_per_tick

The only thing necessary (with or without changing the ints to doubles) to make that into a functional QPC-timed game loop is a QPC based timer such as:

edit:

That is the main loop there in my first post, and again in this post. It's untested, but is a demonstration of the concepts. If you want one with delta-timing instead, just ask.

Hm... not necessarily a good idea... (edit: I feel kinda stupid saying that something of mine isn't a good example for some purpose, but really the PMASK tests weren't written with this is mind... perhaps I should clean up test2.c sometime...)
test.c does not use any timing routines from my get_time.c or anything else except Allegro. It does not use high resolution time. So, it is not really a good example. edit: its timing method is also totally inappropriate for a game
test.2 does use my timing routines. However, it's not the best example as the main loop is kinda quick-and-dirty, cluttered up with text output and keyboard input stuff, and whatnot. Still, it is an example of using my time functions to time something in a relatively smart manner compared to many allegro example programs. It's also undocumented, and uses different priorities than many games might prefer. (for instance it will never use more than 50% of CPU time on graphics)

Thank you very much! I'll try to implement your routines now!