Hey I'm having some trouble with a timing mechanism i have implemented. I'm using time.h's clock() function to read the time elapsed to the milisecond, but apparently it's not very precise. I started counting the dropped frames (when (now -last_time) == 0 b/c I am using this value to multiply against velocities if it's zero there's no change) and at about 50FPS it was dropping 48% of the frames. You would think that the difference shouldn't be zero unless you're running more than 1000 FPS (at which ppoint I wouldn't mind a few dropped frames ) but at 50 FPS? it must be rounding or something (to nearest 50?) anyways, back to my origeonal question, does anyone know how I can get access to a better timer (more precise)? I know the max I'm looking for something around 10 kHz to accomodate the faster processors (and any rounding), is this available? Thanks for any help, O.G.A.P.O. (sorry for 2x post, hit wrong forum last time ) Brought to you by: O.G.A.P.O. +----------------------------------------+ | Surgeon General's Warning - | | OGAPO can cause serious mental damage | | if taken in large doses. | +----------------------------------------+ /* Never underestimate the power of stupid people in large groups */ Edited by - OGAPO on 10/30/00 4:53:01 PM

timeGetTime is accurate IF you use it like this,
timeBeginPeriod(1);
time=timeGetTime();
timeEndPeriod(1);



JoeMont001@aol.com www.polarisoft.n3.net

I wish I could help... clock() is somewhat innaccurate, and it doesn't actually measure milliseconds, it measures clock cycles... in theory.

There's supposedly something called a "multimedia timer" that's insanely accurate, but I know next to nothing about it...

--Tr][aD--

Edited by - TrIaD on October 31, 2000 7:09:55 PM

I''m pretty sure it doesn''t measure cpu ticks.
On a 500MHz machine, a cpu tick is 0.000000002sec, not 0.001sec.

I use clock() and it works fine, fps around 25.

Actually, on my other computer, which is faster & has a better 3D card, I think it came up zero every time, becuase it showed a steady framerate of 33.0...

...
Okay after running a test, clock() increments in 10ms blocks.

That blows, I thought it''d be 1ms.

QueryPerformanceCounter();
QueryPerformanceFrequency();

"Any statements made by the above poster are strictly opion (unless otherwise stated) and may be offensible to some readers."

Err... yeah, som''n like that... but I knew it wasn''t straight seconds...

and incidently, I found QueryPerformanceCounter myself, today... haven''t played with it much yet, but I probably will soon...

if this thing screws up my sig one more time...

--Tr][aD--

FordPrefect

quote:
The resolution of the clock() function is implementation-defined. The macro CLOCKS_PER_SECOND holds the number per second of the value returned by clock().

That has nothing to do with the fact that the smallest quanta clock() will update by is 10 and not 1. Ok well, it has a little to do with it, but I''ve seen CLOCKS_PER_SECOND ever be anything but 1000.

If you call clock() more frequently than 100Hz it always returns 0.

...
wow, LARGE_INTEGER is a 64bit int... and the - and < are not defined for it...
pain in the... had to cast as __int64''s
It mesaures to the microsecond! It appears that 5microseconds is the quanta for this one.
Thanks TrIaD!

LARGE_INTEGER is a strure (or union) depending on the build. You can access the __int64 part by using largeInt.QuadPart (where largeInt is your variable)



BTW, thanks for the help, the MMtimer works great

Brought to you by: O.G.A.P.O.
+----------------------------------------+
| Surgeon General's Warning - |
| OGAPO can cause serious mental damage |
| if taken in large doses. |
+----------------------------------------+
/* Never underestimate the power of stupid people in large groups */