Timers: Myth of truth?

[Dude1]

Is it true that windows 95 and 98 have a different timing resolution than later windows? So if I were to make a program which uses a timer under windows 98 and then run that program on Win2k or XP, it would be either to slow or to fast? Is this true, or is this kind of a myth?

Thanks!

[Zaei]

Timers under the Win9X kernel are less accurate then the WinNT kernel. Win9X timers are only accurate to about 50ms, while WinNT timers are about 15ms-20ms (still not very accurate).

For games, timers are NOT recommended. Just save yourself a headache, and dont use them.

Z.

[jim mcnamara]

I disagree.

Zaei is sort of right.

Timers can be inaccurate. True statement.

Timers in general under a given OS are xMS inaccurate. Not necessarily true.

Timers suffer from confounding factors. Without going into all of the problems, the best available timers are those that have the highest resolution. ie., the fewest confounding factors.

Here's a VB example of a VERY high res timer

Option Explicit

Private Const TIME_ONESHOT = 0  'Event occurs once, after uDelay milliseconds.
Private Const TIME_PERIODIC = 1  'Event occurs every uDelay milliseconds.
Private Const TIME_CALLBACK_EVENT_PULSE = &H20  'When the timer expires, Windows calls thePulseEvent function to pulse the event pointed to by the lpTimeProc parameter. The dwUser parameter is ignored.
Private Const TIME_CALLBACK_EVENT_SET = &H10  'When the timer expires, Windows calls theSetEvent function to set the event pointed to by the lpTimeProc parameter. The dwUser parameter is ignored.
Private Const TIME_CALLBACK_FUNCTION = &H0   'When the timer expires, Windows calls the function pointed to by the lpTimeProc parameter. This is the default.
Private Declare Function timeKillEvent Lib "winmm.dll" (ByVal uID As Long) As Long
Private Declare Function timeSetEvent Lib "winmm.dll" (ByVal uDelay As Long, ByVal uResolution As Long, ByVal lpFunction As Long, ByVal dwUser As Long, ByVal uFlags As Long) As Long
Private MMTimer As Long
Private hMMTimer As Long

Sub InitTimer()
    hMMTimer = timeSetEvent(1, 0, AddressOf TimerProc, 0, TIME_PERIODIC Or TIME_CALLBACK_FUNCTION)
End Sub

Sub KillTimer()
    timeKillEvent hMMTimer
End Sub

Function GetTimeElapsed() As Double
    GetTimeElapsed = CDbl(MMTimer) / 1000
    MMTimer = 0
End Function

Sub TimerProc(ByVal uID As Long, ByVal uMsg As Long, ByVal dwUser As Long, ByVal dw1 As Long, ByVal dw2 As Long)
On Error GoTo ErrorHandle
    MMTimer = MMTimer + 1
    Form1.Label1.Caption = CStr(MMTimer)
    Exit Sub
ErrorHandle:
MMTimer = 0
End Sub

Does that mean you should use this? I can't answer that. Zaei says no. I don't write games, just OS and database components.
I no longer work in Windoze at all.

Basically, no one person can know it all.

[Zaei]

When it comes to SetTimer/KillTimer (the VB Timer control), the inaccuracies between 9X and NT are about what I said.

When It comes to not using timers for games, the reason is not because of the inaccuracies, but because of how they work. Basically, you have a procedure running every so often. For simple games, this might be fine (though you are stuck with a flat frame rate), when you need the performance (and the control), timers fail.

It is akin to calling Render() on a WM_PAINT message. It seems really simple, but when you get down to it, there might be unforseen consequences (in the example above, you get a WM_PAINT when the window is shown, and DX might not have been initialized).

Z.