I wouldn't worry about using a high-resolution timer for sprite animation.

For controlling animation speed, I usually use timeGetTime(). It has fairly low overhead, and a resolution of 1-5 ms.

I only use a high resolution timer (like QueryPerformanceCounter()) for profiling functions in my code.

[This message has been edited by mhkrause (edited December 12, 1999).]

Usually, you only read the time from the system once and store it in a variable. If you keep reading it a whole bunch in the game loop, and use it for time-based scene updates - things are going to go out of sync.
So, read it once at the beginning of the loop and use that value for all of the game objects during that loop iteration.

I wasn't thinking of calling the timer functions more than once during the main game loop, but I was just thinking that the reasons for using a high resolution timer would be null if using it meant there would be a lot of overhead checking if there was one available every time through the game loop. I think I'll just use timeGetTime or GetTickCount...

By the way, what's the difference between timeGetTime and GetTickCount?

[This message has been edited by Qoy (edited December 12, 1999).]

There are a couple of things I wanted to say about this issue. First, I don't see why you would want the if(HPTIMEREXISTS)...else... at the top of each game loop. Wouldn't you want to arange the code so this test is only done one at startup? For our in-house code we simply look for the timer and if none exists we post a message ans quit the program (but of corse this wouldn't be good for released code, except we've NEVER had that message, EVER).

Second, why do you think that is high overhead? The way you've set up your loop...your getting the counter ONE each cycle through...and TESTING it inside the loop i assume MANY times...the relitive cost of using HP timers is small compared to the many tests against the returned value. although to keep the INTERNAL code efficient, you should probably convert one of the two functions returns to a format like the other (to prevent users from needing to use the if/else pair).

Finnally, I realize this type of game loop is common, but with WINDOWS (message bsed) and High Performance timers...WHY? The whole point of these timers is to TIME things...to make them run when they are supposed to...instead of AS FAST AS POSSIBLE.... so why run a game loop...AS FAST AS POSSIBLE...polling the time and testing it all over the place for each movement. How about an EVENT DRIVEN system. Our DirectX gambling game (800x600x16bpp running 60FPS) uses the HP TIMER tests in the WinMain function (chaning the layout of the message loop to include it). See, every few times throught the message loop (few can be every one, or every 10) or EVERY time when there is NO message waiting - we call a function to test the high peformance timers we've set up. The function gets the performance count, then tests each timer we've set up, if they are triggered, we post the associated message, and reset the timers time (to the current time). This way...we KNOW that the Move() function is called exactly 100 times a second, and the UpdateDisplay() function is called 60 times a second, etc etc etc...and these do not affect each other (unless they lag of course). But even in lag situations, this system allows you to CHOOSE recovery behavior and implement it in ONE location...do you want to DROP FRAMES???? do you want the computer to KEEP posting message and hope it doesn't crash???? do you want to turn the WHOLE thing off (all timers to keep it in comparitive sync) until the message queue is empty? these are easy in such a system....

well...i might write a gamedev article about this topic...but...until then....GOOD LUCK

Yes, please. Most Window timer tutorials just say that timer A
has a better resolution than this timer B, and this is how you
call it and keep track of time. Which is fine for basic programs.

But, they don't go into any detail how to use it effectively with
a Windows messaging system, or how/why it should really work.
This is what we all really want to know.

Zip

I am trying to use a timer in an arcade game I am currently developing, but I have trouble implementing it.
I want to get the time for the last frame and then move my ships faster or slower. For example: a ships moves 50 pixel per second. And the frameTime is 30 frames per second then I move my ship 50/30 pixel each Frame. A little bit later the frametime is 60 and I move my ship 50/60 pixel.
But my problem is, that my ship is really shaking. And I got many different Frametime (everything between 30-60 but someone had told me there can only be numbers like 30, 45, 60 - is that right ?)
I don't know, why the frametime is changing so much, and what I can do ?!

Xai, the reason I wanted the if(timerExists) is because if the timer doesn't exist, I would have it using the regular system timer. The reason I'm using the ordinary (non-event driven) game loop is because I am a student, and when I grow up I may be making games for platforms other than Windows, and I don't want to paint myself into a corner. Thanks for your reply though.

For not, back to my second question:
What is the difference between GetTickCount() and timeGetTime()?

Sorry,I'm a Unix lab right now, so I don't have access to MSDN. This is from memory, which may not be correct.

timeGetTime() has a resolution of 1 ms on Windows 9x and 5 ms on Windows NT.

GetTickCount() has a resolution of 55 ms, or 18 Hz.

So timeGetTime() would be better for your purposes. BTW, this is a "multimedia timer" and you must include mmsystem.h and link with winmm.lib.

Everybody is telling me that the performance counter is the best way to measure time for sprite animations. But that means that every time I measure the time, there has to be an
if(hiResTimerPresent)
GetHiResCount();
else
GetTickCount();
It seems to me that that would make for a decrease in performance.
Is there some better way to code for the possiblilty of two timers, or is that the only way?

------------------
http://qoy.tripod.com

You don't have to test if the HP is available, cause it's always there. It's available on every system since the original 8086 I think.