Wie zuletzt beschrieben, ist die Grafik-API Vulkan derzeit mein Hobbyschwerpunkt. Als weiteres Kleinprojekt habe ich den Quake 3 Model Viewer portiert. Das Ding begleitet mich nun schon sehr lange, von DirectX 8 über OpenGL 2 und 4 bis neuerdings Vulkan. Natürlich braucht man dafür keine derart schweren Geschütze - Quake 3 lief schon vor 20 Jahren rund. Allerdings ist das Format vergleichsweise leicht zu implementieren und man streift jedes Thema einmal: Texturierung, Animation, indizierte Koordinaten.

Screenshot Q3View Vulkan

Kühn wie ich so bin habe ich auch gleich einmal probiert, das Grafik-Backend (in diesem Fall natürlich Vulkan) austauschbar zu machen, um ggf. da einmal OpenGL oder sonstwas dranzuhängen. Zunächst für eine super Idee befunden, kann ich davon nun abraten. Die APIs sind derart unterschiedlich, dass wenig bleibt, was man abstrahieren kann. Das Ganze wirkt krass aufgesetzt und macht die Architektur nur komplizierter. Daher mein Ratschlag: wenn man sich für ein Grafik-API entscheidet, kann man ruhig all in gehen. Pluggable Backends können sich gern die großen Entwicklungsfirmen leisten, die Horden von Entwicklern an ihre Engines ansetzen.

Meine kleine Vulkan-Hilfsbibliothek ist weiter gewachsen, zum Beispiel um Klassen für Texturierung und Tiefen-Pufferung. Wie ich zuletzt schrieb: schade, dass jeder seine eigenen Wrapper erfindet, aber glücklicherweise schreibt man sie nur einmal. Es ist auch nicht so, dass ich nicht versucht habe, existierende Libraries zu finden. V-EZ (Vulkan easy) von AMD sah zum Beispiel vielversprechend aus. Der Solo-Entwickler darf daran allerdings nicht mehr entwickeln. Das Projekt ist also hochoffiziell tot, es steht nur nicht dran. Und von dieser Art findet man zahllose mehr. Die Grundsatzfrage bei der Sache ist natürlich: Was will man mit einem generischen Wrapper für Vulkan? Da kommt doch dann OpenGL raus. Die Frage ist berechtigt :)

Schließlich habe ich mir noch vcpkg für Bibliotheksmanagement angeschaut. Ich wollte ja das Dekomprimieren von Quake 3-Modellen nicht selber implementieren. Bisher habe ich zlib und weitere Bibliotheken immer für statischen CRT-Link gepatched und dann mit msbuild selbst gebaut. Stellt sich raus: das geht nun auch mit vcpkg. Die patchen Konfigurationen und bauen dann mit cmake. Klingt ganz einfach und praktisch, geht aber natürlich nicht ohne den üblichen Bloat. Die laden sich allen Ernstes beim ersten Ausführen eine portable Powershell, ein kleines MSys und Nuget runter. Gesamtwert entpackt: 1.2 GByte. Das ist bei heutiger Software leider voll der Trend und noch lange nicht das Ende der Fahnenstange. Ich habe mir kürzlich Skia angeschaut. Damit kann man 2D-Grafiken erstellen, also sowas wie eine Linie von oben links nach unten rechts zeichnen. Dazu braucht man ein Google Build-System, Python, Ninja und wenn man das Bauen dann auslöst, fängt das Script an, x abhängige Git-Repos zu kopieren (Unicode, Textrendering, whatever). Man braucht mehr als 2 GByte an Build-Werkzeugen (so groß wie meine erste Festplatte). Raus kommt eine DLL mit 7 Mbyte. Das ist doppelt so groß wie Turbo Pascal 7.

Ich werd zu alt für so'n Scheiß. Aber High Performance Computergrafik mit C++ ist schon ganz schön geil.