GetTickCount hatte ich anfangs, allerdings wurde der Timer ungenauer (bzw. langsamer), je stärker der PC ausgelastet war, und somit realitv unbrauchbar...
Das sollte nicht passieren. GetTickCount müsste konstant "ticken", aber wie Günther schon sagte, mit einer Auflösung/Genauigkeit von ca. 1/64s (15,625 ms).
Bei GetTickCount, sowie anderen Methoden, muss man allerdings auch an den Überlauf denken: GetTickCount liefert die Anzahl der Millisekunden seit letztem Booten des Computers, wenn der also länger als ca. 49,7 Tage am Stück lief, dann fängt der Wert wieder bei 0 an. Es kann also passieren, dass der Endwert eines Messintervalls kleiner ist als der Startwert!
Alternativen zu GetTickCount sind Multimedia Timer (
timeGetTime) und
QueryPerformanceCounter.
Die timeGetTime
API ist sehr ähnlich zu GetTickCount, allerdings kann man die Auflösung via
timeBeginPeriod auf bis zu 1 ms setzen. Über eine "undokumentierte" ntdll
API (
NtSetTimerResolution) sogar auf 0.5 ms.
Diese Funktionen (außer natürlich NtSetTimerResolution) findet man in der Standardunit MMSystem (
Winapi.MMSystem).
Falls mehr Präzision gebraucht wird, bleibt nur
QueryPerformanceCounter in Verbindung mit
QueryPerformanceFrequency.
Neuere Delphi-Versionen haben übrigens eine System.Diagnostics
Unit, in der ein TStopwatch Record zum Zeitmessen implementiert ist. Der benutzt GetTickCount, oder falls verfügbar QueryPerformanceCounter.
Also das Ganze program ist ein sogenannter "Splitter" für Speedruns eines speziellen Spiels.
Im Prinzip eine Stopuhr...
Ich würde es gerne auf die Millisekunde genau und auch in Echtzeit updaten, also dass man den ganzen Timer hochticken sieht.
Verstehe. Ich hoffe dir ist klar, dass bei einer typischen Bildwiederholfrequenz von 60 Hz ein Zeitabschnitt 1/60 = 16,67 ms beträgt. Also auf die Millisekunde genau messen ist schon drin, jede Millisekunde die Anzeige aktualisieren wäre aber sinnlos.
