Uhrzeit genauer als mit ElapsedMilliSeconds()?

[D4uS1]

Ich habe einen Countdown erstellt, welcher allerdings mit ElapsedMIliseconds() läuft und sehr ungenau ist. Es wird häufig eine oder 2 Sekunden vergessen. Gibt es eine genauere Methode?

Hier meine Uhr:

Code: Alles auswählen

Repeat
...
...
...

  If StartZeitGesetzt = 0
   StartZeit = ElapsedMilliseconds()
   StartZeitGesetzt = 1
   Minuten = 3
   Sekunden = 30
  EndIf
   Uhrzeit = ElapsedMilliseconds() - StartZeit
    StartDrawing(ScreenOutput())
    Box(950, 700, 52, 22, 0)
    Box(951, 701, 50, 20, RGB(255, 255, 255))
    DrawingMode(3)
    DrawText(957, 705, StrQ(Minuten)+" : ", 0)
    DrawText(970, 705, StrQ(Sekunden), 0)
    StopDrawing()
 EndIf
 
If Not Uhrzeit%1000
 Sekunden -1
EndIf
If Sekunden = 0
 Minuten -1
 Sekunden = 59
EndIf

...
...
...
Until Beenden = 1

[Kaeru Gaman]

es gibt zwar genauere methoden als ElapsedMilliseconds(),
( TimeGetTime_() oder QueryHighPerformanceTimer_() [oder so ähnlich] )
aber man kann schon einiges rausholen, wenn man ElapsedMilliseconds() effektiv einsetzt.

Beispiel:

Code: Alles auswählen

OpenWindow(0,0,0,200,100,"Timer-Demo")
CreateGadgetList(WindowID(0))
TextGadget(0,20,20,160,20,"",#PB_Text_Center|#PB_Text_Border)
sec = 1
min = 2
timer = ElapsedMilliseconds()
Repeat
  EvID = WaitWindowEvent(100)
  If ElapsedMilliseconds() > timer
; ****************
    timer + 1000
; ****************
    sec -1
    If sec < 0
      sec = 59
      min -1
    EndIf
    SetGadgetText(0,"-- "+Right("0"+Str(min),2)+":"+Right("0"+Str(sec),2)+" --")
  EndIf
Until EvID = #PB_Event_CloseWindow

dadurch, dass die variable timer nicht auf einen aktuellen wert von ElapsedMilliseconds() gesetzt wird,
sondern einfach 1000 addiert, kann sich die ungenauigkeit von ElapsedMilliseconds() nicht aufaddieren.

[AND51]

@ Schweigender Frosch: Meinst du vielleicht QueryPerformanceCounter_()?

@ Topic: Für einen einfachen Timer, tendiere ich zur API: SetTimer_() ruft eine benutzerdefinierte Procedure in frei wählbaren Intervallen immer wieder auf (bis man KillTimer_() benutzt).
Dann muss man sich nicht selber abmühen und einen Timer schreiben.

[ts-soft]

>> Für einen einfachen Timer, tendiere ich zur API: SetTimer_()
Für mich sieht es nicht so aus, als wenn ein Fenster erstellt wird. Sieht er
nach so Screeny zeugs, da ist der API-Timer falsch, der HighResTimer oder
MultiMedia Timer ist für Screenies.

Aber es kann auch ein Windowed Screen werden, das sind diese nicht
Testbaren, und deshalb unnützen Beispielpostings.

[AND51]

Stimme dir zu, ganz falsch finde ich SetTimer_() aber nicht. Kann man ja z. B. für Berechnungen von Figuren/Raumschiffen/Gegnern/Schüssen/etc. verwenden, welche in einer Procedure ausgelgert sind.

SO gesehen hast du aber Recht, eines der anderen Mittel ist vorzuziehen.

[ts-soft]

>> SO gesehen hast du aber Recht, eines der anderen Mittel ist vorzuziehen.
Wenn er keinen FensterhWnd hat, wirds auch kaum anders gehen. SetTimer_
mit 0 als hWnd halte ich nicht für ratsam.

[AND51]

Dann würd ich eben ein unsichtbares Fenster erstellen, ist ja kein Drama.

[Kaeru Gaman]

unter XP, wenn nicht auch unter 2K/NT sollte doch ein screen auch ein window-handle haben, oder?

aber wie-auch-immer...
ElapsedMilliseconds() ist nicht unbrauchbar, wenn man es vernünftig einsetzt.

[Fluid Byte]

unter XP, wenn nicht auch unter 2K/NT sollte doch ein screen auch ein window-handle haben, oder?

ScreenID()

SetTimer_() mit 0 als hWnd halte ich nicht für ratsam.

Wo ist das Problem?

Im SDK steht das hwnd Handle kann NULL sein. Von Gefahren oder Einschränkungen habe ich diesbezüglich noch nie was gehört.

[ts-soft]

Wenn ein anderes Fenster denselben Timer nutzt, so wird dieser im anderen
Fenster nicht mehr funktionieren, sollte nach erstellen des Timers, ein
anderes Fenster denselben Timer erstellen, funzt unser Timer nicht mehr.

Mein Programm ist niemals alleine unter Windows.