Brauche absolut exakten Timer
-
Kannst Du Deine Simulation (wenn sie denn auch eine ist und nur auf dem PC stattfindet) nicht um einen bestimmten Faktor langsamer machen? Dann ist die Ungenauigkeit der Timer um diesen Faktor kleiner.
Oder Du arbeitest mit "Zeitscheiben" kleiner, jedoch fester Größe, die Du zeitlich beliebig irgenwann abarbeiten kannst.Blackbird
-
Wie machen das denn Profis? Also bei Computerspielen? Ich meine die brauchen zum Teil ja auch periodische Ereignisse mit einer Auflösung von ein paar Millisekunden...
-
chris90 schrieb:
Wie machen das denn Profis? Also bei Computerspielen? Ich meine die brauchen zum Teil ja auch periodische Ereignisse mit einer Auflösung von ein paar Millisekunden...
Warum sollten die sowas brauchen? Die messen i.d.R. immer die Unterschiede zwischen zwei Ereignissen...
Und es ist da auch nicht so schlimm, wenn es mal länger dauert. Dann war halt der Abstand zwischen zwei Messungen größer und die Bewegung wird eben entsprechend angepasst. Aber auf irgendwelche Zeiten verlassen die sich nicht.
-
Ein Game ist keine Simulation.
Vielleicht reden wir wegen der Begriffe aneinander vorbei.Auch wenn ein Echtzeitbetriebssystem zum Einsatz kommt, ist eine Simulation (jedenfalls Das was die "Profis" darunter verstehen) nicht eindeutig. Die Abfolge einer Simulation muß nicht zwangsläufig in Echtzeit ablaufen.
Geht's nur um eine möglichst realistisches Spiel oder eine "richtige" Simulation? (das ist jetzt keine Abwertung Deines Vorhabens, beide Zweige haben ihre volle Daseinsberechtigung)
Blackbird
-
Es geht um eine Simulation. Damit die möglichst schnell abläuft, möchte ich ein kleinstmögliches Intervall haben. Eine einfache For-Schleife in einem neuen Thread genügt deswegen nicht, da die Simulation in Echtzeit graphisch angezeigt werden soll. Glaubt ihr es macht da etwas wenn ich eben alle paar zehntelsekunden mal ein 20ms-Intervall drinhabe neben einem 1 ms Intervall?
Und wie soll ich dann mit den zu großen Intervallen umgehen? Ignorieren ? Dynamisch berechnen - dann hab ich aber wieder das Problem dass ich dann kein Standart - Intervall habe und das könnte dumme folgen haben auf den Ablauf der Simulation.danke
chris90
-
Warum misst Du nicht einfach die Zeit zwischen zwei Aufrufen Deines Timers???
Damit weisst Du wie schnell du die "Bewegung" jetzt ausführen musst. Somit spielt die Genauigkeit des Aufrufes keine Rolle mehr...
-
Das Problem ist eben dass ich gewissermaßen "integriere". Sprich je größer das Intervall, desto ungenauer die Berechnung. Das bedeutet, dass ich ein konstantes kleines Intervall benötige.
ich glaube ich werde es so machen, dass ich größere Intervalle als kleinere behandele.danke
chris90
-
Der Performance Counter ist in der Hardware implementiert und läuft mit 3.19 Mhz. Das gibt uns eine Auflösung von ca. 1 Mikrosekunde (1/1.000.000stel einer Sekunde).
*
Low-Level TimingIch hab den kürzlich erst bei meinem MS3D Loader benutzt. Ist gut, wenn man jeden Frame die FPS hochrechnen will um Bewegungen gleichmäßig zu machen.
-
xindon schrieb:
*Der Performance Counter ist in der Hardware implementiert und läuft mit 3.19 Mhz. Das gibt uns eine Auflösung von ca. 1 Mikrosekunde (1/1.000.000stel einer Sekunde).
*Von welchem Performance Counter redest Du da? Und wo steht sowas?
-
Jochen Kalmbach schrieb:
xindon schrieb:
*Der Performance Counter ist in der Hardware implementiert und läuft mit 3.19 Mhz. Das gibt uns eine Auflösung von ca. 1 Mikrosekunde (1/1.000.000stel einer Sekunde).
*Von welchem Performance Counter redest Du da? Und wo steht sowas?
klick doch mal auf den Link darunter
-
Die einzige Referenz die bei der WinAPI verwendet werden sollte ist die MSDN (die auch nicht perfekt ist
)...Falls Du also von QueryPerformanceCounter reden solltest, dann ist die Frequenz abhängig von der HAL und nicht fest vorgegen! (sonst würde es ja auch keine QueryPerformanceFrequency geben, oder)?
-
Jochen Kalmbach schrieb:
Die einzige Referenz die bei der WinAPI verwendet werden sollte ist die MSDN...
Falls Du also von QueryPerformanceCounter reden solltest, dann ist die Frequenz abhängig von der HAL und nicht fest vorgegen! (sonst würde es ja auch keine QueryPerformanceFrequency geben, oder)?
Auf den meisten heutigen CPU's liegt die Frequenz aber bei 3.19Ghz und die Funktion gibt es, da sie auch anders sein kann, wie du sagst.
Das hab ich irgendwo gelesen.
Ich kann nur aus Erfahrung sprechen, dass ich gute Erfahrungen mit dem Counter gemacht habe beim Rendern, wenn ein Schleifendurchgang nur 5ms oder weniger dauert. Zum hochrechnen wie schon gesagt.
-
naja das Problem ist ja wohl eher nicht dass ich keine Möglichkeit hätte z.b. über QueryPerformanceCounter einen höchstgenauen Zeitabstand zu messen. Das Problem ist, dass ich in der Überprüfung plötzlich immer wieder 16ms abstand habe. Die genauste Timer-Funktion nützt mir nichts, wenn ich sie nur alle 16ms überprüfen kann
-
Ja wann bestimmst du denn die Zeit?
wenn du es einmal in einem Schleifendurchlauf machst, braucht die Schleife vielleicht 16ms ? Könnte ja sein, dass der Prozess deines Programmes nicht oft genug an der Reihe ist und darum dauerts halt ab und zu mal en bisschen länger
-
nein, meine schleife braucht ca. 99 von 100 mal nur ca. 3 oder 4 1/10000 sekunden.
Die Frage ist nur, wie ich den Thread der das zeitinterval misst dazu gebracht werden kann, nicht unterbrochen zu werden. Mit SetThreadPriority hats nämlich nicht geklappt!
-
chris90 schrieb:
nein, meine schleife braucht ca. 99 von 100 mal nur ca. 3 oder 4 1/10000 sekunden.
Die Frage ist nur, wie ich den Thread der das zeitinterval misst dazu gebracht werden kann, nicht unterbrochen zu werden. Mit SetThreadPriority hats nämlich nicht geklappt!nocht nichmal als Echtzeitthread ?
-
nein, noch nicht einmal als Echtzeitthread bzw falls das Priority Nr. 6 ist...
Es macht bei mir aber auch keinen großen Unterschied ob ich nun -15 oder 6 hatte als Priority...
-
hey, ich glaub ich weiß was ich grade für einen Fehler gemacht hab.
Mein Timer zeigt Millisekunden and und nicht Sekunden! Deswegen habe ich bei Ergebnisse wie "0.012" rot gesehen!
aalso: Mit Echtzeitthread klappt es wunderbar! Auflösung: < 0.5 msWieso wird das nicht immer so gemacht wo es doch eine höhere Auflösung hat?
DANKE!!
chris90
-
chris90 schrieb:
hey, ich glaub ich weiß was ich grade für einen Fehler gemacht hab.
Mein Timer zeigt Millisekunden and und nicht Sekunden! Deswegen habe ich bei Ergebnisse wie "0.012" rot gesehen!
aalso: Mit Echtzeitthread klappt es wunderbar! Auflösung: < 0.5 msWieso wird das nicht immer so gemacht wo es doch eine höhere Auflösung hat?
DANKE!!
chris90Je höher die Threadpriorität, desto öfter kommt der Prozess an die Reihe beim Weiterrechnen.
Echtzeit ist halt verdammt oft, wenn nicht sogar *nur*, bin mir grad nicht sicher.
-
xindon schrieb:
Je höher die Threadpriorität, desto öfter kommt der Prozess an die Reihe beim Weiterrechnen.
????
xindon schrieb:
Echtzeit ist halt verdammt oft, wenn nicht sogar *nur*, bin mir grad nicht sicher.
Echtzeit hat nichts mit oft zu tun, sondern mit Deterministrik. Und die ist in Windows nicht gegeben.