Guten Tag,

hier möchte ich die "Problem mit..."-Reihe fortsetzen...
(Viel mir nur gerade auf, weil Firefox mir als Titel "Problem mit Licht" und "Problem mit physikalischen Bewegungen" anbot...
Aber zum Thema:
In meinem derzeitigem Projekt funktioniert Timebased Movement soweit ganz gut und zuverlässig, ihr durftet es ja auch schon testen und es ging. Aber unter gewissen Vorraussetzungen läuft es TROTZDEM langsamer. Ich poste euch mal meine Schleife, erkläre dann die Funktionen und deren Anwendung und hoffe dann auf Hilfe!


Aaaaalso:
glhandleevents holt Events (mithilfe von SDL) und schreibt in ein array von booleans, ob eine taste gedrückt ist, losgelassen wurde.
processkeys verarbeitet dann gegenfalls die gedrückten tasten, ruft aber AUF JEDEN FALL die Function fürs Movement auf, die trunc(thetime/10) mal (NICHT round(thetime/10)!) Gegner, Schüsse, Sterne und mich bewegt. Halt was sich so bewegt...
Dann wird mit gldraw; gezeichnet, frames erhöht zum ausgeben in titelleiste über timer und alles dargestellt! ^^

Nun erfolgen die eigentlichen Berechungen fürs Timebased Movement.
newtime ist die jetzige Zeit (Die neue...).
Thetime wird als zehntel der differenz zur alten zeit errechnet (die am Ende der Schleife "gestoppt" wird), zuzüglich des nicht zuletzt behandelten restes, der in der nächsten Zeile rechnet wird.
Am Ende wird thetime sein eigener wert vermindert um die nachkommastellen zugewiesen.
Sollte thetime die 0 überschreiten, wird oldtime gesetzt und nächste runde passiert das gleiche nochmal.

Zur Erklärung des "Restes"...
Ich berechne nicht x+vergangeZeit bei Berechnungen, sondern vergangeZeit mal x+1, weil sonnst, könnte auf älteren PCs oder bei hohen rechnerischen belastungen ein Objekt "mal so" um 50 Pixel bewegen und "schwubs" durch ein anderes object hindurchfliegen. Und da das ganze mit "reiner Zeit" zu rechenaufwendig wäre (und die objekte nicht nur einen pixel groß sind...) rechne ich mit deren zehntel. Mir dem Nachteil, dass der Rest dringend mit zu beachten ist!

Achja, wie es SCHEINT, wird der Effekt mir der Geschwindigkeit des PCs und damit mit kleinen thetime-Werten verstärkt.

mfg Cyberpuer

_________________
Denn wer nur schweigt, weil er Konflikte scheut, der macht Sachen, die er hinterher bereut.
Und das ist verkehrt, denn es ist nicht so schwer, jeden Tag zu tun als ob's der letzte wär’.
Und du schaust mich an und fragst ob ich das kann.
Und ich denk, ich werd' mich ändern irgendwann.
_________________Farin Urlaub - Bewegungslos

Wenn ich mir das Ganze so mal schnell anschaue, glaube ich, dass der Fehler in dem "rest"-Teil zu finden ist. Trunc in einer Zeitberechnung halte ich für sehr ungenau, und eventuell kommen da auch negative Werte raus.
Mein Tipp: Probiers erstmal ohne den "rest"-Teil aus, und schau, obs so funzen würde.

_________________
"Du musst ein Schwein sein in dieser Welt, sangen die Prinzen, das ist so 1.0. Du musst auf YouTube zeigen, dass dir dein Schweinsein gefällt, das ist leuchtendes, echtes Web 2.0."
- Hal Faber
Meine Homepage: http://laboda.delphigl.com

Im Endeffekt nutze ich trunc sowieso später in einer Schleife (for a:=1 to trunc(thetime) do) und ohne des Rest, läuft es etwas "komisch" (LAHM) auf PCs mit Frames höher denn 100...

_________________
Denn wer nur schweigt, weil er Konflikte scheut, der macht Sachen, die er hinterher bereut.
Und das ist verkehrt, denn es ist nicht so schwer, jeden Tag zu tun als ob's der letzte wär’.
Und du schaust mich an und fragst ob ich das kann.
Und ich denk, ich werd' mich ändern irgendwann.
_________________Farin Urlaub - Bewegungslos

Das sollte aber nicht so sein. Wie weist du eigentlich die Zeit deinen Objekten zu?
Ich mein den Teil:
x:= x + vx * Time;

_________________
"Du musst ein Schwein sein in dieser Welt, sangen die Prinzen, das ist so 1.0. Du musst auf YouTube zeigen, dass dir dein Schweinsein gefällt, das ist leuchtendes, echtes Web 2.0."
- Hal Faber
Meine Homepage: http://laboda.delphigl.com