Page 1 of 2

[C]Does anyone know a good timing library?<solved>

Posted: Tue 04 Sep, 2007 4:14 pm
by Halifax
I need a fairly good timing library that can manipulate milliseconds and is cross-platform because timing.h just isn't doing the trick. So can anyone help me with a suggestion?

Posted: Tue 04 Sep, 2007 4:25 pm
by benryves
What are you looking for? A date/time library (for the manipulation bit), or a timer library? Do you want to time durations or do you want a timer to execute code at fixed intervals? :)

Under Windows the only reliable millisecond-accurate timing is part of the multimedia API, and even there it is recommended that you don't use any API calls apart from the MIDI ones.

I'm guessing that high-precision timers vary wildly by OS. If you could narrow down your request you could probably get away with writing your own methods that use OS-dependant functionality without too much hassle...

Posted: Tue 04 Sep, 2007 5:19 pm
by DJ_O
In summary (according to what he posted on Omnimaga forums) he want to make his games or programs to run at the same speed on all platforms and computers.

Posted: Tue 04 Sep, 2007 8:11 pm
by Halifax
benryves: Hmm alright. Well really all I need is a timing library that works on windows and x86 then I guess. The only thing I don't get is how come millisecond timing can't be cross platform, but second timing is.

Posted: Wed 05 Sep, 2007 6:59 am
by King Harold
Odd indeed..
But can't you make a thread sleep for a number of milliseconds on all multy-threaded platforms? If so, you could just run a thread that loops forever and sleeps 1 millisecond each iteration and report a tick each time it finished sleeping, right? like so?:

Code: Select all

while (true)
{
  sleep(1);
  reportTick();
}
Of course I wouldn't know, I've never done anything of the sort..

Posted: Wed 05 Sep, 2007 9:45 am
by benryves
Sleeping a thread is only guaranteed to give time to the rest of the system for at least the time specified, and the time is typically much much longer (tens to hundreds of ms). You might have more luck bumping up the thread's priority to realtime, but that's fairly inelegant.

Getting code to execute at a fixed, accurate time step with ms-granularity isn't really practical as far as running multiple applications at once go. If this is for a game I'd suggest locking to the monitor's vertical blank, or to not worry about it at all and just let your code run as fast as possible, using QueryPerformanceCounter (Win32 API) or DateTime (.NET) to calculate the time difference between updates and using that to scale logic speed.

Posted: Thu 06 Sep, 2007 12:50 pm
by Jim e
QueryPerformanceCounter is a bad idea. It varies wildly between computers. Intuition says it should be the cpu clock, but that does not seem to be the case in all instances. Trust me, we tried it in wabbitemu, and it caused more grief.

Here, read from one of the few programming blogs I respect.
http://www.virtualdub.org/blog/pivot/entry.php?id=106


Sleep also fails just like Ben says, it waits at least that amount of time.

Simple method of synchronizing would be to keep track of the virtual time in your game, and the real time. If you get ahead of the real time, wait until it catches up(and do any work thats not timing specific). If you fall behind real time then you'll likely need to skip frames and execute as fast as possible.

Now as far as cross platform goes, no idea. There's a way, I just don't know.

Posted: Thu 06 Sep, 2007 3:40 pm
by benryves
Jim e wrote:QueryPerformanceCounter is a bad idea. It varies wildly between computers. Intuition says it should be the cpu clock, but that does not seem to be the case in all instances. Trust me, we tried it in wabbitemu, and it caused more grief.
Hm, curious. Did the problems persist if you forced the thread affinity to a particular core and/or disable variable CPU clock rate?

Posted: Fri 07 Sep, 2007 6:39 am
by crzyrbl
<timing.h>,
is that the same as
<ctime>?

is clock_t not cross-platform?

Posted: Fri 07 Sep, 2007 1:01 pm
by Jim e
benryves wrote:
Jim e wrote:QueryPerformanceCounter is a bad idea. It varies wildly between computers. Intuition says it should be the cpu clock, but that does not seem to be the case in all instances. Trust me, we tried it in wabbitemu, and it caused more grief.
Hm, curious. Did the problems persist if you forced the thread affinity to a particular core and/or disable variable CPU clock rate?
For me it worked fine actually, I'm on an intel. Spencer was on an AMD, it was his clocks speed divided by some number that made it utterly useless. But after reading up on it, we gave up. I heard nothing but woes about it.

Posted: Sat 08 Sep, 2007 12:09 am
by Halifax
crzyrbl: time.h, timing.h, ctime.h are all the same headers and yes clock_t is cross platform, but as stated in my topic post, I need a library to manipulate milliseconds which is not the case with clock_t since it only goes up to seconds.

jim_e: Thanks

Posted: Sat 15 Sep, 2007 10:20 am
by coelurus
Are you sure you need millisecond accuracy? timeGetTime is pretty reliable in Windows although it has pretty bad accuracy, could you possible interpolate between time samples?
And what do you mean with "windows and x86 then I guess"?

Posted: Thu 11 Oct, 2007 2:17 am
by Halifax
SDL gets down to the millisecond, just in case anyone else wanted to solve this problem easier.

SDL is also cross-platform, so it fits all my requirements.

Posted: Thu 11 Oct, 2007 9:13 am
by coelurus
You know what? SDL uses timeGetTime in the newest snapshot.

Posted: Thu 11 Oct, 2007 1:29 pm
by DJ_O
Is SDL for all programming language for PC like Java, Visual Basic, Python and stuff?

And thanks coelurus for editing your forum profile because last time I clicked your Image I landed on a porn site