Geschwindigkeitsoptimierung von VB-Scripten - Artikel von www.it-academy.cc

- - - Geschwindigkeitsoptimierung von VB-Scripten

Geschwindigkeitsoptimierung von VB-Scripten

Dieser Artikel zeigt wie man den VB-Sourcecode eines selbst programmierten Computerspiels optimieren kann.

Autor:	Tobias Surmann (incsoft)
Datum:	31-03-2003, 00:42:02
Referenzen:	http://www.vbDirectX.de
Schwierigkeit:	Fortgeschrittene
Ansichten:	4175x
Rating:	8 (2x bewertet)

Hinweis:

Für den hier dargestellte Inhalt ist nicht der Betreiber der Plattform, sondern der jeweilige Autor verantwortlich.
Falls Sie Missbrauch vermuten, bitten wir Sie, uns unter missbrauch@it-academy.cc zu kontaktieren.

[Druckansicht] [Als E-Mail senden] [Kommentar verfassen]

Einleitung

Du hast also ein Spiel programmiert? Doch leider läuft das Spiel nicht allzu schnell: Du freust dich über eine Framerate im zweistelligen Bereich. Also muss die Geschwindigkeit optimiert werden. Besonders als Anfänger kann es einem bei der Programmierung nur allzu schnell passieren, dass man hier oder da ein paar Zeilen überflüssigen Code schreibt oder performancefressende Funktionen benutzt.

Zuerst sollte die Anzahl und die Größe der Surfaces im Speicher überprüft werden. Diese spielen eigentlich keine allzu große Rolle. Doch wenn man eine Grafikkarte mit nur wenig Speicher besitzt, und die Surfaces dann nicht mehr in diesen Speicher reinpassen, dann hat man ein großes Problem. Der Computer legt dann neue Surfaces im Systemspeicher an und dieser ist nicht annähernd so schnell wie das VRAM auf der Grafikkarte. Am besten man sagt DirectDraw bei der Initialisierung explizit, dass Surfaces nur im Speicher der Grafikkarte angelegt werden sollen. Wenn dann ein Fehler auftritt, weiß man schon mal warum das Programm so langsam läuft. Dann kann man sich entweder eine neue Grafikkarte mit größerem Speicher kaufen oder man denkt darüber nach, wie man den Platzbedarf der Grafikdaten verringert. Dies kann man z.B. durch eine Konvertierung in 16-Bit-Farben erreichen.

Die Geschwindigkeit einer DirectDraw-Anwendung hängt stark von der Anzahl der geblitteten Surfaces ab. Bei der Programmierung eines Spiels, welches auf Tiles zurückgreift, um z.B. eine Landschaft o. ä. anzuzeigen, ist es wichtig, sich vorher Gedanken zu machen, wie groß die Tiles sein sollen. Je mehr Tiles man hat, desto detailreicher kann man die Landschaft darstellen, aber desto länger dauert auch der Bildaufbau. Wenn man weniger Tiles einsetzt, kann man auch die Landschaft nicht so detailreich gestalten. Man muss also je nach Spiel und Genre sehen, was der beste Kompromiss zwischen Grafikqualität und Darstellungsgeschwindigkeit ist.

Wenn du viele Berechnungen in deinem Code durchführst und es nicht ganz so sehr darauf ankommt, dass die Berechnungen exakt sind, ersetze die "normale" Division, also z.B.

c = a / b

durch die Integer-Division, z.B.

c = a \ b

Dies bringt meist einen Geschwindigkeitszuwachs von mehr als 100% für diese Berechnungen.

Wenn du viel mit Sin- und Cos-Funktionen arbeitest, ziehe in Erwägung die Ergebnisse vorher zu berechnen und in einem Array zu speichern. Dann dauert die Initialisierungsphase des Spiels zwar etwas länger, aber während des Spiels ist der Bildaufbau deutlich schneller. Du schreibst also in die Initialisierungsroutine zusätzlich:

Dim Sinus(360) As Double 
'besser global um überall darauf zugreifen zu können
Dim Cosinus(360) As Double 

For i = 0 To 360 

Sinus(i) = Sin(i)
Cosinus(i) = Cos(i) 

Next i

Danach kann man über z.B. Sinus(90) den schon errechneten Wert abfragen.

Beim Prüfen von booleschen Variablen ist bei

If c = True Then

das "= True" natürlich überflüssig. Wenn c wahr ist, ist auch die Bedingung sofort wahr, also kannst du schreiben:

If c Then

Wenn du auf False prüfst ist es so am Schnellsten:

If Not c Then

Und beim Wechseln des Zustands von booleschen Variablen schreibst du anstatt

If c = True Then
c = False
Else
c = True
End If

einfach

c = Not c

Zum einen ist der Quelltext viel kürzer und man spart sich damit etwas Tipparbeit. Zum anderen ist auch die Ausführung aufgrund des logischen Operators Not viel schneller. Wenn es also geht, sollte man immer logische Operatoren mit booleschen Variablen verwenden.

Ein anderer häufiger Fehler tritt beim Vergleich von Strings auf. So testet man z.B. häufig:

If c <> "" Then

oder

If c = "" Then

Aber dabei wird immer ein String verglichen, was ziemlich langsam ist.

Am Besten ist einfach, nur die Länge der Strings zu vergleichen, also:

If Len(c) > 0 Then

oder

If Len(c) = 0 Then

Abschluss

Abschließend bleibt zu sagen, dass es immer eine Möglichkeit gibt seinen Quellcode zu optimieren. Dies kann man nicht nur wie hier dargestellt durch die Benutzung von passenderen Befehlen erreichen. In vielen Fällen kann man eine erhebliche Geschwindigkeitssteigerung durch die Implementierung eines besseren Algorithmus erreichen.

paedubucher
Professonial

Beitrag vom:
06-11-2006, 23:29:36

Kurzer VBA-Code ist nicht gleich kurzer Maschinencode

Vorweg; ich kenne die Details der VBA-Implementierung nicht! Bei einigen Tipps hatte ich jedoch den Eindruck, du gehst davon aus, dass kurzer VBA-Code auch schnellen Code bedeutet. Viele äquivalente Ausdrücke können den gleichen Maschinencode zur Folge haben! So kann dir ein intelligenter Compiler solche Pannen, wie du sie beschreibst, schon einmal ganz gut beheben.

Zudem halte ich Sachen wie Vergleiche von Primitivtypen nicht für den Performance-Flaschenhals in einem VBA-Spiel. Es ist vielmehr die Grafik, aber das hast du ja zu Anfang des Artikels prima beschrieben. :-)

-----------------------------------------------------

[back to top]

User nicht eingeloggt

Autoren:04150
Artikel:00819
Glossar:04124
News:13569
Userbeiträge:16268
Queueeinträge:05150

Ihre Anforderungen an ein Online-Zeiterfassungs-Produkt?