IT-Academy Logo
Sign Up Login Help
Home - Programmieren - Visual Basic - 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: 6291x
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]



Userdaten
User nicht eingeloggt

Gesamtranking
Werbung
Datenbankstand
Autoren:04505
Artikel:00815
Glossar:04116
News:13565
Userbeiträge:16552
Queueeinträge:06241
News Umfrage
Ihre Anforderungen an ein Online-Zeiterfassungs-Produkt?
Mobile Nutzung möglich (Ipone, Android)
Externe API Schnittstelle/Plugins dritter
Zeiterfassung meiner Mitarbeiter
Exportieren in CSV/XLS
Siehe Kommentar



[Results] | [Archiv] Votes: 1140
Comments: 0