Jump to content
  • Advertisement
Sign in to follow this  
Sybalos

Issue with QueryPerformanceCounter

This topic is 2334 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi all,

I'm having an issue when using QPC/QPF here is my code:


unsigned frameNumber;
unsigned lastFrameTimestamp;
unsigned lastFrameDuration;
float lastFrameDurationS;


void InitTime()
{
LONGLONG time;
qpcFlag = (QueryPerformanceFrequency((LARGE_INTEGER*)&time) > 0);
if (qpcFlag) qpcFrequency = 1000.0 / time;
}
unsigned SystemTime()
{
if(qpcFlag)
{
static LONGLONG qpcMillisPerTick;
QueryPerformanceCounter((LARGE_INTEGER*)&qpcMillisPerTick);
return (unsigned)(qpcMillisPerTick * qpcFrequency);
}
else
{
return unsigned(timeGetTime());
}
}


void Timing::Update()
{
if(!timingData) return;
if(!timingData->isPaused)
{
timingData->frameNumber++;
}
// Update the timing information.
unsigned thisTime = SystemTime();
timingData->lastFrameDuration = thisTime - timingData->lastFrameTimestamp;
timingData->lastFrameTimestamp = thisTime;
timingData->lastFrameDurationS = timingData->lastFrameDuration * 0.001f;
}


When i use this to simulate some physics based animation everything work fine on my laptop and my home pc. But i tried it at my job's PC wich is more powerfull and the animation is jerky. When i use timeGetTime instead everything run smooth on every pc. I confirm that every PC that i tried support the HighRes timer. Here is how i use it:

actor->m_position += (actor->m_velocity * g_pApp->GetTiming()->lastFrameDurationS);


Here is the spec of the problematic PC's processor:
http://ark.intel.com...-GTs-Intel-QPI).

Any idea would be apreciate.
Thanks.

Share this post


Link to post
Share on other sites
Advertisement
I'm not sure this will fix your problem, but the QPC functions takes 64bit variable to store the counter and frequency
wich you are converting and storing as (probably) 32bit unsigned int, wich probably isn't a good idea.

Try change thoose unsigned to LONGLONG or int64.

Share this post


Link to post
Share on other sites
Another thought is that you may be running into floating-point precision issues on the faster machine. Your last frame duration may be so small that this starts to become significant, hence the uneven result.

In general you're doing a lot of conversion from integer to floating-point and back again here so some form of imprecision can be expected. Better to keep the values in the highest-precision format (LARGE_INTEGER in this case) until the final calculation, which will preserve maximum precision throughout your codepaths.

Share this post


Link to post
Share on other sites
You're rounding your QPC values to millisecond accuracy, which completely defeats the purpose of using it and will be introducing a lot of timing error.

Also, you should never use [font=courier new,courier,monospace]float[/font] to store absolute time values (it's ok for delta time values), and [font=courier new,courier,monospace]unsiged int[/font] is also too small. Absolute time values should be [font=courier new,courier,monospace]int64[/font] or [font=courier new,courier,monospace]double[/font].

N.B. if you're using that code from multiple threads, the static variable will cause problems.

Share this post


Link to post
Share on other sites
FYI timeGetTime jumps in very large increments (esp relative to QPC calls)

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!