FPS-unabhängige Bewegungen (Zeitbasierte Bewegung)

Started by cocojack, June 08, 2013, 06:58:31 PM

Previous topic - Next topic

cocojack

Schönen guten Abend,

ich bastele momentan schön fleißig an meiner App für mein Android-Tablet.

Mir ist leider (oder zum Glück) ein Problem aufgefallen.

In den Beispielen wie z.b. das Car-Example sind alle Bewegungen so wie die Kollisionsberechnung im On-Draw Frame.
Das Problem dabei ist, dass das die Frame-Rate extrem einbrechen lässt wenn ich das dort machen lasse. Also habe ich das ganze in einen Thread ausgelagert, welcher dann die Bewegung und Kollisionsberechnung ausführt.

So wird dann der nächste Punkt des Objekts berechnet, und dann im on draw Frame verschoben.

Problem ist dabei nur dass die Bewegung dann stark fps-abhängig ist.

Mir fällt momentan leider kein Konzept ein wie ich das vermeide.

Kann mir da jemand weiterhelfen?

EgonOlsen

Ich persönlich sehe in dieser Trennung nur bedingt Sinn. Der Renderthread kann ja nur das berechnen, was der Logikthread an Updates liefert. D.h. letztendlich wartet er entweder auf den Logikthread...dann bringt die Trennung ja nichts, oder er rendert Bilder, die sich gar nicht verändert haben...dann steigen zwar die FPS, aber zusätzliche Informationen werden nicht gerendert, nur bestehende mehrfach.
Einziger Vorteil wäre es zeitliche Überlappung, d.h. während des Renderns könnte schon die nächste Kollisionsberechnung laufen...aber da muss man sehr darauf achten, dass jPCT-AE nicht threadsicher ist. Und letztendlich bringt auch das nicht viel, weil das Rendern an sich sowieso auf der GPU parallel zu den Berechnungen der CPU läuft.

Aber wenn es unbedingt so sein soll: Die Logik sollte zeitabhängig sein, d.h. entweder die Zeit seit der letzten Berechnung messen oder mit Ticks arbeiten (das bevorzuge ich, weil es einfacher ist), d.h. alle x ms zählt ein Zähler hoch und die Logik richtet sich nach dem aktuellen Stand dieses Zählers. Das sollte man aber immer so machen, auch mit nur einem Thread.
Zusätzlich, weil jPCT-AE eben nicht threadsicher ist, muss man genau darauf achten, nicht etwas an Objekten zu ändern, die gerade gerendert werden. Spätestens das dürfte die minimalen Vorteile ohnehin wieder auffressen.

cocojack

das mit der threadsicherheit habe ich auch schon gemerkt, wenn man pech hat bekommt man null-pointer exceptions bei z.b. wenn ein object3d gerendert wird, in einem anderen thread aber grade bewegt wird.

ok das mit den ticks hört sich ganz gut an, ich werd mal sehen ob ich das umsetzen kann.