Niedrigerere FPS bei vielen Objekten (2D)

[Pille456]

Hi!

Wenn man etwas animieren will macht man das ja oft so,um auf jedem System eine gleichmäßige Bewegung zu bekommen, dass man einen Timer einbaut. Das habe ich auch gemacht, dieser Timer ruft halt alle 35ms (sollte ca. 30fps sein) die Render Funktion.
Keine Ahnung wie sich das im 3D Bereich mit Grafikkartenbeschleunigung (also OpenGL, DirectX) auswirkt, aber bei 2D APIs ohne direkte Hardwarbeschleunigung fiel mir auf, dass je mehr Objekte sich bewegen, je mehr sacken die FPS ab.
Also bei 5 Objekten z.B. bewegt sich noch alles ganz flüssig, bei 10 Stück hingegen merkt man schon ein deutliches ruckeln.
Der Grund dafür ist auch mehr oder weniger klar: Die Funktion hat eine längere Ausführungszeit als wie sie vom Timer gerufen wird. (was mich aber irgendwie wundert, weil ich eigentlich keine weltbewegenden Berechnungen durchführe)

Wie kann ich sowas umgehen?
Wenn ich die Timerzeit herabsetze habe ich wieder eine andere Grundgeschwindigkeit was ja auch nicht unbedingt Sinn der Sache ist. Oder sollte ich die Timerzeit dynamisch mit der Anzahl der Objekte ändern?

Cya
Pille

[Gast]

Hallo

Entweder stehe ich gerade auf dem Schlauch oder die Timeridee ist Mist. Mach doch einfach den Fortschritt der Animation von der Framerate abhängig und schon hast du keine unterschiedlichen Geschwindigkeiten auf unterschiedlichen Rechnern mehr. Mit was für einer API arbeitest du denn? 10 Objekte sollten ja nun wirklich möglich sein...

chrische

[Pille456]

Naja die Animation ist quasi eine unendlich gradlinig gleichförmige Bewegung, das heißt es gibt kein Ende außer der Benutzer will dies.
Ich arbeite derzeit mit den wxWidgets zeichnen Funktionen, werde aber später (wenn ich auf 3D umsteige) OpenGL nutzen.

[Gast]

Hallo

Pille456 schrieb:

Naja die Animation ist quasi eine unendlich gradlinig gleichförmige Bewegung, das heißt es gibt kein Ende außer der Benutzer will dies.

Na und?

Pille456 schrieb:

Ich arbeite derzeit mit den wxWidgets zeichnen Funktionen, werde aber später (wenn ich auf 3D umsteige) OpenGL nutzen.

Ich glaube man sollte wxWidgets nicht zum Zeichnen von Spielen nehmen,w eil das wahrscheinlich sehr langsam ist. Ich gehe mal davon aus, dass das Framework weniger auf Darstellungsgeschwindigkeit optimiert ist (ist bei GUI in der Regel ja auch nicht wichtig), als auf Komfort, Bedienbarkeit usw. Du solltest über einer Wechsel der API nachdenken. Ich kenne mich aber mit wxWidgets nicht aus und lasse mich gerne vom Gegenteil überzeugen.

chrische

[Isodrink]

Falls du die API wechseln möchtest, ist SDL (http://www.libsdl.org/) nicht schlecht, damit lassen sich zB. 2D Spiele ganz gut umsetzen. Und falls du dann irgendwann auch mal im 3D Bereich arbeiten willst, kannst du dies auch mit SDL (und OpenGL)
tun. Nebenbei kannst du mit SDL auch alles Mögliche andere tun: Timer, Keyboard, Ton, CD-DVD um nur einiges zu nennen. Und platformunabhängig ist das Ganze auch.

[Pille456]

Hmm derzeit kämpfe ich noch mit wxWidgets und dessen OpenGL Anbindung. Hab die ganze GUI in wxWidgets programmiert und will darum mittem im Projekt ungerne was wechseln.

[Isodrink]

Naja, wenn du mitten im Projekt steckst wird das wohl wirklich schwierig.
aber auf der anderen Seite ist natürlich richtig was chrische5 gesagt hat: Diese Bibliothek sieht so aus, als wenn sie eher dazu da währe Anwendungen zu schreiben, die einfach mit einem Benutzer kommunizieren, dem Programmierer also viel Kleinkrams abnehmen. Anwendungen, die mit dieser Bibliothek programmiert werden sind aber eher einfache Anwendungen, bei denen es nicht auf die Leistung ankommt, sondern auf einfache, komfortable und schöne Bedienung. (korrigiere mich einer wenn ich falsch liege)

[hustbaer]

Pille456 schrieb:

Der Grund dafür ist auch mehr oder weniger klar: Die Funktion hat eine längere Ausführungszeit als wie sie vom Timer gerufen wird. (was mich aber irgendwie wundert, weil ich eigentlich keine weltbewegenden Berechnungen durchführe)

Genau das wird der Grund sein. Der Teil wo die meiste Zeit draufgeht wird auch das Zeichnen der eigentlichen Objekte sein, also nicht in deinem eigenen Code, sondern in der Grafik-API die du verwendest. Wenn diese z.B. nicht hardware beschleunigt ist (GDI+, ...), dann geht da relativ viel Zeit drauf.

Wie kann ich sowas umgehen?
Wenn ich die Timerzeit herabsetze habe ich wieder eine andere Grundgeschwindigkeit was ja auch nicht unbedingt Sinn der Sache ist. Oder sollte ich die Timerzeit dynamisch mit der Anzahl der Objekte ändern?

Cya
Pille

Den Timer schneller zu machen wird wohl nix bringen. Der Grund dass es ruckelt wird sein dass die Ausführung der "update" Funktion länger als 35ms dauert - da hilft ein schnellerer Timer garnix.
Was du machen kannst: versuche den Code der die Objekte zeichnet schneller zu bekommen. Wenn du keine groben Schnitzer drinnen hast wird das vermutlich heissen: wechsel die Grafik-API auf eine die hardwarebeschleunigt zeichnen kann.

[Gast]

Die Frage ist außerdem, wie der Timer funktioniert. Also ob der nächste Timeraufruf genau 35ms nach dem davorgegangenen statt findet, oder 35ms nachdem die Timerfunktion beendet wurde.

Ist zweites der Fall, wir das Timerintervall ja größer als 35ms, weil es ja dann 35ms + Ausführungszeit der Funktion ist.

[hustbaer]

Wann die Timerfunktion beendet wurde (bzw. wie lange die Ausführung gebraucht hat) ist üblicherweise egal.
Und "genau" ist im Zusammenhand mit Timern schonmal garnix.

[Kóyaánasqatsi]

BACKFACE CULLING?

[Pille456]

Kenne die Technik nur im Zusammenhang mit 3D, nicht 2D..?
Timer ist sowieso so ne Sache:
Soweit ich weiss kann man auf einen sehr präzisen Chipsatztimer zugreifen (nicht steinigen wenn es falsch ist..), was aber nicht der Portabilität eines Programmes zu gute kommt, da dessen Ansteuerung ja von OS zu OS unterschiedlich ist.

[Gast]

hustbaer schrieb:

Wann die Timerfunktion beendet wurde (bzw. wie lange die Ausführung gebraucht hat) ist üblicherweise egal.

Bei FLTK gibt es für beide Verhaltensweisen jeweils eine Funktion. Also "üblicherweise" ist ja kein Argument, dass es nicht doch so sein könnte. Es ist vielleicht nicht das wahrscheinlichste, aber man sollte es in Betracht ziehen.

Aber ohne Anhaltspunkte sind das eh nur Vermutungen.

Nochmal zusammengefasst: Vielleicht verzichtest du auf den Timer ganz, falls du das nicht willst, überprüfe mal, indem du entsprechende Funktionen einfügst, wie lange dein Programm so in dem Timerevent verweilt. Wenn es halt zu lange ist, dann musst du halt ein Frame überspringen oder optimieren.

[Pille456]

Joa werde ich wohl im Endeffekt nicht drum herum kommen.
Erstmal habe ich mich darauf geeinigt die Animation(en) mit OpenGL zu implementieren, dann kann ich das Ganze auch gleich 3D gestalten. Wenn ich dann irgendwann an einen Punkt komme wo es ruckelt, dann werde ich wohl anfangen mein Programm dahingehend zu optimieren und auch über andere Timerfunktionen nachzudenken.