Re: alternative to gettickcount



Mike Williams wrote:
I think everyone knows that technique (waiting for a change in the clock
before proceeding with a timing test). It's almost an "industry standard"
and I'm sure it is what many people do, even in the kitchen when they are
timing baking periods for steak and kidney pies!,

Sorry, no offense. Just threw it in for the thread's sake. <g>

but it will NOT cut the
error in half, as you have suggested.

Yeah, that's what I get for multitasking. My mistaken impression offered.

How on earth did you arrive at that [must use timeBeginPeriod at least
a dozen milliseconds before calling timeGetTime?] I've never heard of
this.

Well I don't know what system you are running Karl, but in general you need
to accept the fact that on many (probably most) Windows systems the
resolution of timeGetTime does NOT default to one millisecond.

Right. It's an XP system at the moment, and the resolution appears to be the
bog-standard ~15.something milliseconds:

Public Sub Main()
Dim e1 As Long, e2 As Long
Dim n
' Call timeBeginPeriod(1)
e1 = timeGetTime
Do
e2 = timeGetTime
If e1 <> e2 Then
Debug.Print e2 - e1
e1 = e2
n = n + 1
End If
Loop While n < 5
End Sub

Returns:

16
15
16
16
15

In fact on
many machines it is something of the order of 5 or 10 milliseconds or so. In
Win95 it is one millisecond, and it also appears to be one millisecond in
Vista (from my own experience) but in other versions (NT/2K/XP I think) it
is something in the region of five milliseconds, or perhaps more. I can't
remember what it is in Win98.

Me either. I know it varies.

My suggestion of "a dozen milliseconds" was
of course just a "tongue in cheek" remark, but what I meant is that you
should set the resolution *and allow the new resolution to lock into place*
before you begin timning, so a dozen milliseconds seemed to fit the bill!

Uncommented the timeBeginPeriod above, and these are the new results:

15
16
1
1
1

Interesting! I need to update my stopwatch class.

The other point (which I alluded to in my earlier post and to which you seem
to have taken offence) is that in systems where timeBeginPeriod is necessary
you need to do it *before* you begin timing.

No offense taken, either. I agree, of course, with this point.

For example, on a system where
the default resolution of timeGetTime is 5 or perhaps 10 milliseconds and
you do:

Dim t1 As Long, t2 As Long
timeBeginPeriod 1
t1 = timeGetTime
' some code here
t2 = timeGetTime

. . . you will NOT get a resolution of one millisecond for the timed code.
That's why I said you need to use timeBeginPeriod some milliseconds *before*
you begin the timing period, to allow the new resolution to "click into
place" before the timed code begins.

Agreed. I'm gonna stick a Do-Loop into my class, much like the above.

In your own specific case where you
have said that you always "wait for a new clock" before you begin the timed
code then of course it will usually be okay,

Not really. Note that in my test, here, it was actually the third change where the
new resolution kicked in.

but in cases where you do not
do that then you will get an error in the result. So, my own suggestion of
using timeBeginPeriod in the Form Load event (or whatever event runs at
startup) is a good one, and I stick by it.

You Brits crack me up sometimes. :-)

You can argue with me if you like
(I often enjoy a good argument) but please don't "look down on me", as you
appear to have done in your own response, and don't say things like "How on
earth did you arrive at that? I've never heard of this". You'll only get my
back up ;-)

Actually, you really caught me off-guard there. (Read it as a exclamatory statement
of surprise, more than an accusatory "wtf, man?") Makes sense, on reflection, but I
thought I'd been around all the issues I'd have to have dealt with, a good decade or
more ago. Like I said, no offense intended or taken. We're all here to learn, eh?

Thanks... Karl
--
..NET: It's About Trust!
http://vfred.mvps.org


.



Relevant Pages

  • Re: Accurate time measurement
    ... Actually getTickCount has a resolution of somewhere between 10 and 15 ... milliseconds on most machines. ... An alternative would be to use timegetTime. ... milliseconds), except on Win98 where it usually defaults to one millisecond. ...
    (microsoft.public.vb.general.discussion)
  • Re: alternative to gettickcount
    ... m_StartTime = timeGetTime() ... It's almost an "industry standard" and I'm sure it is what many people do, even in the kitchen when they are timing baking periods for steak and kidney pies!, but it will NOT cut the error in half, as you have suggested. ... There is no way that you can say you have a result to a resolution of within half a millisecond on a one millisecond timer using that technique! ... It will avoid unneccessarily generating errors larger than they really need to be, but it will not improve the overall resolution of the basic timing device! ...
    (microsoft.public.vb.general.discussion)
  • Re: VB6 code runs different speeds on different PCs
    ... As you've discovered, the minimum Sleep period can be different on different machines (5 milliseconds on my own WinXP system, but longer than that on others I think). ... You can get whatever "game rate" you want in a closed loop of course, by checking a high resolution timing source. ... If I were you I would use a proper Timer with a higher resolution that the standard VB Timer and run your entire game in the Timer event. ... Admittedly, updating their positions more than once every ten milliseconds does appear to give smoother animation (even though the video frame rate simply cannot draw a new frame at a rate greater than every 10 milliseconds,or so, depending on your display settings) because it tends iron out the differences more. ...
    (microsoft.public.vb.general.discussion)
  • Re: Time::HiRes usleep on windows strange behaviour...please please help!!
    ... Your timer resolution will be equal to the time duration between system ticks. ... your maximum resolution will be ten milliseconds. ... Rather pointless to pursue faster speeds for internet transaction ...
    (comp.lang.perl.misc)
  • Re: timing VBA execution
    ... Not sure 10 milliseconds is enough resolution, ... > OSAX is Open Scripting Architecture eXtension - also called a Scripting ... > Since the PowerPC has a microsecond timer available, ...
    (microsoft.public.mac.office.excel)

Loading