|
Lachlan87
Moderator
USA
160 Posts |
 Posted - Jun 11 2004 : 3:00:28 PM
|
timeGetTime seems to work fine, but maybe I'll switch to QueryPerformanceCounter anyway, if it's that much faster. What is really strange to me is how much of a difference there is between GetTickCount and timeGetTime. I'm only drawing a handful of images, and I have a pretty powerful computer by many peoples standards (the only reason timeGetTime gives me 85 is because that's what my monitors refresh rate is set at). It seems to me even if it was a congested thread, it wouldn't make that much of a difference. The cpu usage is the same no matter which I use. . . maybe I'll try it on a different computer and see what happens.
|
 |
|
|
Eric Coleman
Gladiator
USA
811 Posts |
Posted - Jun 11 2004 : 5:06:49 PM
|
If "GetTickCount" returns "ticks", what exactly are the time units of a single tick? It might be that a "tick" is just an incrimented number whenever the system timer is updated. The discrepency that you experienced is just really odd, and I can't think of any other way to explain it.
The precision of timeGetTime is on the order of 10 ms, which is 1/100th of a second. Considering that a game running at 60 FPS must complete a single frame in 1/60th of a second, then for timing purposes (animations and stuff) timeGetTime isn't exactly the best thing to use because the precision of the time step is relatively small compared with the size of the frame time step. |
|
|
|
Lachlan87
Moderator
USA
160 Posts |
Posted - Jun 11 2004 : 6:18:48 PM
|
According to MSDN, GetTickCount's "return value is the number of milliseconds that have elapsed since the system was started."
Sounds the same as timeGetTime to me. . .
Tested it on my brother's computer, and had the same result: 85 FPS for timeGetTime, 20 FPS for GetTickCount. Has anyone else noticed this with their games? |
Edited by - Lachlan87 on Jun 11 2004 6:38:02 PM |
|
|
|
Eric Coleman
Gladiator
USA
811 Posts |
Posted - Jun 11 2004 : 6:43:12 PM
|
| Is the FPS value when using GetTickCount wrong or does it slow down the game to 20 FPS? I only ever used QueryPerformanceCounter or timeGetTime, so I never noticed the getTickCount problem. |
|
|
|
game_maker
Knave
Saudi Arabia
83 Posts |
|
|
Eric Coleman
Gladiator
USA
811 Posts |
Posted - Jun 11 2004 : 7:28:59 PM
|
Here is some more code. Just copy and paste this on a form named "form1" with a command button named "command1"
This code tests the resolution of the different timers. It calls the time function, and then repeatedly calls the time function untill the returned value changes. The difference between the two values shows the precision of the timer function. The Timer function seems to be slightly more precise, but less accurate on my system. It is more prone to fluctuations returning either it's time step or it's time step times 2.
Private Declare Function GetTickCount Lib "kernel32" () As Long
Private Declare Function timeGetTime Lib "winmm.dll" () As Long
Private Declare Function QueryPerformanceFrequency Lib "kernel32" (lpFrequency As Currency) As Long
Private Declare Function QueryPerformanceCounter Lib "kernel32" (lpPerformanceCount As Currency) As Long
Private Sub Command1_Click()
Form1.Cls
Form1.CurrentX = 0: Form1.CurrentY = 0
Dim s As Long, t As Long
Dim u As Single, v As Single
Dim Freq As Currency, x As Currency, y As Currency, sngResult As Single
s = GetTickCount()
Do
t = GetTickCount()
If t - s > 0 Then Exit Do
Loop
Form1.Print (t - s) / 1000
s = timeGetTime()
Do
t = timeGetTime()
If t - s > 0 Then Exit Do
Loop
Form1.Print (t - s) / 1000
u = Timer
Do
v = Timer
If v - u > 0 Then Exit Do
Loop
Form1.Print (v - u)
QueryPerformanceFrequency Freq
QueryPerformanceCounter x
Do
QueryPerformanceCounter y
If y - x > 0 Then Exit Do
Loop
sngResult = (y - x) / Freq
Form1.Print Format$(sngResult, " 0.000000000000")
End Sub
after writing this I found the following from microsoft, it seems they did the same thing I just did, http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/support/kb/articles/Q172/3/38.asp&NoWebContent=1
|
|
|
|
Lachlan87
Moderator
USA
160 Posts |
Posted - Jun 12 2004 : 10:03:10 AM
|
One thing I forgot to mention, and may be key to my problem, is that I am using VB.Net, which doesn't always get along with the windows API so well. game_maker's code gives me about 1187 for both values when I put it in VB6--but when I convert it to VB.Net like so:
Private Declare Auto Function timeGetTime Lib "winmm.dll" () As Long
Private Declare Auto Function GetTickCount Lib "kernel32" () As Long
Dim numFrames1 As Long, FirstTime1 As Long, FPS1 As Long
Dim numFrames2 As Long, FirstTime2 As Long, FPS2 As Long
Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
Me.Show()
Do
numFrames1 = numFrames1 + 1
If timeGetTime - FirstTime1 > 999 Then
FPS1 = numFrames1
FirstTime1 = timeGetTime
numFrames1 = 0
End If
numFrames2 = numFrames2 + 1
If Math.Sign(GetTickCount - FirstTime2 - 999) + 1 Then
FPS2 = numFrames2
FirstTime2 = GetTickCount
numFrames2 = 0
End If
Application.DoEvents()
Me.Text = "FPS1 = " & FPS1 & " " & "FPS2 = " & FPS2
Application.DoEvents()
Loop
End Sub
I get about 85203 for timeGetTime and about 21843 for GetTickCount.
It doesn't make any sense to me. I would instinctively guess that VB.Net wasn't converting the data types correctly, but since both timeGetTime and GetTickCount return a Long, it ought to make the same error on both, if it truely was a conversion error. Besides, VB.Net's long can hold much greater values that VB6's, so it seems like there would be no problem.
But that was my reasoning using logic, which doesn't apply when we're working with a product made by Microsoft. I changed GetTickCount to As Integer, and Voila! Now they both return 85 thousand. For some perverted reason GetTickCount wouldn't convert right and timeGetTime would.
But that still leaves the question: Why are the values I get in VB.Net so wildy different than the values I get in VB6? I can't decide if VB.Net is too high, or if VB6 is too low, but they can't both be right! Can they? When logic as I understand it fails, I start to wonder . . .
And just to confuse things a little more, Eric's VB6 code returns the same values for timeGetTime and GetTickCount as my VB.Net verison of his code---without changing any longs to integers!! |
|
|
|
Sr. Guapo
Swordmaster
USA
272 Posts |
Posted - Jun 12 2004 : 10:43:34 AM
|
| It is possible that DoEvents in VB6 doesn't take as long as Application.DoEvents() in VB.NET... IT doesn't seem likely, but I don't know what else it would be... |
Edited by - Sr. Guapo on Jun 12 2004 10:57:50 AM |
|
|
|
Lachlan87
Moderator
USA
160 Posts |
|
|
Eric Coleman
Gladiator
USA
811 Posts |
Posted - Jun 12 2004 : 4:34:17 PM
|
| I'm surprised that code even works at all for you. A LONG data type in VB6 isn't the same thing as a LONG data type in VB.NET. When declaring windows API calls in VB.NET you have to make sure the data type size is the same as what's returned and what's used as parameters, otherwise you'll be reading from memory that you're not supposed to, and VB.NET will convert stuff that it shouldn't be converting. |
|
|
|
game_maker
Knave
Saudi Arabia
83 Posts |
|
|
Lachlan87
Moderator
USA
160 Posts |
Posted - Jun 12 2004 : 10:14:41 PM
|
quote:
A LONG data type in VB6 isn't the same thing as a LONG data type in VB.NET
That I understood. I had thought that VB.Net performed the conversions automatically, but I guess I must have been thinking of the other way of using the windows API (dllImport or something like that).
game_maker: I realize my "test" was backwards and not particularly accurate, but even still, I thought it was safe to infer that GetTickCount was faster.
Oh, well. At least my problem was fixed, and I managed to learn some things. . . but like Eric said, I still wonder why timeGetTime and other API functions work if VB.Net isn't auto converting things. |
|
|
|
Sr. Guapo
Swordmaster
USA
272 Posts |
Posted - Jun 12 2004 : 11:08:47 PM
|
quote:
I still wonder why timeGetTime and other API functions work if VB.Net isn't auto converting things.
Maybe they do that now in VB .NET to discourage the use of variants... Dunno...
What if you defined the GetTickCount as an "Int32" in .NET, I think that is all that a long is, a 32 bit integer. Correct me if I'm wrong. |
|
|
|
game_maker
Knave
Saudi Arabia
83 Posts |
Posted - Jun 13 2004 : 12:35:04 AM
|
in VB.6 :
Long is 4 byte
so it's :
2^(8 * 4) = 4294967296
we dived it by 2 (to get plus and minus numbers)
2^(8 * 4) / 2 =
2147483648 to 2147483648
we save one bit to determine (minus or plus sign)
-2147483648 to 2147483647
we need to find the same properties in VB.Net :
in VB.Net
Integer here defined as 4 byte and accept minus so it's the same definition in VB.6 Longs ... as you did !!! why microsoft did this ,,, if the have to change something then they should define something that have (integers in 8 bytes) and not changing everything
and for Long it's = 8 byte as Double in vb.6
and the definition is not stable ,,it depens on wither it's 32-bit or 64-bit |
|
|
|
Dan
Squire
United Kingdom
29 Posts |
Posted - Jun 13 2004 : 03:54:07 AM
|
quote:
Integer here defined as 4 byte and accept minus so it's the same definition in VB.6 Longs ... as you did !!! why microsoft did this ,,, if the have to change something then they should define something that have (integers in 8 bytes) and not changing everything
I think it has somthing to do with the fact the .NET framework is made up of the supposed 'Best bits' of VB and C. I believe C#'s Int/long variable types are 4 / 8 bytes respectivly. so it came to a toss up between who keeps the type definitions and C# won... makes sense really - Its easier to put a small parcel in a a big box, a wee bit trickier to do the reverse :)
|
|
|
|
FPS Counter
