i''m currently coding my first game in windows, trying to work out vc++ as i go, but i have come a bit unstuck. with dos and the like i can set up timers nicely and rely on them to do the job, but i''m having dificulty getting a timer in windows to update my game world data structure every 1/30th sec. As a simple example i have a timer with a callback function that moves an object one pixel to the right on every cycle of the clock (ie. 1/30th sec), and the main game loop peeks at the message queue, dispatches as requires and then draws to the back buffer and then flips the back buffer if the displayed world is out of date (i.e. the object has moved in the world data structure). The only problem is that it''s a little jumpy... not too bad but quite noticeable, how do i fix it? cheers dom

You just learned a valuable lession. Window's standard timers SUCK! These things are useless for any kind of real specific timing work. The reason is that when you use a timer, it just posts a message in you message queue (with low priority no less) so you won't get them immediately.

Luckily, Windows does have some better timers availible. They probably put these in place for their future plans to corner the real time avionics market. (I'll start walking)

These come in to flavors, system timers and the multimedia timers. Personally, I just use the system timers, since the multimedia timers are more difficult to work with, and I honestly can't tell a difference.

The main function to use the system timers is

DWORD GetTickCount();

This just returns the current number of milliseconds that have elapsed since the system was started. By getting a value and comparing it to another value, you can pretty accurately tell time. This works really well with a static variable in a function.

Also, certain versions of Windows have different system clock resolutions. (NT compaired to 95/98) This may need to be something to keep your eye on with Windows 2K.

Now, since the DWORD is finite, the value will roll over once every 48 days or so, but honestly, when has Windows ever ran that long without crashing?

(Don't mind me. I'm just bitter becuase IE thinks crashing my computer is hysterical)

Edited by - I-Shaolin on 1/25/00 7:13:37 AM

GetTickCount is only slightly better.
To do games, you really gotta have the best of the best.
Try QueryPerformanceCounter, one of the highest resolution(meaning most accurate) counter available on windows(only RTDSC is slightly better, but it is asm, and some argue that QueryPerformanceCounter is mapped onto RTDSC if available).
To check if your system supports the counter, call QueryPerformanceFrequency, which can give you the number of ticks in a second.
So if you want x fps, time_to_update = frequency/x

No Kidding???

I never had any problem using GetTickCount(), and since QueryPerformanceCounter() and QueryPerformanceFrequency() aren''t garunteed to work on every machine, I avoided them.

I guess you learn something new everyday.

Forgive my ignorance on the observation here, but if Query PerformanceFrequency and QueryPerformanceTimer don''t work on all systems, wouldn''t it make sense to use both methods described here encapsulated in a timer class of some sort. Granted the timer wouldn''t be as accurate if QueryPerformanceFrequency wasn''t available but in that case the game was never going to be that acurate on that machine outside of assembly coding. Just a thought.

Kressilac

Actually, that''s exactly what you could do. I just never had the need for a timer as accurate as the one QueryPerformanceTimer() uses.

yeah we all do that.
I fall back according to the following sequence
RTDSC -> QueryPerformanceCounter -> timeGetTime
Each is encapsulated by a timer class, and all derive from a base timer abstract interface.

you may want browse thru the Golgotha source code
http://crack.com/golgotha/

oops.. wrong thread

well it is worth checking out anyway (8

but but, rdtsc takes 13 cycles!! for each call!! ahh!! hell thats slow