Wenngleich es sich um ein Rewrite handelt, nehme ich sämtliche Konzeptarbeit aus der letzten Iteration mit. Insbesondere im Rahmen des Rendering-Ablaufs konnte ich im Lauf der Jahre eine ganze Reihe gut funktionierender und teilweise nicht ganz trivialer Konzepte herausarbeiten, die ich zum Teil bereits auf der Devmania 2009 in einer etwas in technischen Details verlorenen Präsentation vorgestellt hatte. Das natürliche Wachstum dieser Konzepte gepaart mit meinen damaligen Designfertigkeiten resultierten zwangsläufig in einer etwas undurchsichtigen Aufgabenverteilung und einigen Verstrickungen, und es erfüllt mich mit Glück, dass ich diese nun endlich in destillierter und entwirrter Form klar implementieren konnte.
Die neue Iteration basiert auf der ebenfalls innerhalb der letzten 6 Monaten entwickelten lean C++ Bibliothek, und macht damit erstmalig massiven Gebrauch von Speicher- und Ressourcenverwaltung mit RAII. Damit verbunden ist weitreichende Ausnahmesicherheit. Es war eine unglaubliche Erfahrung, minimalen Wrapping-Prinzipien folgend erstmals praktisch alle Fehler mit einer verschwindenden Menge von Zusatzcode sinnvoll, wohldefiniert und strukturiert behandeln zu können. Zuvor war ich 6 Monate an einem Java-Projekt beteiligt gewesen, bei dem ich erstmals versucht hatte, Ausnahmesicherheit konsequent umzusetzen, was sich dort mangels RAII und dank gefühlter 2000 verschiedener Ausnahmetypen als gigantische Qual entpuppte. Mit einer geringen Anzahl von Ausnahmetypen und RAII wird einem in C++ die Fehlerbehandlung praktisch geschenkt. Zudem erspart man sich sämtliche manuelle Entsprerrungs- und Freigabelogik, wodurch ich in meinem Rewrite nun bereits mit einem gefühlten Zehntel des Quellcodes der alten Iteration wesentlich mehr Funktionalität implementieren kann.
(Anmerkung hierbei: Schon mit einer geringen Anzahl von Fehlerbehandlungsmakros (z.B. automatisierter Log-Eintrag und/oder Ausnahme bei Fehlschlag eines WinAPI- oder DirectX-Aufrufs) schrumpft der Fehlerbehandlungscode auf eine bis keine Zeile pro potentiell fehlschlagendem API-/System-Aufruf. Ist man erstmal weg von der unmittelbaren Dritt-API-Ebene im eigenen Code angekommen, regeln Ausnahmen den Rest praktisch von selbst.)
Ganz wichtig ist natürlich der Schritt von DirectX 9 auf DirectX 11, womit mir endlich neue Türen wie Tesselation, Compute Shaders, Geometry Shaders und korrektes Multisampling offen stehen. Bezüglich API-Unabhängigkeit habe ich endlich auf jegliche Laufzeitpolymorphie verzichtet, ich implementiere momentan (und wohl auch zukünftig) ausschließlich einen DirectX-11-Zweig. Einige Entkopplungsvorkehrungen erlauben prinzipiell die Implementierung und Auswahl weiterer Alternativen zur Compilezeit.
Ich kann nur allen davon abraten, APIs mehr oder weniger unverändert um der Unabhängigkeit Willen zu wrappen. Das ist nicht nur reine Zeitverschwendung, sondern verhindert ausschließlich extrem effektiv die Nutzung neuer wie ungewrappter API-Features. Die erste Ebene, auf der sich Entkopplung überhaupt lohnt, ist die, die überhaupt nichts mehr mit den Aufgaben der zugrundeligenden API zu tun hat. Für die letzte Iteration hatte ich DirectX 9 tatsächlich ziemlich komplett gewrappt, und es hat mir, abgesehen von einem etwas breiteren Überblick über die API, absolut nichts gebracht (von der Zeit, die ich damals vertan habe, will ich gar nicht reden).
Weiterhin verfolge ich auf Twitter seit einiger Zeit mit Spannung die Bewegung des Data-oriented Design. Die Idee, alleine durch Datenaufteilung und -sortierung sowie Vereinfachung des Codes auf genau das, was er schlussendlich auch tun soll (d.h. keine Laufzeitpolymorphie, wenig Indirektionen), bedeutende Effizienzsteigerungen zu erreichen, ist in ihrer Logik und Einfachheit bestechend. Da baut man über Jahre Schlösser von hochgradig objektorientierten, gekapselten Systemen, nur um am Ende gesagt zu kriegen, dass der Code, den man intuitiv als Anfänger geschrieben hätte, der Code, der den Job ohne Erweiterbarkeit und ohne große Flexibilität einfach nur erfüllt, schlussendlich auch der beste gewesen wäre. Ich bin von dieser Bewegung alles andere als bedingungslos überzeugt, gerade weil es mit dieser Iteration mein Ziel ist, am Ende auf ein gut designtes Stück offener Software blicken zu können, wohingegen Data-oriented Design Software für eine ganz bestimmte Aufgabe / ein bestimmtes Produkt liefert.
Dennoch hat die Bewegung mich maßgeblich beeinflusst, gerade mit ihrem Credo der Datentransformation anstelle von Datenmanipulation habe ich mich bereits angefreundet. So versuche ich in dieser Iteration innerhalb von inneren Schleifen, beispielsweise dort, wo die gesamte Szene gecullt wird, auf jegliche Indirektion und Polymorphie zu verzichten. Stattdessen habe ich renderbare Objekte auf Datenebene soweit vereinheitlicht, dass ich sie alle in einer einzigen Schleife ohne Aufruf weiterer nicht-inline Funktionen abarbeiten, und sichtbare Objekte direkt in weitere vorkategorisierte Listen eintragen kann.
Schlussendlich bleibt mein Ziel trotz Ansätzen von Data-oriented Design ein klares objektorientiertes Design. Ich vermeide Indirektionen und Laufzeitpolymoprhie, wo ich die Möglichkeiten sehe, vermeide überflüssige Funktionalität und die Vermischung von Aufgaben. Um den Overhead vieler kleiner Objekte aufgrund von rigoroser Aufgabenteilung zu verringern, aggregiere ich viele Klassen by-value, das verringert die Speicherfragmentierung und erhöht die Lokalität für Cache-Ausnutzung.
Eine letzte bedeutende Sache, die mir in der letzten Iteration im Nachhinein sehr negativ aufgefallen ist, war der viel zu hohe Grad an Kapselung. Statt sich selbst aus vielen weiteren Objekten aufzubauen, werden Objekte in der neuen Iteration weitestgehend von außen zusammengebaut. Das macht die API zunächst unglaublich unübersichtlich, weil unter 20 manuell erstellten Framework-Objekten nicht mal ein Würfel gerendert werden kann, lässt sich jedoch sehr sehr leicht durch einige Fabrik-Funktionen beheben (ja, freie Funktionen, benutze ich nun auch für alles, was nicht mit Implementierungsdetails von Klassen zu tun hat). Diese Fabrikfunktionen ergänzen dann fehlende Objektkonstruktionsparameter einfach durch neu erzeugte Instanzen der notwendigen Klassen, ohne dass der Anwender je mehr als sein Renderer-Objekt rumreichen muss. Am Ende hat man dank geringer Kapselungstiefe einen gigantischen Flexibilitätsgewinn und zugleich sehr gute Usability, obendrein beides mit einem Minimum an Laufzeitpolymorphie.
Wow, das war viel Metatalk, ich hoffe nicht gänzlich uninteressant. Ich möchte mich an dieser Stelle noch bei Krishty, dot und jokester bedanken, die meine Programmierung in vielerlei Hinsicht maßgeblich beeinflusst haben, und ohne die ich nie dorthin gefunden hätte, wo ich heute bin.
Zur Diskussion sind alle herzlich eingeladen. Ich meinerseits hoffe, dass ich bald die Zeit finde, konkreteres zu berichten. Möglicherweise biete ich das ganze sogar bald Open Source an. ;-)
