timer hell ! need 13ms

I desperately need to figure out the best method to get a 13ms timer. It doesn't need to be perfect, but as close as possible.

As a newbie to timers I first tried the standard win32 timer (wasted time)

I then found an article on timers :

Timers Tutorial - CodeProject

so figured I would get the best available according to the article: Queue timers, with the same slow result.

I used GetSystemTime to try and benchmark how long my execution is and it seemed to be less than 1ms:

Code:

  
  hdc = GetDC(hwnd);
  hPen = CreatePen(PS_SOLID,1,RED);
  SelectObject(hdc, hPen);
  if(x == 600)
  {
    x = 0;
    y = 240;
    hPen = CreatePen(PS_SOLID,1,GREEN);
    SelectObject(hdc, hPen);
  }
  MoveToEx(hdc, x, y, NULL);
  y = baseline - (signalpoints[x]/10);
  LineTo(hdc, x, y);
  x++;

  ReleaseDC(hwnd, hdc);

seems like simple code, signalpoints is an array of ints

Any suggestions ?

I was going to try multimedia timers but MSDN says they are obselete.

All I am trying to do is draw a heartbeat waveform across the screen.

UPDATE:

multimedia timers worked great. I got down to 5ms which is way faster than I need.

So much for it being labelled as obselete.

QueryPerformanceCounter()
QueryPerformanceFrequency()

Originally Posted by Bubba

QueryPerformanceCounter()
QueryPerformanceFrequency()

Remember that those only work with LARGE_INTEGER ( or whatever its name is ).

Why are you telling me? I use those everyday.

timeGetTime() stinks for high res timing.

Originally Posted by Bubba

Why are you telling me? I use those everyday.

timeGetTime() stinks for high res timing.

So, what are you telling me?
High res timing is more accurate with LARGE_INTEGER(long long)
(Those two functions take LARGE_INTEGER as argument!)

Originally Posted by Sipher

So, what are you telling me?
High res timing is more accurate with LARGE_INTEGER(long long)
(Those two functions take LARGE_INTEGER as argument!)

*sigh*

It has nothing to do with it being a LARGE_INTEGER. The accuracy is determined by your system. On older systems, you will in fact have less accuracy since it will use the PCI bridge timers and these may jump time ahead by a few seconds due to a bug. On other systems that have SpeedStep enabled you will also have less accuracy since the processor frequency will fluctuate, despite the function being the same on all cases.

What determines the accuracy of this method is your processor frequency, your operating system support, the type of processor being used and whether or not it supports SpeedStep and has it enabled. The argument type is just a consequence of how the function works (and what it reads).

Well, ok, i didn't know that!

So, what are you telling me?
High res timing is more accurate with LARGE_INTEGER(long long)
(Those two functions take LARGE_INTEGER as argument!)

I'm telling you the answer. What you do with it is your business. Research it. The SDK provides all types of information about the various timers in Win32. Use the timer that best suits your needs. I have had no luck with allowing the API to time things for me and give me callbacks or whatever when its done. Way too slow and cumbersome. I love how I give you one answer and you proceed to tell me how my answer functions when I would think it to be apparent I know how the function works since...um....I suggested you use it.

Code:

LARGE_INTEGER perfFreq;
LARGE_INTEGER curTime;
LARGE_INTEGER prevTime;


void Init()
{
   QueryPerformanceFrequency(&perfFreq);
   QueryPerformanceCounter(&prevTime);
}

void Loop()
{
   bool active = true;
   while(active)
   {
        QueryPerformanceCounter(&curTime);
        float deltaInSeconds = static_cast<float>( (curTime.quadPart - prevTime.quadPart) * (1.0f / perfFreq.QuadPart) );
        prevTime = curTime;
   }
}