How To: Exceed 49day uptime using GetTickCount or QueryPerformanceCounter in VB6

[ben_fb]

This code will use QPC over GTC unless QPC is not supported on the users computer. However, computers which do not support QPC are almost extinct so the GTC code is mostly there as a backup.

Tested and works. Thanks to vuther for clarifying some stuff for me.

Code: [Select]


Private Declare Function GetTickCount Lib "kernel32.dll" () As Long
Private Declare Function QueryPerformanceCounter Lib "kernel32" (lpPerformanceCount As Currency) As Long
Private Declare Function QueryPerformanceFrequency Lib "kernel32" (lpFrequency As Currency) As Long

Public Function GTC() As Currency
Static LastTick As Currency, BonusTick As Currency
Dim sysTick As Currency, sysFrequency As Currency

    If QueryPerformanceCounter(sysTick) And QueryPerformanceFrequency(sysFrequency) Then
        GTC = Int(sysTick / sysFrequency * 1000)
    Else
        GTC = GetTickCount
        If GTC < 0 Then GTC = GTC + 2147483468
        'set the difference, longer its been negative higher the number is returned.
        If BonusTick = 0 Then LastTick = GTC - 1
        'set the initial last tick
        If LastTick > GTC Then
            BonusTick = BonusTick + (2147483467 - LastTick) + GTC
            'this suggest the tick rolled over either from positives to negatives or negatives to positive
        Else
            BonusTick = BonusTick + GTC - LastTick
        End If
        'if last tick is greater than g t c then i subtract last tick from the max g t c value, then
        'add the amount g t c has passed the max negative
        LastTick = GTC
        'store last
        GTC = BonusTick
    End If
   
End Function



[l2k-Shadow]

your code will not work as expected if you execute your program while the computer was already 49+ days up. Consider using the API calls QueryPerformanceFrequency and QueryPerformanceCounter instead of GetTickCount.

[ben_fb]

your code will not work as expected if you execute your program while the computer was already 49+ days up. Consider using the API calls QueryPerformanceFrequency and QueryPerformanceCounter instead of GetTickCount.

Why would it not work, and have you tried using this on a machine with 49+ days? I don't have one on hand but I tested on one that started in negatives and it worked fine. Please provide more information so that if there is a problem it can be looked into.

PS: I read there are many other problems that can occur with QueryPerformance API.

[Myst]

Because GetTickCount wouldn't be able to tell that the system has been running more than 49+ days because it has already reset to zero and you don't have a previous GTC to compare to before it reset to zero.
Hence using QueryPerformanceFrequency/QueryPerformanceCounter is better and more accurate

[DavidK]

I have a feeling you guys didn't actually review the code before opening your mouths. If you were to have done so, you would've seen his variables were static and he is storing the previous gettickcount and adding it to the current one.

[Myst]

that's all fine and dandy, but the API itself still can't tell you that the system has been running 49+ days (as my post mentioned) because its returns a Long. So the highest number it can give you will be 2147483647 before going negative. 
So if your system has been running already for 49+ days, the above code has no way of knowing that since the code has no cached GTC of the GTC before it went to zero.
In simpler terms the code above has no way of knowing how many times GTC has been rolled when on a system already on 49+ days

edit: the point is system uptime, the above code would work fine for bot uptime, but the queryperformance apis are still better to use for both.

[pikachu]

You guys are funny

[ben_fb]

I take that difference and add it onto 'BonusTick' which is the total tickcount except only for the bot

I never said it would keep the uptime of your computer, computer uptime is not really an important issue. Since a lot of bots rely on GetTickCount for queue and other various events this code works, and works just as well as QueryPerformance. Also QueryPerformance has been known to cause problems with certain machines.

for TLDR, the code works.

[Myst]

Why would it not work, and have you tried using this on a machine with 49+ days? I don't have one on hand but I tested on one that started in negatives and it worked fine. Please provide more information so that if there is a problem it can be looked into.

PS: I read there are many other problems that can occur with QueryPerformance API.

Was merely addressing your above question on why it wouldn't work.  And there are only some issues, tbh which are real negligible, concerning this is to do with uptime for a bnet bot. 
QP is the better API to use and more efficient in using than GTC as an Uptime function for a bot.

[ben_fb]

yeah perhaps. there is a potential problem with this code I just noticed as well. fixing it, reposting after.

There is a lot of things stating that if your core throttles it's speed then QPC can be inaccurate, does measuring the frequency and applying that solve this problem?

[ben_fb]

I second guessed myself, I think the code is fine. Only one way to find out!
That covers the bot, and if you're concerned with system uptime you can just call QPC which I may add as an additional command.

[Myst]

yes you use QPC in conjuction with QPF
http://msdn.microsoft.com/en-us/library/aa457094.aspx

[ben_fb]

seems QPC can vary depending on which core it decided to use. Also for cores that speed-step (both mine do) it can be slightly inaccurate but nothing terrible to worry about. i'll switch to qpc at some point.