Nachdem ich jetzt Punkte, Linien und Kreise zeichnen kann, gehts an die Strukturen der 3D-Grafik. Klar, neben Punkten, Linien und Kreisen ist hier das Polygon das wichtigste Element. Jedes moderne Computerspiel basiert auf Polygonen.
Es ist (mal ganz nebenbei gesagt) erstaunlich, wie viel moderne Computer leisten können. Während man am Anfang der 3D-Grafik grade mal zehn bis hundert Polygone gleichzeitig und in echtzeit darstellen konnte, ist es heutzutage möglich mehrere Millionen Polygone darzustellen und überdies noch komplex auszuleuchten. Echtzeitschatten, Bumpmapping (bzw. Normalmapping) und realistische Physikinteraktionen natürlich eingeschlossen.

O.K., ich schweife ein wenig ab.
Polygone zu organisieren ist weitaus komplizierter, als man denkt. Gucken wir uns zunächst mal an, was Polygone sind, und was es für Polygone gibt:

Polygonarten

So weit, so gut…
Und jetzt gucken wir noch, woraus so ein Polygon besteht:

Bestandteile eines Polygons

Nachdem wir jetzt wissen, was ein Polygon ist, und woraus es besteht, können wir uns Gedanken darüber machen, in welche Datenstruktur wir Polygone quetschen und wie wir damit umgehen.
Aber das ist Schnee von morgen.

Also bleibt am Ball! Demnächst zeig ich dann, wie man Polygone am besten speichert.

MfG, der Dac, der bekennend Polygonie betreibt…

(Am besten wieder auf Youtube gehen und das Video in hoher Qualität angucken)

Den Quellcode poste ich ab jetzt immer bei http://pastebin.ca
Den aktuellen gibt’s also jetzt hier.

So weit, so gut. Jetzt gehts aber ganz sicher an Polygone. Versprochen.
Auch wenn ich in nächster Zeit aufgrund der Prüfungen, die noch ausstehen ein wenig weniger posten werden. Aber dann geht’s wieder rund. Versprochen.

MfG, der Dac, der den Youtubeupload doof findet…

Zum Programm gibts auch noch die glut32.dll. Da gibt es leider keine Möglichkeit den Code mitzukompilieren. Ist ein wenig blöd, aber nicht zu ändern.

Hier gibts die Downloads als .rar-Archiv:

Programmcode (Headerdatei & Coderumpf)
Beispielprogramm (linke oder rechte Maustaste in das OGL-Fenster machen)

Kleines Problem am Rande: Wenn man eine Weile im OpenGL-Fenster nichts macht, reagiert es nicht mehr. Wer weiß, woran das liegt, dem wäre ich dankbar, wenn er einen Kommentar mit Lösung hinterlassen könnte.

Sorry, dass ich an dieser Stelle nicht mehr schreibe, aber demnächst gibt’s mehr zu Vertices und Polygonen.

MfG, der Dac, der jetzt den Rechner neu macht…

Morgen gibt es dann den passenden Quelltext dazu und ein kleines Programm zum Download, das – und jetzt kommts – Linien zeichnen kann.

Vielleicht noch ein kleiner Hinweis an alle, die auch ganz am Anfang der Spieleprogrammierung stehen:

Das, was ich hier mache braucht man nicht wirklich, um Spiele zu programmieren. Das ist tiefes Hintergrundwissen. Heutzutage braucht niemand mehr einen Algorithmus zu schreiben, der eine Linie zeichnet. Das erledigt die Hardware (bzw. OpenGL oder DirectX) von sich aus. Ich mache das nur, damit ich auch verstehe, was genau da gemacht wird. Wer einfach nur ein Spiel programmieren möchte, sollte vielleicht nicht gerade damit anfangen seinen eigenen Linienalgorithmus zu schreiben.

O.K. Wie gehts denn dann hier weiter? Linien habe ich ja jetzt. Dann ist der nächste Schritt ein Kreis zu zeichnen, dann Polygone, dann gefüllte Polygone (eventuell mit Texturen) und dann endlich das große Thema 3D…

MfG, der Dac, der das mit diesem dämlichen entfesselten Blitz nicht hinkriegt…

Nachdem ich nun Punkte in allen nur denklichen 16-Bit Farben an jeder x/y-beliebigen Stelle zeichnen kann, wird es Zeit, diese Punkte zu Linien aufzureihen.
Hierfür nehme ich den gebräuchlichsten Algorithmus, der ohne Fließkommaberechnungen und Multiplikationen auskommt. Der Bresenham’sche Linienalgorithmus ist deswegen auch super schnell und vermeidet Rundungsfehler.

Wie der Algorithmus funktioniert fasse ich in zwei, drei kleinen Videos zusammen. Im ersten Teil erkläre ich die Gundlegende Funktionsweise anhand langsam steigender Linien.  Im zweiten teil folgt dann die Verallgemeinerung der Funktionsweise für alle Linientypen (dazu mehr im Video). Im dritten Teil (sofern ich den noch mache) erkläre ich dann, wie man Kreise mit Bresenham zeichnet.

Hier aber zunächst der erste Teil:

Wer ein wenig mehr erkennen möchte, kann sich das Video auf Youtube auch als High-Quality-Video angucken.

MfG, der Dac, der seine eigene Stimme nicht mag…

Deswegen habe ich mir heute OpenGL und das Microsoft Platform SDK installiert, Visual C++ konfiguriert und losgelegt.

Mein Plan ist es, nur mithilfe der Pixel-zeichnen-Funktion vom eigenen Linienalgorithmus bis hin zu 3-dimensionalen Polygonen erst mal alles selber zu schreiben. Ich hoffe mal, das klappt so, wie ich es mir vorstelle.

Für heute begnüge ich mich mit einzelnen, zufällig positionierten Pixeln auf einer orthogonalen Ebene (wie gesagt, ich fange 2-dimensional an). Ich habe mir den ganzen Code ein wenig zusammengereimt und hoffe mal, dass der so akzeptabel ist. Hier also das Ergebniss meiner heutigen Arbeit:

Und hier das Stück Code, das Schuld daran ist:

MfG, der Dac, der gerade Sterne sieht…

kleiner Nachtrag:

Super, es ist ganz einfach möglich, in der „drawScene()“-Funktion den zeichnenden Code in eine weitere Funktion auszulagern. So ist es kein Problem sich eine extra Funktion für Linien, Kreise, Polygone und andere geometrische Körper zu schreiben.

Jetzt aber zu der Spielerklasse.
Da die Spielfeldklasse für die Ausgabe sorgt, muss ich diese Klasse um ein Spielerarray und einige Funktionen erweitern. Die Spielerklasse an sich stellt einerseits die Superklasse für menschliche Spieler dar und andererseits für computergesteuerte Spieler.

MfG, der Dac, der hoffentlich bald wieder aus der Flaute rauskommt…

Aber genug von der Zukunft geträumt. Zurück zum aktuellen Projekt:

Statt eines Arrays mit den einzelnen Wandobjekten habe ich nun ein Vektor benutzt, was im übrigen super funktioniert. Und weil ich natürlich nicht alles für mich behalten möchte gibts hier endlich den (unter Visual C++) funktionierenden Quelltext zum runterladen, anschauen und selber basteln:

Hier gehts zum Quelltext…

Wer sich den Quelltext genauer anschaut, wird vielleicht merken, dass ich mehrere Wandobjekte mit gleichem Namen erstelle. Das hat den Vorteil, dass ich mit einem einzigen Löschen-Befehl alle Wandobjekte mit diesem Namen wieder löschen kann. Dieses „Feature“ war zunächst ungewollt, hat mir dann aber ganz gut gefallen.

Wie gehts jetzt weiter?

Nachdem das Spielfeld so schon gut funktioniert werde ich mich an eine Spielerklasse machen. Das heißt Ausgabe, Steuerung per Pfeiltasten und Kollisionserkennung. Im Prinzip nicht wirklich schwierig, aber trotzdem mache ich das erst morgen. Wenn ich damit fertig bin kommt der Computergegner, der von mir eine kleine KI spendiert bekommt.

MfG, der Dac, der jetzt DVDs kaufen geht…

Um nicht völlig still zu stehen gibts heute ein kleine Einführung (aber wirklich nur ganz oberflächlich und kurz) in die „STL“ und das Thema „generische Datentypen“.

Was ist die STL?

Die STL ist eine Bibliothek von Klassen, die neue Datentypen(Container) und Algorithmen bereitstellt. Ein Vorteil der Algorithmen ist, dass diese nicht nur auf die von der STL mitgebrachten Datencontainer anwendbar sind, sondern auch mit herkömmlichen Arrays funktionieren.

Einige Nützliche Operationen sind zum Beispiel:

• find(): Suchen eines Wertes innerhalb eines Arrays (oder anderen Containers)
• sort(): Sortiert die Werte eins Datencontainers
• copy(): Kopieren eines Bereiches in einem Datencontainer in ein anderes Array
• reverse(): Vertauscht die Werte eines Datencontainers in umgekehrte Reihenfolge
• fill(): Füllt ein Datencontainer mit einem bestimmten Wert
• equal(): Vergleicht zwei Bereiche eines (oder mehrerer Datencontainer) miteinander
• [...]

Wenn ich hier „Datencontainer“ geschrieben habe meinte ich „Array oder STL-Datentyp“.
Die STL stellt weiterhin auch eine for-each-Schleife und eine Iteratorklasse bereit. Das würde jetzt aber zu sehr ins Detail gehen.

Neben den äußerst nützlichen Algorithmen gibt es auch einige gut zu gebrauchenden Datentypen, die nicht nur nützlich, sondern auch generisch und damit sehr vielseitig einsetzbar sind.

Containerklassen der STL:

• vector<Typ>: Der wohl einfachste Datentyp der STL ist ein dynamisches Äquivalent zum normalen Array. Das Vektorobjekt lässt sich nicht nur als Liste aus Daten benutzen, sondern mit Hilfe einiger gegebener Methoden auch als Stack.
• deque<Typ>: Um diesen Datentyp zu verstehen hilft vielleicht aufzuklären, dass es sich bei der Bezeichnung um eine Abküzung für „double ended queue“ handelt. Und im Endeffekt ist es nichts anderes, als ein Vektor mit der zusätzlichen Funktion, dass man auch Elemente am Anfang der Datenschlange einfügen kann. Deswegen „Vektor mit zwei Enden“.
• list<Typ>: Hier gehts ans Eingemachte. Bei diesem Datentyp handelt es sich um eine doppelt verkettete Liste. Eine Liste ist dann sinnvoll, wenn man oft Daten einfügt oder löscht, aber nicht so oft drauf zugreifen muss. Ein Zugriff per Index wie bei einem Array oder Vektor ist hier leider nicht möglich, da alle Daten durchlaufen werden müssen, um an eine bestimmte Position zu gelangen.
• [multi]set<Typ>: Ein „set“ ist ein Container, in dem alle Werte assoziativ zu einem Schlüssel abgespeichert werden. Wenn es sich nicht um ein „multiset“ handelt, darf jedes Element nur einmal auftreten. Ein weiterer Vorteil ist, dass die Elemente sortiert eingefügt werden.
• [multi]map<Typ>: Die „map“ funktioniert ähnlich wie ein „set“, nur dass man den Schlüssel (und Schlüsseltyp) selber angeben kann. So kann man wie bei einem Array auf Elemente zugreifen, nur dass in den Eckigen Klammern ein beliebiger (auch String) Wert als Index stehen kann.

Das ist natürlich nicht alles, was die STL zu bieten hat, aber genug um zu veranschaulichen, wie mächtig die Bibliothek ist.

Um tiefer in die Materie einzusteigen oder sich die STL runterzuladen lohnt sich ein Blick auf die Homepage: http://www.sgi.com/tech/stl/

Ist ja ganz toll, aber was soll denn das ganze Gequatsche von wegen „generisch“ und was sollen diese „<Typ>“-Dinger sein?

Generische Datentypen

Stellen wir uns mal folgendes vor: Sie programmieren sich eine Klasse, um Integer-Werte in eine Datei zu speichern. Das geht eine Zeit gut, bis plötzlichen nicht nur Zahlen, sondern auch ganze Wörter und Texte gespeichert werden müssen. Jetzt könnte man natürlich exakt die selbe Klasse nur mit dem Datentyp String (bzw. *char) schreiben, die man dann halt benutzt. Aber das wiederspricht irgendwie dem Prinzip so wenig wie möglich doppelten Code zu haben.

Die Lösung: generische Datentypen.
Das heißt, dass man die Klasse schreibt ohne sich auf einen bestimmten Datentyp festzulegen. Das erhöht die Wiederverwedbarkeit von Klassen enorm.

Wie genau das funktioniert kann man in diversen Onlinetutorials oder in so gut wie jedem guten C++ Buch lesen. Das hier zu erklären würde diesen ohnehin schon sehr ermüdenen Artikel wohl unerträglich machen.

Deswegen gibt es noch ein kleinen Codeauszug von mir, der ansatzweise zeigt, was dieser Artikel erklärt:

Die STL im Einsatz

MfG, der Dac, der ganz bestimmt bald wieder was macht.

was damals, als ich noch unsauber und ohne Rücksicht auf Verluste drauflosprogrammiert habe so einfach war gestaltet sich heute ein wenig schwieriger.

Es ist zum Beispiel ein immenser Aufwand die Anzahl der Elemente eines dynamisch erzeugten Arrays das auf Objektinstanzen referenziert, welche wiederrum primitive Datentypen und Zeiger enthalten zu zählen.

In Java gibt es dafür die schöne Instanzvariable „array.length“. In C++ gibt es eine etwas kompliziertere Methode, um die Anzahl eines Arrays mit primitiven Datentypen zu bekommen:

int anzahlElemente = sizeof(array) / sizeof(array[0]);

Aber dämlicherweise funktioniert das nicht mit meinem Objektarray (warum auch immer…). Es gäbe noch die Möglichkeit das Array Element für Element durchzugehen, bis das Arrayende erreicht wurde, aber das ist mir
a) zu aufwändig und
b) zu langsam.

Also werde ich mich mit der STL (Standard Template Library) auseinandersetzen. Und zwar im speziellen mit Vektorobjekten, die eine Methode „vektor.size()“ mit sich bringen. Das funktioniert dann hoffentlich. Außerdem sind Vektoren schon von sich aus dynamisch.

Leider gibt es heute deswegen auch nichts neues zum Programm (außer der obigen Erkentniss).

Zum Schluss noch ein schönes Zitat:

Für das große Chaos haben wir Computer. Die übrigen Fehler machen wir von Hand.

(Quelle: unbekannt)

MfG, der Dac, der ganz bestimmt nicht verzweifeln wird…