Ich schreibe einen schnellen und ziemlich genau Spiel-Timer für die Verwendung unter Windows. Microsoft empfiehlt die Verwendung von QueryPerformanceCounter() für das Timing mit hoher Auflösung, und es funktioniert wie erwartet, aber ich suche nach Alternativen, die weniger Ausführungsaufwand ergeben.QueryPerformanceCounter() vs QueryInterruptTime() vs KeQueryInterruptTime()
Ich habe etwas Googeln und fand die Erwähnung von QueryInterruptTime(), und sein Gegenstück QueryInterruptTimePrecise(), die präziser sein sollte, aber mehr Aufwand verursacht. Ihre Dokumentation (here und here) beschreibt, dass sie die Anzahl der Systemunterbrechungszeiten zum nächsten System-Tick (oder 100ns-Einheit) bringen. QueryInterruptTime() fängt an, als Timing-Kandidat gut auszusehen, aber es gibt sehr wenig Dokumentation seiner Vorteile und seiner Macken.
Und dann gibt es KeQueryInterruptTime() und KeQueryInterruptTimePrecise(), und ich habe keine Ahnung, wie sie sich von ihren "non-Ke" Geschwister unterscheiden.
Kann jemand QueryInterruptTime() und KeQueryInterruptTime() beschreiben, ihre Unterschiede, Vor- und Nachteile, und vergleichen Sie sie mit der ubiquitärer QueryPerformanceCounter() bitte?
Ist so etwas eigentlich eine Anforderung? Der meiste Spielecode muss die Zeit "gerade jetzt" nicht wirklich wissen, sondern interessiert sich dafür, wie die Zeit sein wird, wenn der Rahmen tatsächlich auf dem Bildschirm gerendert wird. Daher interessiert sich Ihr Spiel eigentlich für den Timer, der nach einer idealisierten Rate fortschreitet - was die konsistenteste Benutzererfahrung bietet - und die Spielschleife liefert Frames dann - möglichst nahe dieser Rate - auf den Bildschirm - möglicherweise mit vsync . –
Ja, das ist wahr, ich zähle einfach die möglichen Optionen auf, die existieren, um zu versuchen, eine QPC-Alternative zu finden, die weniger Overhead bietet, aber robust genug ist, um akzeptables Spieltiming zu ermöglichen. –