Zitat von
Antigo:
zu der Wurfparabel: Ich würde gern flexibler bleiben. WIe gesagt möchte ich den Ball auch gerne gegen eine Wand fliegen bzw. dort abprallen lassen. Das haut mit der Wurparabel natürlich nicht hin. Bei Vektoren muss ich da z.B. nur die x1 Komponente umdrehen.
Wie ich meinte: Du berechnest bei der Wurfparabel, obs ne Kollision gibt. Die Wand musst du natuerlich in die Kollisionsberechnung miteinfliessen lassen. Du speicherst dir dafuer den Kollisions(zeit)punkt, und wenn das Objekt diesen erreicht hast, handelst du dementsprechend, indem du bspw. die x-Komponente negierst oder einen physikalisch gesehen etwas flexibleren Algorithmus zum berechnen des Austrittsvektors durchfuehrst. Der Austrittsvektor ist dein neuer Vektor, mit dem du die Wurfparabel berechnest und die naechste Kollision berechnest.
Welchen Vorteil das hat? Ein Beispiel:
du hast eine Kugel, und 2 Waende, die (relativ) weit ausseinanderstehen. Nehmen wir an, die Kugel braucht 200 Takte zu je ein paar ms, um von einer Wand zur anderen zu gelangen.
Wenn du nun bei jedem Takt auf Kollision pruefst, pruefst du in einem Flug 200mal auf Kollisionen, wobei nur einmal eine Kollision auftritt. D.h. nur 0.5% der Berechnungen waeren wirklich notwendig gewesen.
Wenn du die Kollision mit der Parabel berechnest, so berechnest du in einem Flug einmal, um zu wissen, wo die Kollision auftritt. D.h. bei der anderen Variante rechnest du 200mal so oft, mit dem selben Ergebnis. Zudem loest die Wurfparabel auch das zweite Problem:
Zitat von
Antigo:
zu dem Time Based Movement: Ich habe schon verstanden wie das funktionieren soll. Mein Problem ist auch nicht die Bewegung, sondern wie gesagt die Vektoranpassung.
Wenn ich jetzt eine Framerate von 20FPS habe, wird der Timer 20 mal in der Sekunde aufgerufen. Die Pixelverschiebung kann ich durch das Time based Movement leicht anpassen, indem halt nur einen Bruchteil von pixeln gehe. Hier ist nicht das Problem.
Habe ich nun 20 FPS, wende ich auch folgendes 20 mal pro Sekunde an:
Delphi-Quellcode:
Ball.vektor.addieren(Gravitation);
Ball.vektor.addieren(wind);
Habe ich jetzt aber nur 10 FPS, wird der Vektor nur 10 mal pro Sekunde angepasst, und die Flugbahn sieht anders aus. Genau das muss ich jetzt irgendwie kompensieren. Aber ich hab absolut keinen Ahnung wie...
edit: Und dann kommt noch das Geschwindigkeitsproblem hinzu. Ich will abhängig von der Länge des Vektors des Balles natürlich auch eine größre Strecke in der selben Zeit zurücklegen. Ohne Time Based Movement habe ich wie gesagt einfach die Länge des Vektors genommen, und bin soviele Pixel auf einmal gegangen. Was zwar nicht schön aussah, aber geklappt hat....
Ok, das Problem ist: durch unterschiedliche Zeitdifferenzen gibt es leicht abweichende Flugbahnen, da du diese immer nur zu bestimmten Punkten berechnest, und der naechste Punkt vom vorherigen Abhaengig ist. Diese Abhaengigkeit bringt dir die Abweichung in der Flugbahn.
Mit der Parabel hast du keine Abhaengigkeit vom zuvor berechneten Punkt. Du hast die entsprechende Parabelfunktion, mit der du berechnen kannst, zu welchem Zeitpunkt sich das Objekt wo befindet. Die Parabel ist dabei natuerlich abhaengig von der Geschwindigkeit v0 des Vektors. Wenn du die Parabel zusammen mit dem Timebased Movement verwendest, kriegst du, was du brauchst: Du speicherst dir lediglich nicht die Zeitdifferenz zum vorherigen Tick, sondern seit der letzten Parabel-neuberechnung. Die Position des Objektes erhaelst du dann, indem du einfach in die Parabelfunktion die vergangene Zeit einsetzt.
Damit hast du:
- Eine Kollisionserkennung, die durchgefuerht wird, wie oft es noetig ist (naemlich genau einmal bis zwischen einer kollision und der naechsten)
- Timebased Movement ohne den Nachteil der Abhaengigkeit der zuvor berechnenen Position
Also eine doch ganz akzeptable Loesung
greetz
Mike