Hallo,
ich mach einfach mal nen neuen Thread auf, bevor in dem anderen die Übersicht verloren geht.

Also:
Ich habe eine Spielfigur, die kann sich drehen und dann in die jeweils ausgerichtete Richtung fliegen.

Je mehr zeug ich dem Level adde, desto langsamer fliegt die Figur. Ändere ich ihre Geschwindigkeitsvektoren, wird sie wieder schneller.

Anscheinend soll man das ganze ja mit diesem Time Based Movement lösen, doch: Die Drehung der Spielfigur, bzw. die Geschwindigkeit der Drehung lässt sich gar nicht ändern, da ich da ja keinen Vektor habe sondern nur Gradangaben.

Kapiere irgendwie nicht, wie ich das gescheit hinbiegen muss

Es ist nicht wichtig, ob du Vektoren oder Grad angaben hast.

Winkel = Winkel + Winkelgeschwindigkeit * dt

Ort = Ort + Geschwindigkeit * dt

Ist beides das selbe Prinzip. Das "* dt" bedeutet so etwas wie "pro Sekunde". Wenn du als Winkelgeschwindigkeit also 360 nimmst, sollte eine 360° Drehung in einer Sekunde erfolgen wenn ich mich jetzt nicht irre.

mfg

Stimmt, mit pro sekunde geht es, vielen dank, juhu

@Sispi: Hattest du dir das Timebased_Movement im Wiki durchgelesen? Ich frage, weil wir unsere Artikel ja immer besser machen wollen. Falls es irgendwo Verständnisprobleme gibt -> bitte sagen.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Den Artikel könnte man noch um nen paar Kleinigkeiten ergänzen:
* Frameratenlimitter nach oben, damit das Spiel auf sehr schnellen Rechnern nicht unnötzig CPU frisst. Außerdem werden bei zu kleinen Zeitdifferenzen Probleme mit der floatingpoint Genauigkeit relevant.
* Begrenzung der Zeitdifferenz, damit keine riesigen Zeitsprünge durchgeführt werden könne. 100ms=10fps sind hier ein guter Wert.
* Der letze Quellcode ist was die Zeitmessung angeht nicht mit den vorherigen konsistent, da er nur die Zeit innerhalb des Idle Handlers misst, und nicht die Zeit zwischen zwei aufrufen. Imo ist die Zeit zwischen Zwei aufrufen besser.

Der Variablenname "BerechnungsZeit" ist imo auch ungünstig gewählt. "VorherigeZeit" wäre besser, da BerechnungsZeit sich für mich nach der Zeitdifferenz anhört.

Außerdem könnte man darauf hinweisen dass QueryPerformanceCounter auf manchen Boards mit MehrkernCPU Sprünge macht. Da hatten wir afaik schon Threads dazu. Es gibt auch einen MSDN-Artikel der empfiehlt das Ergebnis von QueryPerformanceCounter mit GetTickCount abzugleichen.

_________________

zum Ersten: Ich denke, ein Minimallimit sozusagen, ist bei einigen Anwendungen nicht sinnvoll (muss man wenndann drauf hinweisen), das ist der Tod des Synchronisierten Ablaufes.

zum Zweiten: Zwischen zwei Aufrufen ist ganz schlecht. Denn dann kommst du sogar bei Idle manchmal schlicht und einfach auf fast 0, weil es sofort wieder aufgerufen wird. Besser ist da meiner Meinung nach das Messen von Beginn des letzten Renders bis zum Beginn des aktuellen Renders. Sodass man sozusagen einen Snapshot hat der gezeichnet wird und schon während dem Zeichnen die Zeit weiterläuft. Man kann aber auch trotzdem die zeit zwischen den Aufrufen messen und dann halt die Framerate limitieren (z.B. einfach Sleep(1); oder Sleep(10); aufrufen, wenn man auf einen entsprechend kleinen Wert kommt. Aber das musst dann auch mit in die Zeitmessung einfließen)

Gruß Lord Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Begrenzung der Zeitdifferenz ist nötig wenn du keine kontinuierliche Kollisionskontrolle hast. Und das haben die wenigsten Spiele. Notfalls muss man ein paar mal das Rendern auslassen. Auch muss man dann sehr aufpassen weil OnIdle durch einige aktionen ausgesetzt wird(z.B. offenes Menü)
Mit zwischen zwei aufrufen meine ich dass am anfang jedes frames einmal die Zeit gemessen wird. War also nur ungünstig ausgedrückt.

_________________