Ich habe kürzlich, also vor zwei Jahren, mal wieder das Spiel des Lebens implementiert. Viel zu spielen gibt es dabei allerdings nicht. Es macht mehr Spaß es zu bauen, als dann ewig zuzugucken (auch wenn sich im Verlauf Muster ergeben, die einem wie Gleiter erscheinen können). Vielleicht wäre es interessanter, wenn sich die "Lebewesen" bewegen würden. Gesagt, getan!

Wenn sich kleine Dinge bewegen und dabei einen Lebenszyklus durchlaufen, haben wir es technisch mit einem Partikelsystem zu tun. Das schreit nach Hardware­beschleunigung, sowohl in der Simulation/Physik als auch in der Grafik/Rendering. Also alles, was ich schonmal gemacht habe. Der Anspruch kommt davon, sich neue Regeln auszudenken und zu sehen, was passiert. Haben kleine Änderungen große Auswirkungen? Ist das System stabil? Ab wann? Für wie lange?

Hier die Regeln, die ich mir für den Anfang überlegt habe:

• Simuliert werden Kugeln verschiedener Farbe mit Bewegungsimpulsen, die übertragen aber nicht verloren gehen können (keine Reibung).
• Berühren sich zwei verschiedenfarbige Kugeln, entsteht eine neue Kugel (Geburt) mit zufälliger Farbe eines "Elternteils". Berühren sich zwei gleichfarbige Kugeln, geschieht nichts.
• Nach einer Kollision gibt es eine Abklingzeit während der weitere Kollisionen keine Nachfahren erzeugen (Kugeln werden heller dargestellt).
• Kollidiert eine Kugel in kurzer Zeit zu häufig (Überbevölkerung, Impuls­sammler), wird sie vom Spielfeld entfernt (Tod).

Das erzeugte bei mir immer stabile Systeme. Ich habe nicht genügend Versuche gemacht, um eine Population aussterben zu sehen. Es gab auch immer einen quasi-stabilen Endzustand ab dem sich bevölkerungsmäßig nichts mehr getan hat. Offensichtlich kann ein begrenzter Raum nur begrenzt viel Energie aufnehmen, McFly. Ab dann regelt sich alles selbst.

Das Hantieren mit den Regeln ist hier das eigentliche Spiel. Man könnte es in Lua-Scripting verpacken und damit Leuten das Programmieren schmackhaft machen. Die schwere Technik und Simulation bliebe im C++-Kern. Hier bin ich mir aber nicht sicher, wieviel Macht man letztlich ins Scripting übergeben müsste. Wenn das Marshalling zu umfangreich wird, frisst es einerseits Performance und andererseits auch Einfachheit und Zugänglichkeit. Deswegen lasse ich das mal weg und hier gibt es nur etwas zu schauen: lifesim-win64.zip [1,3 MByte Download].

Da sind die zwanziger Jahre nun schon zur Hälfte rum. Nebenbei auch das erste Viertel des Jahrhunderts, aber das wäre zu viel zurückzublicken. Beschränken wir uns auf das halbe Jahrzehnt, das objektiv global betrachtet eher nur so mittel war. Also lassen wir den Weltschmerz um Klimakatastrophen, Kriege und Viren außen vor und beschränken den Betrachtungsradius auf den Bereich, auf den man konkreten Einfluss hat. Bei mir waren das exemplarisch drei tolle Hobbies.

1. FinTech

Hierüber schreibe ich ja jedes Jahr (2020, 2021, 2022, 2023). Ich habe da einfach riesige Freude dran, Daten zu sammeln und aufzubereiten. Zunächst habe ich Börsenkurse und Depotwert regelmäßig von meinem Raspberry Pi sichern lassen, Anfang 2023 bin ich aber auf einen kleinen Server bei Ionos umgezogen. Da wird die Hardware einfach besser überwacht und die Anbindung ans Internet (hier: das API von Alpha Vantage) mag robuster sein. Jedenfalls sammelte ich so einen feinen Berg an Transaktions- und Kursdaten.

Und ich wäre kein Informatiker, wenn ich da keinen ebenso feinen Berg von Software drumrum gebaut hätte. Das fängt bei einem Online-Dashboard an (D3.js), geht über analytische Verarbeitung mit DuckDB und endet bei ge-cron-jobbten Gnuplot-Grafiken in verschiedenen Stilen. Wie hier zum Beispiel:

So habe ich das Gefühl, alles im Blick und dabei eine gehörige Portion Ingenieur-Spaß zu haben. Ich betreibe allerdings keine technischen Kursanalysen. Niemals. Also ich versuche nicht, irgendwelche Muster zu erkennen, um kurzfristige Entscheidungen abzuleiten. Früher habe ich noch bei Markt­korrekturen gehandelt, jetzt habe ich diese Form der Mikro­optimierung auch aufgegeben, wie man an der Treppenstufen-Investitionskurve sieht. Mit einer Ausnahme: Nvidia ist dieses Jahr wieder so stark gestiegen, dass ich da mal meine Anfangsinvestition rausgenommen und etwas später in ETFs geschoben habe. Grüße ans Finanzamt: für den Sack Steuern hätte ich gerne einen Obstkorb!

2. Computergrafik

Neben der nerdigen Darstellung von Zeitreihen und Statistiken, habe ich meine alte Liebe zu High-Performance Computergrafik reanimiert. Ich habe zum Beispiel SameGame gleich drei Mal implementiert. Okay, die Spiellogik und -physik nur einmal, aber den Renderer habe ich mehrfach ausgetauscht. Einfach nur so aus Spaß. Da war zunächst OpenGL (einfach), dann Vulkan (schwierig) und schließlich nochmal raytraced (autsch!). Hier eine Montage, die ich mit ImageMagick zusammengeskriptet habe:

Die subtilen visuellen Unterschiede liegen nicht allein am Renderer. Ich hätte mit Vulkan auch die OpenGL-Ausgabe reproduzieren können, ohne dass man irgendetwas bemerkt, aber ich habe das Aussehen über das halbe Jahrzehnt nachjustiert. Bei OpenGL wollte ich nah an meiner allerersten SameGame-Version von 2002 sein und habe eine schmutzige Wolkentextur für die Kugeln benutzt. Im Vulkan-Renderer habe ich diesen Zopf abgeschnitten, das Ganze ambient heller gemacht und eine filigrane Marmortextur eingesetzt. Im Raytracing habe ich es nochmal glänzender und spiegelnder eingestellt. Ich glaube Raytracing-Grafiken sind immer glänzender und spiegelnder ;)

3. Balance

Anfang des Jahrzehnts habe ich einmal die Woche nicht vom Büro aus gearbeitet. Mitte des Jahrzehnts arbeite ich einmal die Woche vom Büro aus. Hätte mir das jemand vorher gesagt, ich hätte ihm 'nen Vogel gezeigt. Aber viel besser hätte es nicht kommen können. Als Informatiker brauche ich keinen Smalltalk übers Wetter, sondern Fokus und Landschaft, wie ich festgestellt habe. Häh, Landschaft? Ja, ich jogge quasi meditativ durch Brandenburg. Wobei meditativ eigentlich gelogen ist, denn da versucht man gerade nicht zu denken. Ich entwerfe beim Joggen allerdings Strategien und löse Probleme — und aus meiner Sicht anders (mindestens genauso gut), wie von Bildschirmen aus. Das hätte ich Anfang des Jahrzehnts auch nicht gedacht.

Dies hat dazu geführt, dass ich so entspannt wie noch nie durchs Leben gehe (naja, das und die Grundlage von Hobby 1). Ich versuche, nur noch Dinge zu tun, die mir Spaß machen, was wiederum bedeutet, dass ich manches nicht mehr mache. Erstaunlicherweise haben sich dadurch aber keine Nach- sondern aus meiner Sicht nur Vorteile ergeben. Für den Rest des Jahrzehnts gibt es daher in Sachen Lebenseinstellung ein klares »Weiter so« von mir.

Bonus: Drei Literaturempfehlungen aus dem halben Jahrzehnt

• [Belletristik] Hugh Howey: Silo (Teil 2: Level, Teil 3: Exit)
• [Ratgeber] André Kostolany: Die Kunst, über Geld nachzudenken
• [Fachbuch] Björn Andrist: C++ High Performance (Tipp: Kapitel zu Coroutinen überspringen und auf C++26 warten)

Die heißeste Schnittstelle für High-Performance Computergrafik neben DirectX 12 ist bekanntlich Vulkan und obendrauf einigermaßen aktuell ist Vulkan Raytracing. Ich schreibe einigermaßen, weil ich zugegeben etwas spät zu der Party bin. Zunächst sehr intensiv von Nvidia beworben, sind die mit ihrer Hardware inzwischen zu statistischen Sprachmodellen ("KI") weitergezogen. Nichtsdestotrotz fand ich Raytracing schon immer spannend. Das begann in den Neunzigern mit POV-Ray als die Generierung einer einzigen Grafik noch mehrere Sekunden bis Minuten brauchte. Jetzt soll es mit 60 FPS gehen? Muss ich sehen!

Zunächst einmal ist Vulkan keine einfache Schnittstelle. Ich würde sie grob dreimal so komplex wie OpenGL einschätzen und Raytracing dann nochmal doppelt so aufwändig. Der Umfang an Infrastruktur-Code ist enorm. Ich habe die ersten zwei Drittel des Experiments praktisch blind gearbeitet, was überhaupt nicht meinem iterativen Ansatz entspricht. Ich ändere Code und führe das Programm aus, um den Effekt zu sehen. Bei Vulkan-Infrastruktur gibt es da aber lange nichts zu sehen außer bestenfalls die Abwesenheit von Fehlermeldungen (das Validation Layer ist Gold wert, da hängt man Parameter- und Zustandsvalidierung vor den Grafiktreiber). Ebenfalls unpraktisch: für Vulkan Raytracing ist mir keine Software-Emulation bekannt. Ich musste komplett am Gaming-PC mit tauglicher Hardware entwickeln — Laptop auf der Couch oder am See ging nicht.

Aber was soll ich sagen? Hardware-beschleunigtes Raytracing ist schon krass. Bei herkömmlicher Rasterisierung schickt man Objekt für Objekt (Untergrund, Haus, Baum) aus Dreiecken an die Grafikkarte und wenn es weit genug vorn liegt (Tiefentest), wird das Pixel entsprechend gefärbt. Beim Raytracing lädt man dagegen die gesamte Szene in den Grafikspeicher und schießt darauf so viele Strahlen wie man Pixel hat, also beispielsweise 800x600. Die Grafikkarte sagt dann einem Shader-Programm, das man vorher hochgeladen hat, welches Objekt getroffen wurde ("Glasfenster"). Hier wird es noch spannender. Man kann dann antworten: "Oh, Glasfenster. Kannst du mal verfolgen, welches Objekt der reflektierte Strahl trifft?" und die GPU kommt dann zurück mit "Baum". So kann man Spiegelungen nach einem physikalischen Modell statt mit mehreren Render-Durchläufen erzeugen.

Für SameGame RTX [676 kByte Zip-Download] habe ich mich da mal durch­gekämpft, allerdings mit nur einer Rekursionsstufe und sehr schwacher Reflexion. Wenn man ganz genau hinguckt, sieht man Spiegelungen benachbarter Kugeln. Es war wirklich heftiger Aufwand für so wenig Effekt, aber es ging ja ums Ausprobieren. Ich glaube, dass solche Projekte die Grenzen des persönlich Machbaren verschieben. Selbst wenn man nicht permanent auf der höchsten Schwierigkeitsstufe operiert, kann man auf niedrigeren davon profitieren, es mal getan zu haben. Ich bemerkte das beim Ray-picking. Da schießt man genau einen Strahl in die Szene (nämlich von der Maus-Position) und rechnet auf der CPU aus, welches Objekt getroffen (angeklickt) wird. Das benutzt man seit Jahrzehnten zum Beispiel in Echtzeit-Strategie­spielen, aber erst seit ich Raytracing durchgezogen habe, ist mir die Mathematik dahinter in Gänze klar. Eine sinnvolle Lektion für jede Art interaktiver 3D-Grafik.

Was mich zur abschließenden Bewertung bringt.

• Für konservative Projekte mit durchschnittlichen Teams würde ich weiterhin OpenGL wählen. Das ist eine abgehangene, dokumentierte und überschaubare Technologie. Gutes Gelingen ist wahrscheinlich.
• Wenn man etwas mehr Performance und Zukunftssicherheit für viel mehr Aufwand haben will und das Team zu den oberen 20% der Entwickler gehört, würde ich mich an Vulkan wagen. Das Projektrisiko ist signifikant, die Belohnung dann aber auch.
• Um Raytracing würde ich einen Bogen machen, außer die Anforderungen leiten extrem deutlich in Richtung physikbasiertes Rendering. Selbst dann würde ich nochmal prüfen, wie es um die Unterstützung auf Grafikkarten steht. Ich wäre nicht überrascht, wenn Nvidia Raytracing für Gamer fallen lässt, weil Hardware für Rechenzentren profitabler ist. In jedem Fall würde ich ein Raytracing-Projekt nur mit den besten 5% der Entwickler anfassen.

Ich lese ja regelmäßig die Wirtschaftswoche (WiWo). Die Meinungsartikel triefen oft neoliberal und sind entsprechend schwer zu ertragen. Der Journalismus hat aber hin und wieder einen Lichblick - womöglich Brotkrumen, die beim paywall-vernagelten Handelsblatt runterfallen. Jedenfalls lese ich dort dieses Jahr das hier:

Ui, ui, ui. Harte Worte: Moral, schmutzig, aber, aber, Schande. Naja, denke ich mir, Wirtschaftswoche eben. Aber Moment mal! Die vier Namen darin, die kommen mir doch irgendwie bekannt vor: Unilever, Procter & Gamble, PepsiCo und Nestlé. Woher nur? Aber ja! Das sind Konsumgüter Value-Aktien. Wenn man irgendetwas Robustes in seinem Depot haben wollte, das sich auch in Krisenzeiten stabil hält, dann würden die vermutlich in die engere Wahl kommen. Einen Sicherheitsanker habe ich ja selber. Also ganz genau gesagt, über die letzten 10 Jahre, vier Sicherheitsanker, nämlich: Unilever, Procter & Gamble, PepsiCo und Nestlé.

Tja. Zufälle gibts! Zu meiner Verteidigung kann ich sagen, dass sie dieses Jahr nicht über-performed haben. Ich habe also nicht übermäßig von Gierflation und Schande profitiert. Daher ja auch Sicherheitsanker (andere Erwartungshaltung).

Die wenigen Einzelwerte, die ich aus Spaß noch halte, wollte ich unter 4% je Position laufen lassen. Da hat mir Growth (Technologie-Werte, allen voran Nvidia) aber einen Strich durch die Rechnung gemacht. Der Growth- und der Value-Anteil waren tatsächlich mal gleich groß bei jeweils ca. 15%. Nach dem Auseinanderlaufen wäre eigentlich ein Rebalancing fällig gewesen, aber ich war zu faul. Habe es einfach laufen lassen und nicht zu Gunsten von Schande oder ETF umgeschichtet.

Damit bin ich dieses Jahr 2023 mit +26,25% internem Zinsfuß rausgegangen. Nach dem extrem schwachen letzten Jahr pendelt sich der mehrjährige Schnitt wieder auf statistischem Mittelmaß ein. Erwartungsgemäß, möchte man sagen. Also alles gut im Depot und Grüße an Nvidia. Gute Arbeit, Leute!

Schon länger wollte ich mal etwas mit WebAssembly machen. Number crunching und performance-kritische Anwendung im Browser? Da bin ich dabei! Leider ist mir dazu nichts Realitätsnahes eingefallen (die klassische Schwierigkeit, wenn man zu einer Lösung das Problem sucht). Ich habe überlegt, ob man finanzmathematisch etwas implementieren könnte, aber über gleitende Durchschnitte oder Bezier-Splines mit 1000 Stützpunkten lacht sich ein Ryzen-Prozessor doch tot. Die üblichen Verdächtigen funktionieren locker in JavaScript.

Also habe ich das Game of Life von John H. Conway nochmal rausgekramt. Wie man das eben so macht, wenn man einfache Algorithmen auf größeren Datenmengen ausprobieren will. WebAssemblies (wasm) kann man in vielen Sprachen erzeugen. Ich habe es mit AssemblyScript probiert. Der Trick daran ist, dass man das auch nach JavaScript übersetzen kann - wichtig für Vergleiche. Aber hier erstmal das Ergebnis: der Evolutionsschritt findet in WebAssembly statt, das Rendering in JavaScript, denn WebAssembly hat keinen Zugriff auf das HTML DOM. Also bekommt es das Spielfeld als typisiertes Array und gibt die nächste Generation zurück. JavaScript packt das dann in ein Canvas.

Nerd-Hinweise: Ein Klick mit der linken Maustaste platziert einen sogenannten Gleiter, ein Klick mit der rechten Maustaste eine Gleiterkanone. Die Simulation wird gedrosselt auf rund 10 Generationen pro Sekunde. Wenn die Evolution zum Erliegen kommt, einfach die Seite neu laden, um das Spielfeld zu resetten.

Und hat sich der ganze Spaß nun gelohnt? Als Lernerfahrung schon, aus Performance-Sicht leider nicht. Für die Benchmark habe ich 1000 Generationen ungedrosselt laufen lassen, jeweils ohne Rendering, damit hier nicht die Grafikkarte oder die Rendering-Engine vom Browser dazwischen funkt. Es sollte die meiste Rechenzeit im Game-of-Life-Algorithmus verbracht werden und nicht in der Browser-Infrastruktur. Ich war vom Ergebnis so verblüfft, dass ich in zwei weiteren Browsern gegenprüfen musste. WebAssembly ist signifikant langsamer als JavaScript.

Ich vermute, das Problem ist zu sehr datengebunden. Die Übergabe der Rohdaten (nach WebAssembly und wieder raus, marshalling) ist teurer als wirklich mit den Daten etwas zu tun (der Algorithmus). Das Game of Life mit mehr als 100000 Feldern ist immer noch zu anspruchslos, um damit irgendwelche Optimierungen in verschiedenen Programmiersprachen und Runtimes zu machen.

Also Fazit: WebAssembly lohnt sich aus Performance-Sicht nicht pauschal. Vermutlich eher sehr selten. Ich denke, das ist etwas, wenn man existierenden Code in C++ oder Rust hat (Codecs, Krypto, Runtimes). Dann kann man den über Ecken auch im Browser ausführen. Wenn man eh neu entwickelt, kann man das auch direkt in JavaScript tun. Damit bin ich mir nicht mehr sicher, ob WebAssembly nicht nur ein modernes Flash oder Silverlight ist. Na mal sehen, ob da im Jahr 2030 noch ein Hahn nach kräht.

Mir ist kürzlich aufgefallen, dass mein vor etwa 20 Jahren gebautes Logo seit ungefähr 10 Jahren nicht mehr zeitgemäß ist. Leider bin ich auch nie richtig grün mit Bildbearbeitungsprogrammen geworden. Ich glaube ich hatte das Logo deswegen seinerzeit auch bereits mit POV-Ray gerendert, also quasi programmiert. Auf diese Art wollte ich mich auch an einem neuen Logo probieren. Ich habe mich dieses Mal für SVG (skalierbare Vektorgrafik) entschieden, weil ich es mit einem Texteditor manipulieren kann oder mit einem Programm, das Texte manipuliert.

Erste Idee: Es sollten idealerweise meine Initialen CS enthalten sein. Nun fällt auf, dass der obere Bogen des S ja schon ein C ist. Man muss das eine Zeichen innerhalb des anderen nur irgendwie sichtbar machen. Offensichtliche zweite Idee: andere Farbe! Ok, aber noch etwas subtiler wäre schön, zum Beispiel in der Geometrie. Geometrie? Geometrie? Da war doch was! Ich bin ja ein Fan von Mathematik im Allgemeinen und linearer Algebra im Besonderen. Außerdem glaube ich, dass visuelle Ästhetik unter anderem aus Mathematik kommt (Symmetrien, goldener Schnitt und Fraktale zum Beispiel).

Also sollte das S mit dem eingebetteten C irgendwie schlau zerschnitten werden. Und hier kommt wieder die Computergrafik ins Spiel. Ich mag außerdem 3D-Renderings und Drahtgittermodelle und an dieser Stelle wird es extrem: ich habe einen 3D-Software-Renderer nach SVG geschrieben - also ein Programm, dem man Dinge aus 3D-Koordinaten (x, y, z) reingibt und das zweidimensionales SVG (x, y) ausgibt. Ganz ohne DirectX, OpenGL und Vulkan, stattdessen mit Modell-, Ansicht- und Projektionsmatrix, perspektivischer Division und Bildschirm-Transformation. Lange Rede kurz: Ich habe ein animierbares Octahedron (Achtkant) hinter das S gepackt. Und damit ergibt sich ein "natürlicher" Schnitt in der Mitte.

Die Schriftart habe ich bei Google Fonts gesucht und gefunden. Als MINT’ler sollte es für mich nur einigermaßen futuristisch aussehen. Das Fundstück habe ich im True Type Font (TTF) Format heruntergeladen und dort das S als Pfad-Spezifikation extrahiert. Das ergibt also:

1. 3D-Octahedron nach 2D-SVG rendern.
2. Darüber bündig den extrahierten S-Pfad legen (verschieben und skalieren bis es passt).
3. Mit einem Texteditor den S-Pfad in zwei Pfade zerlegen sowie verschieden einfärben.
4. Puh. Und als weiteren Spaß auch noch eine Animation integrieren, damit man sieht, dass es eigentlich 3D gemeint ist.

Mit dem Ergebnis bin ich als Nicht-Grafiker zufrieden. Es ist zeitgemäß flach (wenig Details, keine Schattierungen) und funktioniert in Groß, Klein (als Icon) und sogar animiert. Ah, und es ist nicht gemalt sondern programmiert.

Dies ist die Fortsetzung meines Marktrückblicks von 2021, der wiederum eine Fortsetzung des Marktrückblicks von 2020 ist. Ich hatte es letztes Jahr schon beschrien: die Börsenentwicklung war da so gut, dass statistisch gesehen mal deutlich etwas in Abwärtsrichtung passieren musste.

Und naja, was soll ich sagen? Wie niemandem entgangen sein dürfte, ging es abwärts. Bereinigt um Zu- und Abflüsse waren es in meinem Depot negative 19% Performance (exklusive Dividenden, die den Verlust noch leicht abmildern). Finanzmathematisch dürfte es sich bei meiner Berechnungsmethode um den internen Zinsfuß oder einen Verwandten davon handeln.

Wie üblich und auch schon beim Corona-Crash 2020 habe ich die Gelegenheit zum außerordentlichen Nachkaufen genutzt. Tatsächlich stehen in diesem Jahr ausschließlich Nachkäufe in der Bilanz. Keine neuen Positionen und auch keine Verkäufe. Ich habe nirgends das Vertrauen verloren. Es ist es mir auch lieber, dass es jetzt kracht als später, denn beim vermeintlich Unvermeidlichen bin ich ungeduldig (Achtung: ich rechne Geduld in Quartalen, nicht in Stunden oder Tagen). Jetzt müsste man nur noch wissen, wann es überstanden ist. Zusammen mit meinem alten Kumpel - der Statistik - gehe ich insgesamt von 6 bis 12 mauen Quartalen aus.

War 2022 also ein Reinfall, das erste von mehreren verlorenen Jahren? Nein. Abgesehen von der Beseitigung meines statistischen Unbehagens war es Kaufgelegenheit. Netto bin ich am Ende ungefähr bei 0 rausgekommen, das heißt ich habe Kursrückgänge durch Zukäufe kompensiert, jedoch nicht überkompensiert (dafür hatte ich dann doch nicht genügend Liquidität). Somit war es das erste Mal, dass mein Depot in absoluten Zahlen auf Jahressicht nicht gewachsen ist (ich bin seit 2014 an der Börse aktiv). Jedoch sehe ich die diesjährigen Zuflüsse als rabattierte Grundsteine für späteres Wachstum oder wie André Kostolany es ausdrückte: »Wer die Aktien nicht hat, wenn sie fallen, hat sie auch nicht, wenn sie steigen.«.

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.