spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Also nimmst du für einfache Mechanismen erheblichen Mehraufwand in Kauf (siehe meine Beispiele)? Oder stelle ich mir das grundsätzlich falsch vor?

Denn mir geht es eigentlich ähnlich: Mir ist es noch nie vorgekommen, dass ich eine variable Framerate benötigte, und trotzdem hatte ich keine Probleme mit unerkannten Events.

Zitat von »"Nexus"«

Also nimmst du für einfache Mechanismen erheblichen Mehraufwand in Kauf (siehe meine Beispiele)? Oder stelle ich mir das grundsätzlich falsch vor?

Denn mir geht es eigentlich ähnlich: Mir ist es noch nie vorgekommen, dass ich eine variable Framerate benötigte, und trotzdem hatte ich keine Probleme mit unerkannten Events.

Naja. Ein Aufwand ist es ja nicht. Du musst einfach einen Wert hinzumultiplizieren. Fertig. Und das hat den netten Nebeneffekt, dass du dein Spiel auch sehr langsam oder schnell laufen lassen kannst. Und einen "Rückspuleffekt" ist ev. auch möglich.

Letztendlich ist es ja nun auch echt kein Problem, im Bedarfsfall schnell umzuschalten. Wenn man eh schon ein Zeitdelta übergibt, setzt man es halt auf 1/30 und stellt halt in der Mainfunktion oder wo auch immer fest, dass dies genau 30 mal pro Sekunde aufgerufen wird.
Dann kann man auch sagen "ich peile mal so grob eine feste Framerate von 30 an", misst aber zusätzlich noch die Zeit um halt mal 1/28 oder 1/33 zu übergeben.

Ich hab selber im Moment eine flexible framerate, überlege aber die auf Werte zwischen 10-20 und 100 zu begrenzen. Bei zu niedrigen Frameraten läuft das Spiel dann halt langsamer, bei zu hohen wird etwas gebremst. Das sollte schon die meisten Probleme die bei der Physik auftreten können beheben.

Ja natürlich, multipliziert man immer die Zeit dazu! Das ist nicht das was ich unter fixed-framerate verstehe! Es wird lediglich versucht das Zeitdelta aus oben genannten Gründen konstant zu halten. aber die Zeit wird IMMER übergeben und bei allen (zeitlichen) Abläufen dazumultipliziert! so vereint man die Vorteile beider Verfahren!

Irgendwie hab ich das Gefühl, dass ich grundsätzlich was nicht verstehe...

Also bei dynamischen Frameraten kann sich ein Objekt (Sprite) einmal 3, einmal 5 und einmal 17 Pixel pro Frame bewegen. Meiner Ansicht nach braucht man hier zusätzlichen Aufwand (z.B. für Kollisionsabfrage, oder Ereignisse, die gleichmässig über die Strecke verteilt sein sollen, z.B. Partikelausstoss). Wieso soll das nicht so sein? Oder nimmt man das einfach in Kauf?

Und was ist mit "Rückspuleffekt" gemeint?

Naja, normalerweise hat man eine Framerate >30 und nur sehr selten Dinge, die öfter als 30 mal pro Sekunde passieren.
Es kann natürlich sein, dass man 100 Partikel pro Sekunde erstellen will, aber wirklich aufwändiger wird das durch eine variable Framerate doch auch nicht.