Nachdem ich Narses Tutorial zum Protokoll gelesen hatte, wollte ich zwecks Übung eins von diesen Weltraumshootern proggen.
Dabei hab ich ein Spielfeld von 3000*3000 Einheiten (je ein Pixel). Da dies zu groß für einen Bildschirm ist, sieht man am Rand in einer Art Radar, wo man sich auf dem Spielfeld befindet. Wenn man mit der Maus klickt, startet man einen Timer und alle 200ms wird ein Schuss erzeugt. Dieser behinhaltet vier Real-Werte: x/y Position sowie geschwindigkeit. Zusätzlich noch ein Bild.
Alle paar Zeitabstände sendet der Server dan den Befehl für die Ausführung alles zu bewegen.
Aber bereits bei mehr wie 50 Schüssen reicht die Rechenleistung nicht mehr -.- .
Ich habe mir gedacht, dass es daran liegt, dass es viele Bilder auch auserhalb des Bildschirms zeichnet.
Also habe ich versucht, mit einer IF - Abfrage zu testen, ob das Bild auf dem Bildschirm wäre. Falls nicht, wird es nicht verschoben, sondern nur seine Positionsvariablen angepasst. Allerdings trug dies nichts zur Performance bei.
Wieso ist das bei so relativ wenigen Bildern bereits so lahm (Beispiel Spiele wie Warcraft - da wird weitaus mehr gemalt).
Und wäre es vielleicht besser, wenn ich auf die ganze Form ein großes Image ziehe und die Schüsse als Shapes bewege.
(Aber selbst wenn - die abzuschiesenden Ufos sollen nicht nur ein Shape sein sondern schon etwas besser aussehen - wie mache ich es dann mit denen?).
Eine andere Überlegung von mir war, dass ich einen zweiten Thread starte, der fürs Bilder verschieben verantwortlich ist (mit einer Schleife), während der andere nur rechnet. Aber so werden a) Viele Bildsequenzen übersprungen und b) war es auch nicht viel schneller.
Irgendwelche vorschläge wie ich das machen könnte?


Moderiert von Narses: Topic aus Delphi Language (Object-Pascal) / CLX verschoben am Di 16.09.2008 um 12:48

Spiele zeichnen normal Hardwarebeschleunigt. Mit anderen Worten sagen sie nur zeichne das und das und die Grafikkarte macht das dann automatisiert und um ein vielfaches schneller als es mit der CPU je möglich wäre. Dabei wird dann entweder OpenGL oder direct3d verwendet. Wenn es später irgendwann mal etwas komplexer werden soll, dann wirst du meiner Meinung nach um solchen einen Schritt nicht umherum kommen. Ich persönlich würde aber aus nicht näher erwähnenswerten Gründen OpenGL empfehlen.

Aber zum jetzigen Zeitpunkt kommt es natürlich darauf an wie du zeichnest und wie die Kommunikation abläuft. Übertragen darfst du natürlich nur die ID und die Positionen der Schüsse. Beim Zeichnen würde ich so vorgehen, dass du zu erst den Hintergrund in einen Bufferbild zeichnest und anschließend die Schüsse dort drauf plazierst. Dieses Bild wird dann auf das Fenster gemalt.
Um Leistung einzusparen würde ich ein Temporäres Hintergrundbild erstellen was genau die Größe der Ansicht hat. In dieses zeichnest du den Hintergrund und zeichest es zukünftig anstelle des richtigen Hintergrundes. Das Temporäre bleibt so lange erhalten bis sich die Ansicht verändert. Dann muss ein anderer Auschnitt des Spielfeldes gezeigt werden.

Allerdings wie oben schon erwähnt kannst du ohne Hardwarebeschleunigung keine Wunder erwarten. Und ich habe keine Ahnung ob der zweite Tipp überhaupt etwas hilft, denn beim Zeichnen gibt es so viele Dinge die man verkehrt machen kann, dass es unmöglich ist alles aufzuzählen. Mit anderen Worten da fehlt vermutlich etwas input von deiner Seite. Aber bevor du die ein oder andere Richtung weiter ausdehnst solltest du überlegen was du mit dem Programm später alles anstellen willst. Also ob daraus ein kleines spiel werden soll etc...

Hmmm also OpelGl werd ich mir dann wohl anschauen - schaden kann es ja nie mehr zu wissen wie nötig
Übertragen wird eigentlich kaum was zu den Schüssen - der Client sendet ne Anfrage zusammen mit x+y Richtung des Schusses - der Server sendet dann allen Clienten die Position und Richtung des Schusses - danach sendet der Server erst wieder, wenn der Schuss mit etwas kollidiert. Da er ja vor jedem Zeitschritt auch wartet, ob die Clienten bereit sind besteht eigentl. keine Gefahr der Asynchronität - weitere übertragungen sind somit eigentl. nicht notwendig.
Zu Dingen die man verkehrt machen kann - bis jetzt hatte jede Kugel ein Image, dass mit .top/.left verschoben wurde.
Ein Bild mit der Kugel schwebt als Bitmap herum, die dann immer von neuen Schüssen bei erstellung übernommen wird.
Meinst du es lohnt sich das ganze mit dem großen Image zu versuchen, bis ich iwas gutes mit opengl hinkrieg oder ist das eher n dead-end, sprich: soll ichs gleich sein lassen?

Wenn du mehrere visuelle Komponenten (TImage) benutzt und diese verschiebst, dann vielleicht auch noch das gesamte Spielfeld immer in einem TImage hälst statt nur dem aktuellen Ausschnitt, etc., dann musst du dich nicht wundern, wenn das ganze extrem langsam ist.

Da hat Lossy eX ja auch in seinem zweiten Absatz bereits etwas gesagt wie es sinnvoller ist.

Ok, bin grad dabei mir die Bibliothek herunterzuladen und Tutorials zu lesen.
Danke für die Hilfe,
MS

Habe ich in einem anderen Thema gerade schon geschrieben. Für OpenGL kannst du dir auch mal das Quickstart Tutorial auf DelphiGL.com anschauen. Das ist speziell für solche einen Fall gemacht worden.