wenn ich ein "On timer" Event setze (1s) dann ensteht über die Zeit (beispiel nach über eine Minute) eine Abweichung von 0.009, sprich alle 10 sekunden entsteht ein offset von ca. 0.001 sekunden
Abklären warum das so ist, und ob es ein Bug ist.
<img width="329" alt="image.png" src="attachments/eeab754a-7bc6-443a-8bbe-fcd406d35a14">
wenn ich ein "On timer" Event setze (1s) dann ensteht über die Zeit (beispiel nach über eine Minute) eine Abweichung von 0.009, sprich alle 10 sekunden entsteht ein offset von ca. 0.001 sekunden
Abklären warum das so ist, und ob es ein Bug ist.
Kein Bug im Timer, aber jetzt mit Ausgang late (Commit 6fecb2e).
Ursache:On timer kann nur an einem Frame feuern. Er feuert im ersten Frame nach jeder fälligen Sekunde. Time.time steht in diesem Moment auf Sollzeit + Verspätung, und die Verspätung ist höchstens ein Frame. Der Timer selbst driftet nicht: beim Feuern zieht er genau ein Intervall ab und nimmt den Rest mit.
Läuft der Bildschirm nicht exakt mit 60,000 Hz, rutscht das Frame-Raster langsam gegen die vollen Sekunden. Nachgerechnet mit der Timer-Logik bei 59,994 Hz: etwa 0.001 pro 10 s, bei 82 s rund 0.008. Nach etwa 167 s ist die Verspätung einen ganzen Frame groß, dann springt sie auf ~0 zurück (Sägezahn, wächst nicht weiter). Bei exakt 60 Hz bleibt sie 0.
Neu:On timer hat einen Zahlenausgang late, also wie weit der Frame hinter der Sollzeit liegt. time - late ergibt damit genau die Sollzeit. Holt ein langer Frame mehrere Ticks nach, bekommt jeder seinen eigenen Wert, der erste den größten.
Tests: ein neuer Unit-Test (0.125 nach einem Frame über 1 s, 0 auf den Punkt, 1.5 und 0.5 für zwei nachgeholte Ticks). Die Gegenprobe (late vor dem Abziehen) lässt genau diesen Test fallen. Gate: 156 Dateien, 2300 Tests, CHECK EXIT 0. Wiki: Behaviors ist ergänzt.
Kein Bug im Timer, aber jetzt mit Ausgang `late` (Commit 6fecb2e).
**Ursache:** `On timer` kann nur an einem Frame feuern. Er feuert im ersten Frame **nach** jeder fälligen Sekunde. `Time.time` steht in diesem Moment auf Sollzeit + Verspätung, und die Verspätung ist höchstens ein Frame. Der Timer selbst driftet nicht: beim Feuern zieht er genau ein Intervall ab und nimmt den Rest mit.
Läuft der Bildschirm nicht exakt mit 60,000 Hz, rutscht das Frame-Raster langsam gegen die vollen Sekunden. Nachgerechnet mit der Timer-Logik bei 59,994 Hz: etwa 0.001 pro 10 s, bei 82 s rund 0.008. Nach etwa 167 s ist die Verspätung einen ganzen Frame groß, dann springt sie auf ~0 zurück (Sägezahn, wächst nicht weiter). Bei exakt 60 Hz bleibt sie 0.
**Neu:** `On timer` hat einen Zahlenausgang **`late`**, also wie weit der Frame hinter der Sollzeit liegt. `time - late` ergibt damit genau die Sollzeit. Holt ein langer Frame mehrere Ticks nach, bekommt jeder seinen eigenen Wert, der erste den größten.
**Tests:** ein neuer Unit-Test (0.125 nach einem Frame über 1 s, 0 auf den Punkt, 1.5 und 0.5 für zwei nachgeholte Ticks). Die Gegenprobe (`late` vor dem Abziehen) lässt genau diesen Test fallen. Gate: 156 Dateien, 2300 Tests, `CHECK EXIT 0`. Wiki: *Behaviors* ist ergänzt.
Nachtrag: time - late kam im Log als 5.999999999999972 statt 6 an. Das ist Gleitkomma-Rauschen, denn time und late summieren dieselben gemessenen dt auf verschiedenen Wegen. Ein Compare == 6 ist daran gescheitert, und man hätte jedes Mal ein Round davorsetzen müssen.
Compare vergleicht Zahlen jetzt mit einer relativen Toleranz: gleich ist, was |a - b| <= 1e-9 * max(1, |a|, |b|) erfüllt. Alle sechs Operatoren nutzen dieselbe Regel. < und > gelten nur, wenn die Werte nicht ungefähr gleich sind, <= und >= auch dann. So können == und > nie gleichzeitig wahr sein.
Equals nutzt dieselbe Regel, wenn zwei echte Zahlen ankommen. Objekte werden weiter über ihre Identität verglichen, alles andere als Text.
1e-9 schluckt auch nach vielen Stunden aufsummierter Frame-Zeiten das Rauschen, echte Unterschiede wie 6 und 6.001 bleiben verschieden. Physikwerte aus Rapier (float32) deckt die Toleranz absichtlich nicht ab.
Die Anzeige im Log ist unverändert und zeigt weiter die rohe Zahl.
Tests: 11 neue Fälle im Node-Katalog-Test, Gate 2311 Tests grün. Gegenproben mit exaktem Vergleich und mit </> ohne Ausschluss fallen genau an ihren Fällen. Wiki: Behaviors, Eintrag zu Compare.
Nachtrag: `time - late` kam im Log als `5.999999999999972` statt `6` an. Das ist Gleitkomma-Rauschen, denn `time` und `late` summieren dieselben gemessenen `dt` auf verschiedenen Wegen. Ein `Compare == 6` ist daran gescheitert, und man hätte jedes Mal ein `Round` davorsetzen müssen.
Behoben in 9d6a0ae:
- **`Compare`** vergleicht Zahlen jetzt mit einer relativen Toleranz: gleich ist, was `|a - b| <= 1e-9 * max(1, |a|, |b|)` erfüllt. Alle sechs Operatoren nutzen dieselbe Regel. `<` und `>` gelten nur, wenn die Werte nicht ungefähr gleich sind, `<=` und `>=` auch dann. So können `==` und `>` nie gleichzeitig wahr sein.
- **`Equals`** nutzt dieselbe Regel, wenn zwei echte Zahlen ankommen. Objekte werden weiter über ihre Identität verglichen, alles andere als Text.
- 1e-9 schluckt auch nach vielen Stunden aufsummierter Frame-Zeiten das Rauschen, echte Unterschiede wie `6` und `6.001` bleiben verschieden. Physikwerte aus Rapier (float32) deckt die Toleranz absichtlich nicht ab.
- Die Anzeige im Log ist unverändert und zeigt weiter die rohe Zahl.
Tests: 11 neue Fälle im Node-Katalog-Test, Gate 2311 Tests grün. Gegenproben mit exaktem Vergleich und mit `<`/`>` ohne Ausschluss fallen genau an ihren Fällen. Wiki: *Behaviors*, Eintrag zu `Compare`.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
wenn ich ein "On timer" Event setze (1s) dann ensteht über die Zeit (beispiel nach über eine Minute) eine Abweichung von 0.009, sprich alle 10 sekunden entsteht ein offset von ca. 0.001 sekunden
Abklären warum das so ist, und ob es ein Bug ist.
Kein Bug im Timer, aber jetzt mit Ausgang
late(Commit6fecb2e).Ursache:
On timerkann nur an einem Frame feuern. Er feuert im ersten Frame nach jeder fälligen Sekunde.Time.timesteht in diesem Moment auf Sollzeit + Verspätung, und die Verspätung ist höchstens ein Frame. Der Timer selbst driftet nicht: beim Feuern zieht er genau ein Intervall ab und nimmt den Rest mit.Läuft der Bildschirm nicht exakt mit 60,000 Hz, rutscht das Frame-Raster langsam gegen die vollen Sekunden. Nachgerechnet mit der Timer-Logik bei 59,994 Hz: etwa 0.001 pro 10 s, bei 82 s rund 0.008. Nach etwa 167 s ist die Verspätung einen ganzen Frame groß, dann springt sie auf ~0 zurück (Sägezahn, wächst nicht weiter). Bei exakt 60 Hz bleibt sie 0.
Neu:
On timerhat einen Zahlenausganglate, also wie weit der Frame hinter der Sollzeit liegt.time - lateergibt damit genau die Sollzeit. Holt ein langer Frame mehrere Ticks nach, bekommt jeder seinen eigenen Wert, der erste den größten.Tests: ein neuer Unit-Test (0.125 nach einem Frame über 1 s, 0 auf den Punkt, 1.5 und 0.5 für zwei nachgeholte Ticks). Die Gegenprobe (
latevor dem Abziehen) lässt genau diesen Test fallen. Gate: 156 Dateien, 2300 Tests,CHECK EXIT 0. Wiki: Behaviors ist ergänzt.Nachtrag:
time - latekam im Log als5.999999999999972statt6an. Das ist Gleitkomma-Rauschen, denntimeundlatesummieren dieselben gemessenendtauf verschiedenen Wegen. EinCompare == 6ist daran gescheitert, und man hätte jedes Mal einRounddavorsetzen müssen.Behoben in
9d6a0ae:Comparevergleicht Zahlen jetzt mit einer relativen Toleranz: gleich ist, was|a - b| <= 1e-9 * max(1, |a|, |b|)erfüllt. Alle sechs Operatoren nutzen dieselbe Regel.<und>gelten nur, wenn die Werte nicht ungefähr gleich sind,<=und>=auch dann. So können==und>nie gleichzeitig wahr sein.Equalsnutzt dieselbe Regel, wenn zwei echte Zahlen ankommen. Objekte werden weiter über ihre Identität verglichen, alles andere als Text.6und6.001bleiben verschieden. Physikwerte aus Rapier (float32) deckt die Toleranz absichtlich nicht ab.Tests: 11 neue Fälle im Node-Katalog-Test, Gate 2311 Tests grün. Gegenproben mit exaktem Vergleich und mit
</>ohne Ausschluss fallen genau an ihren Fällen. Wiki: Behaviors, Eintrag zuCompare.