Sign in to follow this  

Issue with QueryPerformanceCounter

This topic is 2049 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:

[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;
}
[/CODE]

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:
[CODE]
actor->m_position += (actor->m_velocity * g_pApp->GetTiming()->lastFrameDurationS);
[/CODE]

Here is the spec of the problematic PC's processor:
[url="http://ark.intel.com/products/39718/Intel-Xeon-Processor-W3520-(8M-Cache-2_66-GHz-4_80-GTs-Intel-QPI)"]http://ark.intel.com...-GTs-Intel-QPI)[/url].

Any idea would be apreciate.
Thanks.

Share this post


Link to post
Share on other sites
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 ([i]it's ok for delta time values[/i]), 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

This topic is 2049 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this