spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Der Unterschied bleibt immer noch bei "=" und "+=" und dabei, ob ich vom letzten Frame abhänge oder nicht. Ich weiß ja, worauf du hinaus willst, numerisch macht es aber eben doch einen wichtigen Unterschied.

Wie ich schon sagte, die Formel an sich dahinter ist natürlich die selbe. Die abgezielte Implementierung ist es aber nicht. Da habe ich mich aber nicht klar genug ausgedrückt.

Zitat von »BlueCobold«

Der Unterschied bleibt immer noch bei "=" und "+="

Noe.

Vielleicht erklärt man es doch einfach simpel:

du merkst dir die zeit, die zwischen zwei frames vergeht in sekunden als float. diese wird immer 0.0 <= t <= 1.0 sein. dann musst du jegliche bewegung in abhängigkeit der zeit ausdrücken, d.h. in Pixel Pro sekunde. wenn du zum beispiel ein auto hast, dass sich innerhalb einer sekunde über den bildschirm, der 640pixel breit ist, bewegen willst, so drückst du seine bewegung so aus:



einfache rechnung: wenn du gerade eine framerate von 40 hast, dann hast du 25ms pro frame, das sind 0,025 sekunden. somit bewegst du dich mit 640 * 0,025 = 16 Pixel pro frame. würdest du 80 frames haben, so würdest du eine frametime von 0,0125 sekunden haben und dich 640 * 0,0125 = 8 Pixel pro frame bewegen. Macht auch sinn: ist die framerate doppelt so hoch, dann darfst du dich pro frame nur halb so schnell bewegen!

Bei der ganzen Sache sollte man aber beachten:
- Determinismus geht fast garantiert flöten, wenn man variable Schrittweiten benutzt
- KI könnte auf schnellen Rechnern plötzlich "schlauer" werden, weil sie öfters "denken" kann - je nach Implementierung

Ich bin ja mittlerweile überzeugter Benutzer des "Zeitkonto"-Ansatzes.
Merk Dir, wie viel Zeit Du noch abarbeiten musst. Sobald sie über 1/Gewünschte_logische_Framerate steigt (z.B. 1/60), mache so lange feste Update-Schritte (ebenfalls 1/60) und ziehe diese 1/60 vom Zeitkonto ab, bis sein Wert wieder kleiner als 1/60 ist. Danach rendern (fortgeschritten: niedrigere Update-Rate, aber häufiger rendern und zwischen den Zuständen interpolieren). Partikelsysteme oder andere unkritische Sachen kannst Du auch mit variabler Schrittweite berechnen, wenn sie nicht zur Spiellogik beitragen. Nach jedem Durchlauf der Hauptschleife addierst Du die für diesen Durchlauf benötigte Zeit wieder auf das Zeitkonto.
Probleme kriegst Du mit diesem Ansatz potenziell dann, wenn der Rechner zu langsam ist, um die Updates schnell genug zu schaffen, dann wächst das Zeitkonto immer weiter an. Aber wenn Du Deine Spiellogik effizient programmierst und alles im Rahmen bleibt, sollte das nicht passieren (oder wenn doch, dann ist der Rechner eh hoffnungslos überfordert).

Der Vorteil ist, dass Du nun mehr Determinismus hast. Du könntest z.B. die Eingaben des Benutzers für jedes Frame aufzeichnen und später wieder einspeisen und hast dann einen ziemlich einfachen Demo-Recorder/-Player (vorausgesetzt, Du initialisierst auch eventuelle Zufallsgeneratoren mit demselben Wert). Für Physik/Kollisionserkennung ist es eh besser, mit festen Schrittweiten zu arbeiten, weil sonst komische Sachen passieren können (im schlimmsten Fall fliegen Objekte durch andere hindurch).

(zu diesem Thema muss unbedingt ein Wiki-Artikel geschrieben werden, wenn das Wiki dann endlich mal eröffnet wird )

@David:
Das geschickte Warten hat noch einen Vorteil: es ist die beste Moeglichkeit, das im Netzwerk alles synchron laeuft.

Sorry, habs nicht kapiert.

Wie bekomme ich dann mit der Zeitkonto Methode das Spiel synchron?

Sagen wir der Rechner muss noch 10 Sekunden einen Ball auf und ab springen lassen.
Ein schneller Rechner wird auf Grund seiner hohen Frame-Rate viel mehr Zeit/Durchläufe haben, um seine Schritte zu berechnen.
Ergebnis ist, dass der Ball auf einem neuen Rechner 100 Sprünge macht und auf einem alten Rechner vielleicht 10.

Ich denke auch, dass der Ersteller dieses Threads mittlerweile total verwirrt ist - ich bin es jedenfalls.

Über einen Artikel im hoffentlich bald neuen Wiki würde ich mich auch sehr freuen.

Schöne Grüße

fb

Zitat von »David Scherfgen«

Bei der ganzen Sache sollte man aber beachten:
- Determinismus geht fast garantiert flöten, wenn man variable Schrittweiten benutzt
- KI könnte auf schnellen Rechnern plötzlich "schlauer" werden, weil sie öfters "denken" kann - je nach Implementierung

Ich bin ja mittlerweile überzeugter Benutzer des "Zeitkonto"-Ansatzes.
Merk Dir, wie viel Zeit Du noch abarbeiten musst. Sobald sie über 1/Gewünschte_logische_Framerate steigt (z.B. 1/60), mache so lange feste Update-Schritte (ebenfalls 1/60) und ziehe diese 1/60 vom Zeitkonto ab, bis sein Wert wieder kleiner als 1/60 ist. Danach rendern (fortgeschritten: niedrigere Update-Rate, aber häufiger rendern und zwischen den Zuständen interpolieren). Partikelsysteme oder andere unkritische Sachen kannst Du auch mit variabler Schrittweite berechnen, wenn sie nicht zur Spiellogik beitragen. Nach jedem Durchlauf der Hauptschleife addierst Du die für diesen Durchlauf benötigte Zeit wieder auf das Zeitkonto.
Probleme kriegst Du mit diesem Ansatz potenziell dann, wenn der Rechner zu langsam ist, um die Updates schnell genug zu schaffen, dann wächst das Zeitkonto immer weiter an. Aber wenn Du Deine Spiellogik effizient programmierst und alles im Rahmen bleibt, sollte das nicht passieren (oder wenn doch, dann ist der Rechner eh hoffnungslos überfordert).

Der Vorteil ist, dass Du nun mehr Determinismus hast. Du könntest z.B. die Eingaben des Benutzers für jedes Frame aufzeichnen und später wieder einspeisen und hast dann einen ziemlich einfachen Demo-Recorder/-Player (vorausgesetzt, Du initialisierst auch eventuelle Zufallsgeneratoren mit demselben Wert). Für Physik/Kollisionserkennung ist es eh besser, mit festen Schrittweiten zu arbeiten, weil sonst komische Sachen passieren können (im schlimmsten Fall fliegen Objekte durch andere hindurch).

(zu diesem Thema muss unbedingt ein Wiki-Artikel geschrieben werden, wenn das Wiki dann endlich mal eröffnet wird )

Zitat von »Fireball«

Ein schneller Rechner wird auf Grund seiner hohen Frame-Rate viel mehr Zeit/Durchläufe haben, um seine Schritte zu berechnen.

Nee, man macht ja immer erst dann ein Update, wenn wieder genug Zeit auf dem Zeitkonto ist.
Solange das nicht der Fall ist, hat der Rechner nichts zu tun und kann warten bzw. die Rechenzeit an einen anderen Prozess abgeben.
Der schnellere Rechner wird dementsprechend mehr Zeit mit Warten verbringen.
Wie gesagt, Voraussetzung ist immer, dass der Rechner prinzipiell in der Lage ist, die geforderte Anzahl von Updates pro Sekunde zu schaffen.

Zitat von »TGGC«

Zitat von »BlueCobold«

Der Unterschied bleibt immer noch bei "=" und "+="

Noe.

Das kannst Du noch so verleugnen, es bleibt ein numerischer Unterschied, ob ich ein Ergebnis aus 200 Frame-Ergebnissen oder einem Schritt berechne. Wettern hilft da gar nichts.

Noe, ist genau die gleiche Rechnung. Nur s0 wird anders bestimmt. Werden alle Contraints eingehalten, ist auch das Ergebnis gleich.