rlsw – Raylib-Software-OpenGL-Renderer mit weniger als 5.000 LOC

• rlsw ist ein OpenGL-1.1-Stil-Software-Renderer, der ein alternatives Backend bereitstellt, um raylib in Umgebungen ohne GPU auszuführen
• Unterstützt verschiedene Render-Modi wie Punkt, Linie, Dreieck, Quad sowie umfangreiche Funktionen wie Clipping, Texturierung und mehrere Farb-/Tiefenpuffer
• Texturen können in allen von raylib unterstützten unkomprimierten Formaten verwendet werden; Filter- und Wrap-Einstellungen sind fein granular steuerbar
• Enthält zentrale 3D-Grafikfunktionen wie Matrix-Stack, Tiefentest, Blending, Cull Face und maximiert die Kompatibilität durch OpenGL-Funktionsbindungen
• Mit einem Umfang von unter 5.000 Zeilen liegt sein Vorteil gegenüber anderen Software-Renderern vor allem in Einfachheit und Integrationsfähigkeit bei Performance und Ressourceneffizienz

---

rlsw: Überblick über den Raylib Software-OpenGL-Renderer

Einführung

• rlsw ist eine Bibliothek, die die vom rlgl.h von raylib bereitgestellten Funktionen vollständig als OpenGL-1.1-Stil im Software-Ansatz implementiert
• Es wurde als direktes Ersatz-Backend konzipiert, das raylib auch auf Geräten ohne jegliche GPU ausführen kann

Hauptfunktionen

• Rendern erfolgt über einen benutzerdefinierten internen Framebuffer mit vielfältigen Farb-/Tiefenmodi (RGB 8/16/24bit, Depth 8/16/24bit)
• Unterstützte Render-Modi: Punkt, Linie, Dreieck, Quad
  • Konfigurierbare Optionen wie Punktdicke, Linienbreite und Polygonmodus
  • Alle Render-Modi unterstützen Clipping
• Texturfunktionen: Unterstützung aller unkomprimierten Formate, die von raylib unterstützt werden
  • Prüfung/Steuerung von Minification/Magnification
  • Punkt- und Bilinearfilterung
  • Ausführlich konfigurierbare Wrap-Modi pro S/T-Koordinate
• Direkte Vertex-Array-Unterstützung, sofortiges Zeichnen von Primitiven
• Unterstützung der Matrix-Stack (Push/Pop)
• Weitere Funktionen: OpenGL-Stil-Getter, Framebuffer-Resize, Perspective-Correction, Scissor-Clipping, Tiefentest, Blend, Cull Face

Verwendung und Anpassung

• Besteht aus einer einzelnen Header-&-Source-Struktur, bei der die Implementierung via #define RLSW_IMPLEMENTATION erzeugt werden kann
• Unterstützt benutzerspezifische Anpassungen über mehrere Build-Zeit-Konstanten vor dem Build
  • z. B. Anpassung der maximalen Anzahl/Größe von Framebuffer- oder Texturobjekten

Struktur und Typen

• Definiert mehrere OpenGL-kompatible Enums und Typen sowie interne Strukturen wie sw_vertex_t, sw_texture_t
• Ersetzt die meisten OpenGL-Aufrufe durch entsprechende rlsw-Funktionen zur alternativen Nutzung
• Stabiles internes Zustandsverwaltungssystem für diverse Matrizen-, Status- und Texturverwaltungen

Lizenz und Einsatz

• Veröffentlicht unter der MIT-Lizenz, daher frei für kommerzielle, nicht-kommerzielle Nutzung und die Erstellung von Derivaten
• Der Fokus liegt auf Leichtgewichtigkeit und vollständigem Software-Ersatz statt auf maximaler Performance, was den einfachen Einsatz bei Integration und Distribution begünstigt

Detaillierte Zusammenfassung

Header-Struktur und Beschreibung

• rlsw ersetzt nahezu alle OpenGL-1.1-Funktionen auf Funktions-Ebene vollständig durch Softwareimplementierungen
• Diese Header-Datei (rlsw.h) definiert
  • Werttypen sowie benutzerdefinierte Enums und Structs
  • Makros, die OpenGL-Befehle auf interne rlsw-Funktionen remappen
  • die API-Deklarationen (Initialisierung, Framebuffer-Kopie/Abruf, Zeichnen, Clear, Vertex-/Textureingabe etc.)

Hauptmerkmale

• Unterstützt intern mehrere stackbasierte Matrizen (eigene Stacks für Projection/ModelView/Texture)
• Render-State-Verwaltung: Bitweise Steuerung von Scissor, aktiver Texture und Depth-Test
• OpenGL-Kompatibilitätsfunktionen: diverse Getter, Zustandskopie, Fehlerbehandlung
• Texturverarbeitung: unkomprimierte Formate, Filter-/Wrap-Modi, Speicheroperationen
• Standardmäßig werden die meisten 2D/3D-Formen (Punkt, Linie, Dreieck, Quad) sowie Farb- und Tiefenverarbeitung unterstützt

Anpassbare Konfigurationswerte

• Framebuffer-/Texturauflösung und -anzahl, Farb-/Tiefenpuffer-Bitbreite, Tiefe der Matrix-Stacks, maximale Texturanzahl und mehr
• Erweiterte Benutzereinstellungen wie SW_MAX_CLIPPED_POLYGON_VERTICES

Wichtige interne Strukturen

• sw_context_t: Enthält den vollständigen Kontext mit allen Zuständen und Buffern
• Internes integriertes Management von Vertex Buffer, Texture Array, Framebuffer und Statusflags

Vorteile und Einsatzgebiete

• Optimiert für Geräte ohne GPU, Embedded-Umgebungen sowie Plattformentwicklung, Portierung, Test und Automatisierung
• Kann raylib-basierte Apps vollständig ohne OpenGL nur mit Software ausführen
• Die schlanke Struktur ist sehr gut geeignet für neue Experimente/Entwicklung und die Unterstützung nicht standardisierter Umgebungen

Lizenz und Beitragende

• Flexible Weiterverteilung dank MIT-Lizenz
• Review von Le Juez Victor, Ramon Santamaria (2025–2026)

Fazit

• rlsw ist ein raylib-kompatibler nahezu vollständiger Pure-Software-Renderer mit OpenGL-Nähe
• Durch einzelne Datei, geringe Größe, Erweiterbarkeit und vollständige Texturformat-Unterstützung in raylib übertrifft es in Bezug auf Einstiegshürde und Integrationsgrad viele andere reine Software-Grafiklösungen
• Besonders wertvoll für Projekte mit Fokus auf Low-Level-Graphics und Portabilität

[GN⁺]

Hacker-News-Kommentare

• Der Autor von Raylib hat mit großer Freude bekannt gegeben, dass sich ein komplettes Raylib-Programm ohne externe Abhängigkeiten ausschließlich als Win32-App kompilieren lässt Link
  • Wirklich spannend, ich habe aus Spaß für einen eingebetteten Prozessor nach etwas gesucht, mit dem man auf einem LED-Bildschirm etwas rendern kann, aber bisher war nichts davon zufriedenstellend. Wenn ich es richtig verstanden habe, müsste man das kompilieren und Software-Rendering nutzen können. Bei meiner Größe von etwa 192x128 Pixeln dürfte das auf praktisch jedem System schnell genug sein, also ist es jetzt wohl Zeit für ein paar interessante Animationen
  • Für Win32 gibt es bereits einen ziemlich brauchbaren OpenGL-1.2-Software-Renderer
  • Ich frage mich, warum man das unbedingt so machen sollte
• Mich würde Tsodings Meinung zu dieser Nachricht interessieren
  • Wahrscheinlich hat Tsoding jetzt das Interesse verloren, weil es inzwischen Mainstream geworden ist und es sogar bis auf HN geschafft hat
• Es ist cool, dass Computer inzwischen so schnell sind, dass man allein mit solchen OpenGL-1.1-Bibliotheken für Software-Rendering schon ein ziemlich ordentliches 2D-Spiel bauen kann
  • Wenn man die Auflösung niedrig hält, die Komplexität der Szene bewusst im Griff behält und beim Art Style klare Entscheidungen trifft, konnte man schon auf Hardware von vor 20 Jahren ein vernünftiges 3D-Spiel bauen. Ich habe tatsächlich selbst testweise ein Spiel gemacht 1 2, und jetzt, da ich weiß, dass das möglich ist, plane ich ein zweites, „ernsthafteres“ und ausgereifteres Spiel. Man merkt wirklich, wie stark sich die Rechnerleistung verbessert hat. Die Neuigkeiten zu Raylib sind ebenfalls großartig, und ich überlege ernsthaft, es tatsächlich einzusetzen
  • Edit: Mir war nicht klar, dass es sich um Software-Rendering handelt. Trotzdem glaube ich, dass mein Spiel sich auch nur mit einem optimalen Sprite-Tiefensortierungsalgorithmus auf der CPU rendern ließe, es ist im isometrischen Pixel-Art-Stil wie RollerCoaster Tycoon. Beim Metropolis-1998-Projekt aus den 90ern musste ich die uralte OpenGL-Fixed-Function-Pipeline verwenden, zum Glück habe ich entdeckt, dass man über Erweiterungsfunktionen in der gl.h-Datei zusätzliche Felder an die GPU übergeben kann. Ich nutze SFML als Grafik-Framework, wahrscheinlich auf Basis von OpenGL 1.x. Ein aktuelles Beispiel dafür, was dieser Ansatz leisten kann, ist das Spiel Metropolis 1998
  • Ich denke, Software-Rendering ist letztlich die Zukunft, unter der Bedingung, dass man Hardware-Beschleunigung aktiv so nutzen kann wie bei GPGPU
  • Es gab schon vor Jahrzehnten ein vollständig in Software gerendertes 3D Unreal Tournament, und es läuft auch 2023 noch gut Link
• Fabrice Bellard hat auch TinyGL rund um OpenGL geschrieben Link
  • Erstaunlich ist, dass am 5. März 2022 TinyGL 0.4.1 erschienen ist, während TinyGL 0.4 ursprünglich am 17. März 2002 veröffentlicht wurde, „unser Entwicklungsplan erstreckt sich über Jahrhunderte“
  • Die Person ist ein wirklich beeindruckendes Vorbild, das scheinbar fast alles hinbekommt
  • In den 90ern habe ich viele Software-Renderer dieser Art gesehen, aber ehrlich gesagt waren sie damals langsam und schwerfällig oder produzierten viele Artefakte, daher mochte ich sie nicht besonders. Für gute Performance brauchte man eine enge Integration zwischen Spiel und Renderer, eine gewisse Ironie der Geschichte
  • Zur Info: Es gibt auch tinygl, einen von C-Chads geforkten Ableger, der deutlich länger gepflegt wurde als das Original und verschiedene Funktionen wie Multithreading ergänzt hat, Ende 2023 aber archiviert wurde
• Dank pikuma.com habe ich die Schönheit von Software-Renderern kennengelernt und bin sehr stolz darauf, dass ich den Großteil des Codes verstehen konnte
• Bei der Beschreibung „OpenGL-1.1-artige Implementierung in Software“ frage ich mich, wie viele Zeilen nötig wären, um OpenGL 2.0 zu implementieren, die Nicht-ES-Version
  • Mindestens ein paar Dutzend Mal mehr. Die Unterstützung für benutzerprogrammierbare Shader (ARB-Assembly/GLSL) wäre am schwierigsten, und man bräuchte außerdem einen GLSL-Parser und einen Shader-Interpreter. Dazu kämen Multitexturing und verschiedene Texture Combiner. Insgesamt halte ich selbst mit einer sehr konservativen Schätzung mindestens 40.000 Zeilen für nötig. Wenn man natürlich nicht die komplette Spezifikation umsetzt und nur das Minimum nimmt, könnte es auch weniger sein
  • Ich habe früher tatsächlich einmal die OpenGL-API für Fixed-Function-Hardware implementiert, bis Version 1.5, dazu noch einige Erweiterungen wie Framebuffer Objects. Die 1.x-Reihe enthält zwar viel Überflüssiges, ist aber leicht zu implementieren. 2.x mit Shadern ist in Software sehr schwer umzusetzen
  • Die genaue Zeilenzahl kenne ich nicht, aber es gibt auch PortableGL, einen 3.x-Software-Renderer. Ein sehr cooles Projekt, mit dem man auch gern herumspielt
• Zum Begriff OpenGL-artig
  • Wenn man das nur anhand der Header beurteilt: Glückwunsch, das ist eine ziemlich ordentliche OpenGL-1.1-Software-Implementierung. Sie erfüllt natürlich nicht die gesamte Spezifikation, sondern eher so wie frühere MiniGL-Treiber nur die Teile, die nötig sind, damit Spiele laufen. Dieses Projekt setzt ähnlich nur das um, was nötig ist, damit Raylibs OpenGL-Backend funktioniert. Das Ziel ist, es ohne externe Grafik-Abhängigkeiten nutzbar zu machen
• Ich frage mich, ob es CUDA unterstützt
  • Nein, es ist reines CPU-Rendering, es verwendet nicht einmal SIMD, sondern nur direkten Integer-/Floating-Point-Code
• Das scheint perfekt zur Nintendo 3DS zu passen
  • Dann frage ich mich, ob man das auch für die Entwicklung von Spielen für Konsolen wie NES, SNES oder Genesis nutzen könnte