Man sieht in der Software-Entwicklung immer wieder, dass die Leute eine technische Lösung einführen wollen und dann ihr Problem darauf anpassen (technology driven development). Wer kann es den Ingenieuren verdenken? Technologien machen Spaß, halten kreativ, schaffen Arbeit. Je komplexer desto mehr. So kommen Firmen dann zu Softwaresystemen, die am tatsächlichen Bedarf um ihrer selbst willen geschmeidig vorbei­laufen. Weil ja das Problem erst noch an die Lösung angepasst werden muss, dieser Schritt dann aber nicht mehr gegangen wird, falls er denn überhaupt möglich ist.

Warum erzähle ich das? Nun, ich habe das in meiner Freizeit natürlich auch so gemacht. Ich wollte mal wieder etwas mit Computergrafik, irgendwas mit Shadern entwickeln, also habe ich mir die Probleme SameGame, Ballout und Snake geschaffen.

Jetzt war es aber mal an der Zeit, dem Minimalismus zu huldigen. Nehmen wir an, wir haben die Spielidee und wählen davon ausgehend die Werkzeuge! In diesem Fall ist mein Problem ein Breakout-Klon und meine Lösung ohne prozedurale 3D-Geometrie, Beleuchtungsberechnung und Texturen. Einfach nur Rechtecke, Kreise und etwas Vektormathematik. Entwicklergolf sozusagen - wer die wenigsten Züge braucht, gewinnt.

Wenn man das so angeht, kommt schnell heraus, dass man die ganze Grafikkarten-Magie überhaupt nicht benötigt. Das ist auch irgendwie klar, es ging schon 1976 ohne. Man schreibt 2022 natürlich auch nicht mehr Assembler, aber man kann mal versuchen, sich auf die Bordmittel, in diesem Fall von MS Windows, zu beschränken. Es ist zugegebenermaßen etwas Augenwischerei: MS Windows ist, wenn man so will, die fetteste Abhängigkeit, die man sich überhaupt in ein Projekt holen kann. Für Spiele ist das meiner Ansicht nach okay und die Grundannahme ist hierbei, dass die zehntausenden Entwickler bei Microsoft ihre milliardenfach ausgerollte Komplexität einigermaßen im Griff haben. Hier also der Code-Umfang von Breakout in Direct2D für MS Windows.

D:\Projects\Games [master]> cloc.exe .\Breakout\
      35 text files.
      35 unique files.
      30 files ignored.

github.com/AlDanial/cloc v 1.90  T=0.10 s (235.4 files/s, 20617.1 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
C++                              5            206             47            778
XML                              7              0              0            361
C/C++ Header                     8             65             23            204
Windows Resource File            1             51             63            163
JSON                             2              0              0             53
-------------------------------------------------------------------------------
SUM:                            23            322            133           1559
-------------------------------------------------------------------------------

Und schließlich die Downloads: Zip (32 Bit) | Zip (64 Bit). Wie immer gilt: einfach entpacken und ausprobieren, keine Installation, keine Systemveränderungen.

»Wann hast du eigentlich zuletzt einen Arkustangens benutzt?«
»Na letzte Woche!«

Ja okay, ich gebe es zu: davor auch einige Jahre nicht mehr. Kürzlich habe ich es gebraucht, um den Winkel zwischen einem Fixpunkt und dem Mauszeiger zu bestimmen. Konkreter den Winkel eines am Ende fixierten virtuellen Kanonenrohrs und seiner beweglichen Mündung (gemessen zum Horizont).

Der Leser ahnt es schon. Ein neues Spiel! Und ich nenne es Ballout. Es ist im wesentlichen ein Klon von Puzzle Bobble (manchmal auch Bust a Move), ich habe es nur nicht so getauft, um nicht in irgendwelche markenrechtlichen Schusslinien zu geraten. Es basiert wieder einmal auf der von mir selbst entwickelten SameGame-Engine und enthält damit auch eine annehmbare physikalische Simulation.

Nach SameGame und Snake ist das nun schon das dritte Spiel auf dieser Technologie-Basis. Damit hat sich die Wiederverwendung wohl gelohnt - und natüüürlich war es von Anfang an als Trilogie geplant. Komplexitätsmäßig siedelt sich Ballout knapp über Snake an. Die Logik ist eben nicht übermäßig extravagant wenn man die Physik und Grafik bereits einmal vorbereitet hat.

Und jetzt nicht lange fackeln! Alle Spiele der Trilogie unter MS Windows ausprobieren: Zip (32 Bit) | Zip (64 Bit)

Kürzlich habe ich irgendwo einen Artikel gesehen: "Game Engine unter 50 MByte Größe". Das war als Werbung gedacht und der herausragende Punkt war also offensichtlich wie schlank der Code ist. Ich habe mich gefragt, ob die das ernst meinen. Dann wurde mir klar, dass die Entwickler vermutlich den Begriff Engine falsch benutzen. Ich kann nur vermuten, dass in dem Paket auch Resourcen (Modelle, Texturen, Audio) und natürlich Dokumentation mit drin sind. Mich hätte aber schon interessiert, was die Größe nur der Algorithmen einer schlanken Game Engine ist.

Die Frage drängte sich umso mehr auf, weil ich ja vor Kurzem selbst wieder mit SameGame ein kleines Spiel geschrieben habe ‐ zugegeben ein sehr einfaches Spiel aber nichts desto trotz in modernem C++ mit GPU-Beschleunigung. Also nächster Schritt: den weitestgehend generischen Code in eine Bibliothek (SameGame Engine) ausgelagert und auf dieser Basis den Klassiker Snake nachgebaut. Am Ende sind alles nur Kugeln. Mittels cloc habe ich schließlich die Codezeilen der Bibliotheken und Anwendungen durchgezählt, ausgenommen Kommentare und Leerzeilen.

Etwa ein Drittel von SameGame war allgemeiner Grafik-Code (Geometrie, Instancing), dazu noch etwas Dateibehandlung (Konfiguration und Highscores). Nicht extrahiert habe ich Physik und sowieso nicht verschiebbar war die SameGame-Spiellogik. Neu hinzu kam ein signifikanter Anteil an Visual Studio Boilerplate, aber um den muss man sich glücklicherweise nicht übermäßig selbst sorgen. So ist im Resultat der ausgelagerte Grafik-Code in etwa genauso groß wie die Snake-Logik. Oder anders ausgedrückt: Snake nur halb so groß wie es ohne wiederverwendete "Engine" wäre.

Und hier noch die Downloads für MS Windows: Zip (32 Bit) | Zip (64 Bit)

Als Computergrafik-Gesamtübung habe ich SameGame noch einmal neu implementiert. Erst als ich fertig war, ist mir aufgefallen, dass das ziemlich genau 18 Jahre nach der ersten Version war. Das Programm ist jetzt also offiziell volljährig. Und tatsächlich habe ich den Original-Quelltext auch noch - oh man, wie sich die Zeiten ändern. Es folgt ein kurzer Vergleich zwischen damals (links im Bild) und heute (rechts im Bild).

SameGame32 schrieb ich 2002 im Borland C++-Builder. Visual Studio war noch ein teures Produkt für Profis (was habe ich mich gefreut, als Student an eine Vollversion zu kommen). Heute ist das umgekehrt: der C++-Builder wollte in die Oberschicht vordringen und hat dabei jegliches Klientel verloren. Visual Studio hat es als Community-Version in die Breite geschafft, der C++-Builder in die Bedeutungslosigkeit.

Die Fenstergröße war damals fixiert. Das klingt harmlos, war aber Symptom einer bedeutenden Einschränkung: das Spiel tat nur so, als wäre es 3D. Tatsächlich wurden Bitmaps mittels DirectX 7 an feste Koordinaten eines Rasters kopiert. Die Kugeln lagen als bmp-Datei in den Anwendungsresourcen und zwar alle 3 Farben aus jeweils 18 Winkeln (ingesamt 54 Standbilder). Eine volle Drehung bestand aus Abspielen der 18 Bilder. Aus den Mauskoordinaten ließ sich trivial bestimmen, welche Kugel gerade überfahren wird und damit die Animation abgespielt werden muss. Die Einzelbilder wurden mit POV-Ray vorberechnet. Ja, es gab bereits Raytracing, allerdings weit weg von Echtzeit.

Nun ist das komplett anders. Beleuchtungsberechnung in Hardware ist lange Standard. Dementsprechend werden keine Bitmaps mehr kopiert sondern triangulierte Kugeln im 3D-Raum gerendert. Mit der invertierten Projektion lässt sich bestimmen, welche Kugel selektiert ist und damit ist die Fenstergröße nun frei verstellbar. Ich habe mich an das Endresultat mit 3 Shadern herangetastet: Gitternetz-Shader, Textur-Shader und schließlich Phong-Beleuchtung, was sehr nahe am damaligen Effekt ist.

Meine Grafik-Hardware kratzt das überhaupt nicht. Sie liefert Bilder so schnell wie der Monitor sie darstellen kann. Die Animationen sind entsprechend weich. Was für ein Unterschied zu den 18 Einzelbildern. Der Refresh war seinerzeit übrigens an einen Timer gekoppelt, der auf 75 ms eingestellt war. Das ergibt 13 Frames pro Sekunde oder anderthalb Sekunden für eine komplette Kugeldrehung. Keine Ahnung, wie ich auf diese Zahl kam. Wahrscheinlich durch Ausprobieren bis es bei maximaler Resourcenschonung auf einem Röhrenmonitor ausreichend flüssig aussah.

Da schrieb ich noch vor fast zwei Jahren: Ich bin drauf und dran, von der Blogengine zu einer selbstgebauten Lösung zu wechseln. Ich habe es dann nicht gemacht, weil der Autor löblicherweise anfing, etwas Bloat (Angular!!!) zu entfernen. Hat er dann aber leider nicht weitergeführt, sondern geschrieben, dass er keine Lust mehr auf die Blogengine hat und stattdessen mit etwas Neuem rumspielt. Damit muss man natürlich rechnen - unangenehm ist es aber trotzdem.

Da hat es mich also wieder in den Fingern gejuckt. Doch was tun? Habe mich wieder im Microsoft-Umfeld umgeschaut, wie ich das am besten selber baue. Microsoft hat mich ziemlich früh in der Uni mit dem Studentenprogramm drangekriegt. Seit Visual Studio 2002 bin ich beim .NET Framework dabei, das müsste Version 1.1 gewesen sein. Doch mit dem .NET Framework ist es nun aus. 16 Jahre waren echt eine lange Zeit. MS ist ja verdammt, die Kompatibilität zu erhalten (Developers! Developers! Developers!).

Der neue hippe Kram ist .NET Core und damit ASP.NET Core, ein modularisiertes Framework, das immer noch C# versteht und schwer auf den Paket-Manager Nuget setzt. Habe ich also den Schritt gemacht und die Blogengine einfach mal komplett weggeworfen. Mehrere tausend Dateien. Ich habe nur die 39 Blog-Beiträge und darin referenzierte Resourcen behalten, ansonsten alles from scratch neu geschrieben (insgesamt ein Aufwand von drei Tagen, ich habe viel Bloat einfach weggelassen, wie Trackbacks, Pingbacks, Kommentare, Bewertungen). Das Ergebnis läuft hier gerade.

Dann habe ich auch gleich noch Geogen v4 auf .NET Core portiert. Das soll ja angeblich auch schneller laufen. Eigentlich ging es mir aber um die Zukunftssicherheit - ich will nicht auf dem Trockenen sitzen, wenn Windows Server irgendwann kein .NET Framework mehr mitbringt. Manchmal ist das auch schade, wie Microsoft so durch die Technologien huscht. Als sie den SQL Server Compact mit ASP.NET Unterstützung eingeführt haben, war ich wirklich glücklich, eine In-Process Alternative zum SQL Server zu haben. Leider haben sie die Unterstützung inzwischen komplett eingestellt. Argh! Hätte ich nur gleich auf Sqlite gesetzt.

Achtung sehr technisch. Ich schreibe diesen Eintrag hauptsächlich aus Eigennutz, denn ich muss irgendwie festhalten, wie man die Cairo-Bibliothek compiliert. Ich habe dafür unübertriebene drei Stunden gebraucht und das will ich beim nächsten mal unbedingt verhindern. Cairo ist eine quelloffene 2D-Vektorgrafik-Bibliothek für Entwickler. Im wesentlichen kann man damit Linien, Dreiecke, Vierecke und Mehrecke (also Kreise, Texte und beliebeige Polygone) zeichnen. Und das ganze wahnsinnig performant und gleichzeitig plattformunabhängig. D.h. für Windows: keine GDI Odyssee und auch keine GDI+ DLL-Hölle.

Die derzeit aktuelle Version ist Cairo 1.10 vom 25. September 2010. Das Ziel ist ein Kompilat in eine einzige DLL (die man einfach zusammen mit der Anwendungs-Exe weitergibt) unter Visual Studio 2010. Nun wäre die Geschichte kein Krampf, wenn es sich bei Cairo nicht vorrangig um ein Linux-Projekt handeln würde. Die Windows- Unterstützung ist also allenfalls rudimentär.

1. Doch fangen wir von vorne an: Benötigt wird natürlich erstmal der Cairo-Quelltext. Ebenfalls herunterzuladen ist das aktuelle Pixman-Paket. Darin sind die absoluten Low-Level Routinen für Cairo zu finden. Weiterhin bestehen Abhängigkeiten zur zlib (aktuell v1.2.5) und zur libpng (aktuell v1.4.4). Während sich letztere beiden mit einer Visual Studio-Solution bauen lassen, sind bei Pixman und Cairo nur Makefiles mitgeliefert. Die sind allerdings zu kompliziert für Microsofts NMake, so dass man sich am besten MSYS mit einem richtigen Make installiert. Tja. Nur dass die MSYS-Leute ihr System in einzelne Archive verpackt deployen. Anstelle sich 500 Einzel-Archive herunterzuladen und zu entpacken, empfehle ich das MozillaBuild-Paket. Da kriegt man zwar noch einiges mehr, aber wenigstens läuft das ganze dann und scheitert nicht an einer fehlenden DLL.

2. ZLib bauen ist recht einfach über die Solution im Contrib-Ordner. Wir wählen die statische Variante (zlibstat) in der Releasekonfiguration. In den Projekteigenschaften sicherstellen, dass die Codegenerierung auf Multithreaded (MT, wir wollen keine Abhängigkeiten in die Microsoft CRT!) eingestellt ist und los gehts. Die libpng liefert eine VS2010-Solution mit, die ist aber doof konfigiert. Also die 7.1er wählen und upgraden. Release-Konfiguration wählen, das Verzeichnis der aktuellen zlib als zusaätzliches Includeverzeichnis angeben, Codegenerierung auf MT umstellen und in den Präprozessor-Direktiven des Compilers "ZLIB_WINAPI" hinzufügen, denn wir wollen die zlib später nicht als externe DLL sondern direkt in Cairo.

3. Pixman bauen. Hier kommt das erste Mal unser neu erworbenes Make aus dem MSYS-Package zum Einsatz. Zumindest wenn das Makefile.win32 schon perfekt wäre. Ein Änderung ist noch nötig, da wir die MS-CRT ja nicht als Abhängigkeit haben wollen: in Zeile 21 zu den CFLAGS ist wiederum der Schalter -MT einzufügen. Dann gehts auch los: start-msvc10.bat von MozillaBuild starten, in der erscheinenden bash zum pixman navigieren und "make -f Makefile.win32 CFG=release" führt zum Glück.

4. Cairo fit machen. In der bash zu Cairo/src navigieren und "make -f Makefile.win32 CFG=release" eingeben. Was nun kommt sind Fehlermeldungen. Tjo. Das Makefile für Windows ist ein nicht gepflegter ungetesteter Trümmerhaufen. Zunächst einmal fehlt die Datei cairo-features.h. Diese sollte in einem Make-Lauf erstellt werden. Die passende Regel wird aber offenbar nie angestoßen. Etwas Suche in den Sourcen offenbart wie sie aussehen sollte (am besten einfach kopieren und einfügen):

#ifndef CAIRO_FEATURES_H
#define CAIRO_FEATURES_H 1

#define CAIRO_HAS_WIN32_SURFACE 1
#define CAIRO_HAS_WIN32_FONT 1
#define CAIRO_HAS_PNG_FUNCTIONS 1
#define CAIRO_HAS_PS_SURFACE 1
#define CAIRO_HAS_PDF_SURFACE 1
#define CAIRO_HAS_SVG_SURFACE 1
#define CAIRO_HAS_IMAGE_SURFACE 1
#define CAIRO_HAS_RECORDING_SURFACE 1
#define CAIRO_HAS_USER_FONT 1
#define CAIRO_HAS_INTERPRETER 1

#endif

5. Reparatur und Anpassung der Makefiles. Src/Makefile.sources ist nicht nur für NMake zu kompliziert sondern auch für MSYS zu proprietär: Im Notepad öffnen und suchen und ersetzen nach if mit ifdef. build/Makefile.win32.common öffnen und in Zeile 20 die MS_MDFLAGS von -MD nach -MT umstellen (beim Debug analog auf -MTd aber ich erstelle hier nur das Release). Im folgenden sind zwischen Zeile 25 und 37 einige Pfade hart codiert. Diese sind an die tatsächlichen Gegebenheiten anzupassen. Insbesondere haben sämtliche Abhängigkeiten bei mir eine Versionsnummer im Pfadnamen. In Zeile 40 zu den DEFAULT_CFLAGS noch die Option -DZLIB_WINAPI anhängen, weil die zlib ja statisch in die DLL soll.

6. Patchen der Sourcen für den VC++-Compiler, da dieser keine Implementierung von lround in math.h kennt. In cairoint.h die Zeile 955 so erweitern, dass dort #if DISABLE_SOME_FLOATING_POINT || defined(_MSC_VER) steht. In cairo-misc.c in Zeile 486 dieselbe Erweiterung vornehmen.

make -f Makefile.win32 dynamic CFG=release

7. Et voila. Eine cairo.dll von knapp 1 MByte ohne extravangante Abhängigkeiten aber mit der Fähigkeit PNGs und PDFs zu erzeugen. Hoffentlich wird das mit der nächsten Version etwas einfacher.