Seite 1 von 1

2D-Spiel, Steps mit Timer oder besser mit Thread?

Verfasst: 18. März 2008 00:44
von Funkelzahn
Hi :D

Ich habe ein bischen Erfahrung mit C++ und habe mich auch kürzlich mit QT angefreundet. Einen simplen Tronclon für den Anfang habe ich schon hinbekommen (Pixel fährt über ein Spielfeldraster, man kann mit den Pfeiltasten die Richtung ändern, ...).

Das klappt soweit ganz gut mit einem QTimer (bei jedem Timeout wird ein Step gemacht, d.h. das Objekt bewegt sich um einen bestimmten Betrag und das Bild wird neu gezeichnet), allerdings scheint es mir, dass unter Win2K der Timer minimal bis zu ca. 50ms liefern kann oder darüber (unter Linux scheint das gleiche Programm schneller zu laufen). Damit bekommt man also nur ca. 20 fps hin, besser wären aber 30 oder mehr.

Sollte man so etwas lieber mit Threads lösen (einfaches Spiel mit 2D-Grafiken, Sprites, ...) und kann mir dann jemand einen simplen Beispielcode posten, der Thread und QPainter kombiniert?

Verfasst: 18. März 2008 09:07
von upsala
Aus der Doku:
Note that QTimer's accuracy depends on the underlying operating system and hardware. Most platforms support an accuracy of 1 millisecond, but Windows 98 supports only 55. If Qt is unable to deliver the requested number of timer clicks, it will silently discard some.
Sollte es aber trotzdem nicht hinzubekommen sein, kannst du auch eine Thread erstellen, mit einer Endlosschleife, die immer x-Millisekunden wartet und dann ein Signal sendet. Das wäre zumindest das einfachste...

Verfasst: 18. März 2008 09:20
von Christian81
Für Rendering in einem Extra-Thread empfiehlt sich das mandelbrot - example.

Verfasst: 18. März 2008 18:01
von Funkelzahn
Hm, das Beispiel mit Mandelbrot arbeite ich gerade durch, aber ich frage mich, ob das das Richtige ist ... dort wird der Thread ja verwendet, damit das Programm weiterhin auf Eingaben regaieren kann, während die umfangreichen Berechnungen laufen.

Da wird aber nur nach einer Usereingabe eine Neuberechnung und damit ein update() ausgeführt.

Ich bräuchte da dann wohl eher einen Thread der mit "forever" läuft und muss dann am besten selbst die verstrichene Zeit messen und dann nach Ablauf einer gewissen Zeitspanne ein update() ausführen. Das soll ja bei mir regelmässig passieren und nicht nur dann, wenn der User etwas gemacht hat.



edit: mit Thread komme ich jetzt auf maximal 60 fps bei einem Pentium 4 mit 1.6 GHz, der nebenbei noch was anderes macht. Das ist schon nicht schlecht, allerdings könnte es auch noch viel schneller sein...

Verfasst: 19. März 2008 22:24
von Funkelzahn
ein Kollege hat das gleiche unter Linux laufen lassen und kommt auf ca. 300 fps ... hat noch jemand eine Idee, wie man unter Windows zu annähernd gleichen Ergebnissen kommt?

Verfasst: 26. März 2008 00:55
von Funkelzahn
Leider ist das Beispiel Mandelbrot nicht das passende, da dort der Thread nur im Hintergrund anspringt, wenn der User eine Eingabe getätigt hat. Ich brauche aber eher einen Thread, der automatisch alle 30 Milisekunden feuert und zeichnet (möglichst QPainter).

Nachdem ich mir jetzt schon eine Woche lang die Zähne daran ausbeiße, hoffe ich, dass mir jemand einen Beispielcode zeigen kann (Thread soll alle paar Milisekunden ein Signal senden und dabei ein Objekt mit QPainter aktualisieren (einfache Sprites oder geometrische Figuren)).

Ich habe auch schon versucht einen extra Thread einzubinden, der meinen Thread aus dem Mandelbrotbeispiel anfeuert, nur dann meldet er leider, dass Thread::run doppelt vorhanden ist, obwohl die Klassen unterschiedlich heissen (RenderThread::run und Thread::run).