spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Ok, das wird mir jetzt echt zu blöd. Ihr seid entweder nicht in der Lage meine geschriebenen Texte vernünftig zu lesen (denn ich sage es nun zum 10ten Mal: Nicht jede Simulation lässt sich damit vernünftig lösen, aber solche nicht-analytisch lösbaren Simulationen werden hier auf SPPRO aber nur äußerst selten durchgeführt! Auch das Beispiel von 3D-Shootern ist im Übrigen prima auf diese Art lösbar und ich sehe hier auf SPPRO nun wirklich nicht allzuviele 1st oder 3rd Person Games. Mal davon abgesehen dass meine Variante EBENFALLS eine Zeit-diskrete Art der Berechnung in kurzen Intervallen durchführen KANN, FALLS es NOTWENDIG sein sollte).

Aber echt, ich hab' keinen Bock mehr, ich bin raus aus dem Thema. Wer es nicht verstehen will, der will es eben nicht verstehen. Macht doch eure statischen Updates oder multipliziert mit der Frametime, wenn euch das glücklich macht. Ich jedenfalls werde weiterhin versuchen die numerischen Problem da zu umgehen, wo man sie umgehen kann. Ich habe mich jetzt bei weitem oft genug wiederholt.

Schönen Tag noch.

Ich kann nur empfehlen folgendes Thema im Physics Simulation Forum mal anzuschauen. Dort werden einige Probleme, die durch zu große Timesteps (was ja im Grunde ein Teilproblem von variablen Timesteps ist; bei fixed Timestep ist es wenigstens ein kontrollierbares Problem, da man ja die Länge des Timestep kennt) erzeugt werden angesprochen und es wird diskutiert wie man "beliebig" lange Zeitspannen durch kontinuierliche Kollisionserkennung realisieren kann. Bullet implementiert kontinuierliche Erkennung AFAIK auf experimenteller Basis...
http://www.bulletphysics.org/Bullet/phpB…php?p=&f=4&t=20
Außerdem ist dieser Wikipedia Abschnitt auch interessant: http://en.wikipedia.org/wiki/Continuous_…28continuous.29

Also ich hab es bis jetzt so gemacht :



Wenn ich dann ein Sprite bewegen will * ich frameTime mit der bewegung z.b.: (positionX += movePos * frameTime).
Jetzt wollte ich fragen ob meine lösung doch nicht so gut ist?

Meine lösung is doch jetzt unabhängig vom FPS oder seh ich das falsch?

MFG
JasonB

Jo, sollte passen.

Nur sie ist nummerisch instabil, weil du nur die frameTime berücksichtigst.

Am einfachsten lässt sich das Grundproblem damit beschreiben, dass für sagen wir eine Zeit von 10 Sek bei reiner Berücksichtigung der frameTime für gefolgende Gleichung immer andere Werte erhalten:
absTime += frameTime;
Der Wert von absTime wäre in einer perfekten Welt immer genau 10 (Da 10 Sek vorgegeben waren). Mit fexibler frameTime und den Rundungsproblemen ist absTime aber selten genau 10. Und je mehr Updates gemacht wurden umso ungenauer wird der Wert.
Wenn man nun aber fixe Schrittweiten nimmt und die Anzahl der Updates möglichst genau eingrenzt, dann ist zwar auf Grund der Rundungsprobleme der Wert immernoch nicht genau 10, aber dafür ist er immer gleich nach gleicher Schrittzahl egal wieoft man das Ganze durchlaufen lässt.

Und wie kriegst du fixe Schrittweiten hin? Man könnte am Ende einer Frame sleep benutzt um X Millisekunden zu warten, aber das ist eher ein Richtwert, er wird nicht genau so lange warten. Außerdem berücksichtigt das ja nicht die Zeit zur Berechnung des letzten Frames, also selbst wenn sleep genau x ms warten würde, würds nicht gehen.
Ansonsten kannst du natürlich sowas wie aktives Warten benutzen, und immer gucken wie viel Zeit vergangen ist, und wenn genug Zeit rum ist, die Schleife abbrechen. Aber du bist nicht alleine, andere Threads wollen auch rechnen, damit wirst du also auch nie genau darauf landen.

und jetzt mal ehrlich: Wer merkt ob ein Spiel um ein tausendstel oder zehntausendstel schneller oder langsamer läuft?

Ich glaub ich mach gleich mal eine Beispielanwendung mit simulierten Lags um mal zu zeigen wie sich das auf die Bewegung von Objekten auswirken kann, die sich nicht linear bewegen x)

Ok, was man machen kann ist, die Zeit, wann das Spiel gestartet hat zu speichern und nach jeder Frame zu gucken, wie viel Zeit seit dem vergangen ist. Dann weiß man zwar immer noch nicht genau, wann der nächste Schritt anfängt, aber man ist nach ner Stunde wenigstens keine 2 Sekunden schneller oder langsamer gewesen.

Das ist übrigens dann in etwa das, was ich von Anfang an erzählt habe.