Time algorithms C++ ?

[Redee]

Ok I understand, thank you.

Yes I newbie but there says to minimal use in game!
>>
http://msdn.microsoft.com/en-us/library/windows/desktop/ee417693.aspx

Nevertheless, developers should attempt to have their games call QueryPerformanceCounter as little as possible to avoid any performance penalty.

Yes now I know need only 1 call, alright, no problem with QPC now )).

timeGetTime() and GetTickCount() as old reliable solution to measure time.
Else this needs link Winmm.lib (if you instal MS Visual Studio can find at C:\Program Files\Microsoft SDKs)
And at windows system32(64) path will be Winmm.dll
For example its using famous old game Quake3.

[Hapax]

http://msdn.microsoft.com/en-us/library/windows/desktop/ee417693.aspx

Nevertheless, developers should attempt to have their games call QueryPerformanceCounter as little as possible to avoid any performance penalty.

can be called several hundred times per frame without any noticeable impact

[Redee]

timeGetTime() faster but no need thats amount of calls ))
Simple test >

(click to show/hide)

#include "iostream"
#include "windows.h"
using namespace std;

void main()
{
        DWORD start, end;
        // amount of iterations
        int n = 10000000;

        start = timeGetTime();
        cout << "Start time: " << start << endl;
        for(int x=0; x < n; x++)
        {
                timeGetTime();
        }
        end = timeGetTime();
        cout << "End time:" << end << endl;
        cout << "Elapsed time(milliseconds): " << (end - start) << endl;
        cout << "Elapsed time(seconds): " << (double)(end - start)/1000 << endl;
        cout << "---" << endl;

        ////////////////////////
       
        LARGE_INTEGER freq, check;
        QueryPerformanceFrequency(&freq);
        start = timeGetTime();
        cout << "Start time: " << start << endl;
        for(int x=0; x < n; x++)
        {
                QueryPerformanceCounter(&check);
        }
        end = timeGetTime();
        cout << "End time:" << end << endl;
        cout << "Elapsed time(milliseconds): " << (end - start) << endl;
        cout << "Elapsed time(seconds): " << (double)(end - start)/1000 << endl;
}

[Nexus]

What's your point? Which time measurement technique you use depends on the needed resolution...

[Redee]

Nexus thank you, your advices very helpful.

In main game logic - I have global gameTimeCounter variable which refresh every frame.
All objects compare with this variable.
If more then minimal value after comparison - object do my action.

timeGetTime() is faster.
QPC is much more powerful but have some bugs.

I again here and very sorry - on old windows systems can be bugs with QPC.
http://msdn.microsoft.com/en-us/library/windows/desktop/dn553408.aspx

Windows XP and Windows 2000

QPC is available on Windows XP and Windows 2000 and works well on most systems. However, some hardware systems' BIOS didn't indicate the hardware CPU characteristics correctly (a non-invariant TSC), and some multi-core or multi-processor systems used processors with TSCs that couldn't be synchronized across cores. Systems with flawed firmware that run these versions of Windows might not provide the same QPC reading on different cores if they used the TSC as the basis for QPC.

Here also explains about possible issues.
http://www.virtualdub.org/blog/pivot/entry.php?id=106

(click to show/hide)

When it comes to high-precision timing on Windows, many have gotten used to using the CPU's time stamp counter (TSC). The time stamp counter is a 64-bit counter that was added to most x86 CPUs starting around the Pentium era, and which counts up at the clock rate of the CPU. The TSC is generally readable via the RDTSC instruction from user mode, making it the fastest, easiest, and most precise time base available on modern machines.

Alas, it is rather unsafe to use.

The first problem you quickly run into is that there is no easy way to accurately and reliably determine the clock speed of the CPU, short of perhaps doing calibration over a longish period of time. Sometimes you don't need super accuracy or only need to deal with timing ratios, in which this doesn't matter. However, you're still screwed when you discover that on CPUs with speed switching, the speed at which the TSC counts will change when the CPU speeds up or slows down, which makes the TSC's rate swing all over the place. And if this weren't enough, the TSC is not always synchronized on dual-core or SMP systems, meaning that the reading from the TSC will jump back and forth by as much as 0.2ms as the kernel moves your thread back and forth across the CPUs. Programs which do not have adequate safety protection may be surprised when time momentarily runs backwards.

For reasons like these, Microsoft now recommends that you use QueryPerformanceCounter() to do high-precision timing. What they don't tell you, though, is that QPC() is equally broken.

The documentation for QueryPerformanceFrequency() says that not all systems have a high-performance counter. Truth be told, I've never seen a system that didn't support QPF/QPC, including ones running Windows 98, NT4, and XP. However, the timer that is used can vary widely between systems. On Win9x systems that I've seen, QPF() returns 1193181 -- which looks suspiciously like the clock rate of the venerable 8253/8254 timer. On a PIII-based Windows 2000 system, I got 3549545, which happens to be the frequency of the NTSC color subcarrier, but is probably just a factor of a common clock crystal used by some chipset timer. And I've also seen the CPU clock speed show up, or CPU clock divided by 3.

Some of these timers used for QPC also have bugs.

When I was looking at some anomalous capture logs from one of my systems, I noticed that the global_clock values from the capture subsystem, which were recorded in the capture log, occasionally jumped forward or backward by a few seconds compared to the video capture clock. (While video capture drivers are notoriously flaky, there were no gaps in the video and I'm pretty sure my PlayStation 2 didn't burp for three seconds.) When I tried Windows XP x64 Edition, the HAL used the CPU TSC for QueryPerformanceCounter() without realizing that Cool & Quiet would cause it to run at half normal speed. And recently, I've had the pleasure of seeing a dual-core system where use of the TSC exposed QPC-based programs to the same CPU-mismatch bug that RDTSC incurred. So, realistically, using QPC() actually exposes you to all of the existing problems of the time stamp counter AND some other bugs.

So, what to do?

I switched VirtualDub's capture subsystem from QueryPerformanceCounter() to timeGetTime(). I had to give up microsecond precision for only millisecond, but it's more reliable. If you don't really need high precision, you can use GetTickCount(), which has terrible precision on Win9x (55ms), but it's reliable, and it's fast, since it just reads a counter in memory. If you're a user suffering from this problem, you can try fixing the problem by adding /usepmtimer to the end of the boot.ini entry, which switches QPC() to use an alternate timer (usual disclaimers apply; back up data before trying; no purchase necessary; void where prohibited).

And here a little bit explains about bugs of QPC.
http://stackoverflow.com/questions/14363398/queryperformance-counter-in-multicore-systems-with-variable-clock-speeds

Who can use new vers. of MSVS (from 2012 and higher) - use <chrono> library for time measure.
If develop on old visual studio for old windows versions also - my advice use timeGetTime().