spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Ganzzahlen sind natürlich auch doof, wenn man die z.B. in einen Sinus jagen will.

Schau nochmal meine letzte Antwort, ich hatte etwas bemerkt und sie bearbeitet (dein Code hat keinen Unterschied zwischen den Zahlen angezeigt, aber mit printf schon!).

Zudem kann man ja einfach nur ganzzahlig zählen und dann bei Bedarf immer noch “lokal“ nach float/double umrechnen. Nur halt nicht direkt damit akkumulieren.

War mir schon aufgefallen. Meine Hyperbel erhalte ich dennoch (PS: Wäre auch mit std::setprecision(10) ersichtlich gewesen, man muss ja nicht gleich printf nehmen - dazu kommt aber noch, dass ideone die Konstanten und Addition gleich mal komplett wegoptimiert )

Ich habe das jetzt auch mal untersucht. Bei der Verwendung von float und einer Update-Rate von 60 Hz erhält man ab 16384 Sekunden (~4.55 Stunden) eine deutliche Abweichung des tatsächlich ausgeführten Zeitschritts, dieser steigt dann nämlich auf 0.0175781 Sekunden statt 0.0166... Sekunden. Das sind über 5% Abweichung nach oben, im Spiel sollte man das schon merken können.
Bei diesem Wert bleibt es dann bis 32768 Sekunden (~9.1 Stunden), dann sinkt der Zeitschritt auf 0.015625 Sekunden (6.25% Abweichung nach unten).
Ich hätte jetzt bei 65536 Sekunden die nächste Änderung erwartet, aber stattdessen bleibt es quasi "ewig" dabei - wohl weil 0.015625 sich sehr schön als Binärzahl darstellen lässt, es ist nämlich genau 1/64!
Ja ja, diese bösen Fließkommazahlen

PS: Wenn man double benutzt, liegt der Fehler auch nach Jahren noch bei ~0.000006%. Also mit double ist man ziemlich auf der sicheren Seite

Zitat von »BlueCobold«

Wenn das Spiel länger läuft, dürfte das hier zum echten Problem werden: aktuelleZeit += zeitSeitLetztemSchleifendurchlauf
Einfach weil die aktuelle Zeit so groß wird, dass bei der Addition dank des Datentyps floats nichts mehr passiert:

Der Wert wird in dem Pseudocode bei einem Updatedurchgang verringern. Der Wert von aktuelleZeit sollte also nur riesig werden wenn du deine Zeit pro Frame so riesig wählst. Das würde man aber nicht tun. Man würde ja nicht alle 15203 Sekunden ein Update durchführen wollen sondern viel öfter.

Nein, Schorsch. Lange Laufzeit des Programms vs. kleine Zeitschritte sind das Problem. Lange Zeitschritte wären sogar vorteilhaft, weil weniger fehlerbehaftet in Relation zur großen Gesamtzeit (in Anbetracht der Addition, die durchgeführt wird). Zahlen ähnlicher Größenordnungen addieren prima, Zahlen verschiedener Größenordnungen allerdings nicht. Addition ist eine numerisch instabile Operation.

Verwendet man konstante Updatezeiten um die Performance zu steigern?
Warum macht man das zB nicht so:


KonstanteZeit wäre dann nur in etwa die Updatezeit, aber damit eleminiere ich doch das Problem der Ungenauigkeit, aber hab geringere CPU-Last?
Oder hat die Methode gravierende Nachteile?

@BlueCobold:
Aber "aktuelleZeit" wird doch nie wirklich groß werden?
Es wird doch die Zeit seit dem letzten Update hinzuaddiert und anschließend werden wieder Werte substrahiert (erste Zeile in der while-Schleife)

Damit sollten doch auch im Worst-Case höchstens ein paar Sekunden in "aktuelleZeit" drin stehen?

Ah, Tatsache, es wird gar nicht permanent hochgezählt, sondern quasi immer nur der Rest-Betrag als "aktuell" mitgeschleift.

@CentuCore: Fix your timestep! Also nein, das ist meistens keine tolle Lösung.