spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Nun, auf SPPRO finden sich aber (fast) nur Trivialbeispiele und nur auf diese bezieht sich meine Lösung. Das habe ich von Anfang an klar gemacht. Deswegen verstehe ich auch nicht, wieso mir immer und immer wieder gesagt wird, dass das unter gewissen Umständen auch nicht besser ist. Mehr als wiederholen kann ich mich nämlich auch nicht.

Und dass der komplette Verzicht auf zeitbasierte Updates noch grausamer ist, da sie vollständig von den FPS eines Systems abhängen, das brauchen wir ja wohl sicher auch nicht zu erörtern.

Was spricht denn dagegen die Zeit zwischen den Updates zu addieren, das Ergebnis in Ticks um zurechnen und dann Berechnungen auf Basis der Ticks machen. So könnte man beide Probleme Lösen.

Zudem könnte man auch die Geschwindigkeit sehr einfach anpassen (und muss dies nur an einer Stelle implementieren, Stichwort DRY). Auch für Replays kann ich mir vorstellen das es sehr von Vorteil ist eine eigene Zeit im Spiel zu haben.

Zitat von »BlueCobold«

@Jonathan:
Nein. Während du für die Berechnung eines iterativen Systems mit einem Intervall von 0.02 Sekunden für eine Bewegung über eine Sekunde 50 Berechnungen machen musst, so muss mein System (und das von daG) eben nur eine einzelne Berechnung durchführen. Der Vorteil der gesparten Rechenzeit und numerischer Fehler sollte offensichtlich sein.

Hm, das versteh ich nicht. Hab ich 50 FPS berechne ich jedesmal die Spiellogik neu, damit jedes Bild anders aussieht. Wenn man jede Sekunde nur einmal rechnet, sollen dann 50 Bilder gleich aussehen?
Ich will ja nicht den Endwert haben, ich will den Verlauf ausrechnen.

Ich glaube wir reden gerade auf ungefähr 3 verschiedenen Ebenen aneinander vorbei...

@Jonathan_Klein : Es geht darum was du machst wenn z.B. das Spiel für ne Sekunde oder länger aussetzt. Oder wenn das Spiel weniger als die gewünschte FPS erreicht.

Zitat von »dot«

Zitat von »xardias«

[...] jedoch machen wir hier ja keine wissenschaftlichen Simulationen. [...]

Wissenschafltiche Simulationen arbeiten in der Regel erst recht iterativ, denn wenn es eine analytische Lösung gäbe könnte man die einfach ausrechnen und bräuchte keine Simulation

Hast völlig recht dot. Wir machen hier z.B. sehr viele Partikelsimulationen in der Virtual Reality Group die natürlich ebenfalls iterativ berechnet werden. Das geht jedoch nicht mehr in Echtzeit wenn man die Genauigkeitsbedürfnisse der Ingenieure befriedigen will

Was ich meinte ist, dass numerische Genauigkeit von Animationen für die Spieleentwicklung in der Regel kein zentraler Faktor ist, in wissenschaftlicher Anwendung dagegen schon.

Zitat von »daG«

@Jonathan_Klein : Es geht darum was du machst wenn z.B. das Spiel für ne Sekunde oder länger aussetzt. Oder wenn das Spiel weniger als die gewünschte FPS erreicht.

Nein, das ist doch wieder ein ganz anderes Problem. Ich meine, viele Möglichkeiten gibts da eh nicht, du kannst es ruckeln lassen, oder langsamer werden lassen.
Wenn es ruckelt, kannst du dir überlegen, ob du einen großen Schritt machst, was je nach Problem garantiert ungenau wird (Kollision mit nem Objekt mit ner komischen Flugkurve und komplizierte Levelgeometrie, viel Spaß, das in einem Schritt korrekt zu berechnen) oder du machst halt wieder mehrere kleine Schritte um z.B: eine Physik FPS zu gewährleisten. Nur wenns wegen der Physik ruckelt steht man auch wieder dumm da.

Solange es noch ordentliche Ergebnisse liefert, würde ich es ruckeln lassen und danach halt langsamer laufen lassen. Das Problem hat man immer, ist der Rechner nicht stark genug für ne Echtzeitanwendung kann sie halt nicht vernünftig in Echtzeit laufen, da kann man noch so viel tricksen.

Ich umgehe dieses Problem wie gesagt mit den Ticks (entweder ich multipliziere es mit der Anzahl oder ich benutze eine Schleife), aber ob das für alle Probleme eine Lösung ist kann ich nicht sagen. Ist mein erstes Game

@Jonathan:
Nein, das ist eben kein anderes Problem.
Ein Game hat drei Möglichkeiten:

1) Es bringt viele FPS.
1.A) Ich lasse es schneller laufen durch die Verwendung statisches Updates, was bei 120FPS im Gegensatz zu geplanten 60FPS immerhin doppelten Speed bedeutet, was manche Spiele sicherlich komplett unspielbar machen könnte.
1.B) Ich multipliziere meine Updates mit der Frametime und addiere immer fröhlich iterativ. Klar, geht, ist aber unnötig (un)genau durch viel zu viele Updates und immer größer werdende numerische Fehler. Auch 1 oder 2% können eben 1 oder 2 Pixel neben der geplanten Position bedeuten, was absolut unnötig ist und bei manchen Games zusätzliche, unnötige Prüfungen notwendig macht, damit ein Objekt nicht durch Wände oder sonstewas hindurch-iteriert.
1.C) Ich berechne meine Updates unabhängig von den FPS durch die Verwendung der generell verstrichenen Zeit, was die Berechnung eben exakt macht, egal zu welchem Zeitpunkt. Ich kann genau vorhersagen, wann mein Objekt wo ist. Bei iterativen Systemen geht das eben nicht.
1.D) Ich verwende parallel laufende Berechnung des Modells in einem Thread mit fester Framezahl nach Methode 1.A, 1.B oder 1.C. Das löst das Problem aus 1.A (bei der Verwendung der Methode aus 1.A), aber noch immer nicht das aus 1.B (bei der Verwendung der Methode aus 1.B).

2) Mein Spiel läuft so schnell, wie geplant.
In diesem Fall laufen alle Ansätze auf das gleiche hinaus, bis auf den Vorteil in 1.C, welcher hier ebenfalls gilt.

3) Mein Spiel bringt wenige FPS. Da bleibt mir wieder die Wahl:
3.A) Das Spiel läuft langsamer. Bei 30 FPS im Gegensatz zu geplanten 60 FPS immerhin nur noch halb so schnell. Das kann beim Spieler sehr schnell in Frustration ausarten und ist unnötig.
3.B) Ich benutze wieder die Multiplikation mit der Frametime. Zusätzlich wird die Berechnung unter Umständen ungenau durch zu seltene Updates. Lässt sich beheben wie in 3.C durch die Berechnung zusätzlicher Zwischenschritte. Die Ungenauigkeiten aus 1.B bleibt aber in jedem Fall bestehen.
3.C) Siehe 1.C. Ich muss im günstigsten Fall weniger Berechnungen durchführen (so viele, wie ich FPS habe), was aber natürlich in gewissen ungünsten Situationen nicht möglich ist, weil die Simulation mehr Updates verlangt. Dennoch ist es numerisch genauer als 3.B. Zudem bleibt mir noch immer die Wahl mehr Zwischen-Schritte zu berechnen, sofern die Performance es zu lässt (wenn 90% der Frametime auf die GPU gehen, dann ist das z.B. gar kein Problem). Damit nähere ich mich wieder an eine Lösung aus 1.D unter Verwendung der Berechnung aus 1.C an.
3.D) siehe 1.D, sofern die Performance es zulässt (hier gilt die gleiche Bedingung bezüglich CPU/GPU-Last wie in 3.C)

Meine Wahl ist die zu 1.C/3.C oder 1.D/3.D mit der Berechnungsvorschrift aus 1.C/3.C, denn dort habe ich die Wahl, wie ich die Simulation laufen lassen will und habe nur dann ein System, was bei Bedarf genau wie die anderen Methoden viele kleine Schritte machen kann, allerdings auf die ständige Addition und damit die Aufsummierung der Fehler verzichtet und weniger Schritte machen kann, falls es möglich ist.


Aussetzer von 1+ Sekunden kann man lösen, wie man will. Manchmal kann es besser sein die dazwischen vergangene Zeit nicht dem Spieler zur Last zu legen, manchmal ist aber genau das eben notwendig oder wünschenswert. Alle der oben genannten Ansätze (außer die A-Varianten) können das Problem aber auf beide Arten handhaben. Die Wahl ist dem Entwickler überlassen.