CTimer::CTimer() // this code mirrors the Reset() function, pretty much, so I won't include that here.
: m_LastFrame(0), m_Frequency(0), m_Elapsed(0)
{
m_LastTick.QuadPart = 0;
m_CurrTick.QuadPart = 0;
m_NumUpdates.QuadPart = 0;
LARGE_INTEGER Freq;
QueryPerformanceFrequency(&Freq);
m_Frequency = double(Freq.QuadPart);
QueryPerformanceCounter((LARGE_INTEGER *)&m_CurrTick);
}
void CTimer::Update()
{
m_LastTick = m_CurrTick;
QueryPerformanceCounter((LARGE_INTEGER *)&m_CurrTick);
m_LastFrame = (m_CurrTick.QuadPart-m_LastTick.QuadPart)/m_Frequency;
m_NumUpdates.QuadPart++;
m_Elapsed += m_LastFrame;
}
Time based movement a flawed concept?
Author
Alright, I see a never ending stream of posts with people complainging that their time based movement is jerky or otherwise performs poorly. Usually it comes down to people saying "well it should work but it doesn't" And it works in some programs but mysteriously not in others
I recently implimented it into mine and it works except it causes all the graphics (not just the object affected by time based movement) to freeze up for a brief period occationally (causing the spaceship to jump forward as it should). But the whole point of time based movement is to get smooth consistent movement at different frame rates. Is calculating time use a lot of resources or something? But just so you know my code isn't weird here it is (it's pretty standard)
Anyone have any insight? Remember my whole program freezes for a fraction of a second from time to time (which translates to jerkiness) it didn't do this until I added this time based movement code.
QPC has a major (and well known) bug that causes it to jump forward by a comparatively massive amount.
The way to deal with this is to set a maximum delta with timeGetTime. I don't have the MSDN link around, unfortunately; I'm sure someone can find it.
The way to deal with this is to set a maximum delta with timeGetTime. I don't have the MSDN link around, unfortunately; I'm sure someone can find it.
Just average out your delta time over the previous n frames, rather than just the previous one. Oh yeah, and make sure your delta doesn't go over or under certain limitations.
timeGetTime() is an extremely flawed (drift wise) timer. It can be as much as 15 ms off. Comparatively speaking, QPF is rarely off by more than a few nanoseconds.
Time based movement is definitely the way to go, but, yes, calculating accurate timing intervals can be a pain in the ass on many systems where QPF doesn't perform correctly.
Time based movement is definitely the way to go, but, yes, calculating accurate timing intervals can be a pain in the ass on many systems where QPF doesn't perform correctly.
Author
Quote:Original post by red_sodium
Just average out your delta time over the previous n frames, rather than just the previous one. Oh yeah, and make sure your delta doesn't go over or under certain limitations.
Can someone give me an example of what this might look like as source? I'm using C++ of course
Quote:
Can someone give me an example of what this might look like as source? I'm using C++ of course
I imagine it would look something like this:
ctimer{ //blah blah float mAvtimearr[5]; float mAvTime; int mArrP;}ctimer::ctimer(){ mArrP = 0;}float ctimer::AddTimeToArr(float thisdelta){ if(thisdelta < mintime) thisdelta = mintime; elseif(thisdelta > maxtime) thisdelta = maxtime; mAvtimearr[mArrP++] = thisdelta; mArrP%=5; mAvTime = mAvtimearr[0] + mAvtimearr[1] + mAvtimearr[2] + mAvtimearr[3] + mAvtimearr[4]; mAvtime /= 5.0f; return mAvTime;};float ctimer::Initialise(float deltatime){ for(int i = 0; i < 5; i++){ mAvtimearr = deltatime; }}I hope that helps, haven't used the averaging approach though so I cannot vouch for its effectiveness. I suggest you read the article that I linked in my previous post for a well designed high resolution timer.
It's hard to get smooth movement using timeGetTime() - it has very poor resolution on most systems - typically 10ms. The QueryPerformanceCounter() jumping bug does exist but it's not as common as people sometimes make out, be aware of it but in most cases the problem will lie elsewhere. There are a whole bunch of potential reasons for jerky movement.
The concept isn't flawed. The resources the implementation relies on is.
I have never had a problem with it. I think it only seems like a problem because you only hear from the people who have problems (usually not even from the counter), not from the countless times more who have had success.
I have never had a problem with it. I think it only seems like a problem because you only hear from the people who have problems (usually not even from the counter), not from the countless times more who have had success.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
