rlsw – Moteur de rendu OpenGL logiciel pour raylib, moins de 5000 lignes

• rlsw est un moteur de rendu logiciel de style OpenGL 1.1 qui fournit un backend alternatif pour exécuter raylib dans des environnements sans GPU
• Il prend en charge divers modes de rendu (points, lignes, triangles, quads), ainsi que le clipping, les textures, et des tampons couleur/profondeur multiples
• Les textures peuvent utiliser tous les formats non compressés pris en charge par raylib, avec un contrôle précis des réglages de filtrage et de wrapping
• Les fonctionnalités 3D clés comme la pile de matrices, le test de profondeur, le blend et la culling de faces sont intégrées ; la compatibilité est maximisée grâce à des bindings OpenGL
• Avec une taille inférieure à 5000 lignes, le projet se distingue des autres rendus logiciels par sa simplicité et son intégration, avec une priorité sur la légèreté plutôt que sur les performances

---

rlsw : aperçu du moteur de rendu OpenGL logiciel raylib

Introduction

• rlsw est un moteur de rendu logiciel de style OpenGL 1.1 qui implémente en software l’ensemble des fonctions fournies par rlgl.h dans raylib
• Il est conçu comme un backend de remplacement direct pour exécuter raylib même sur des appareils qui n’ont tout bonnement pas de GPU

Fonctionnalités principales

• Le rendu s’effectue dans un framebuffer interne personnalisé avec prise en charge de plusieurs modes couleur/profondeur (RGB 8, 16, 24 bits, depth 8/16/24 bits)
• Modes de rendu pris en charge : points, lignes, triangles, quads
  • Les réglages de rendu détaillés peuvent être personnalisés, notamment l’épaisseur des points, la largeur des lignes et le mode polygonal
  • Tous les modes de rendu prennent en charge le clipping
• Gestion des textures : tous les formats non compressés supportés par raylib
  • Contrôle de la minification/magnification
  • Filtrage point/bi-linéaire
  • Application fine du mode wrap par coordonnées S/T
• Support direct des vertex arrays, avec dessin direct de primitives
• Pile de matrices (Push/Pop) prise en charge
• Autres fonctions : getter de style OpenGL, redimensionnement du framebuffer, correction de perspective, scissor clipping, test de profondeur, blend, culling de faces

Utilisation et personnalisation

• Il suit une structure header+source unique, et la génération du code d’implémentation peut se faire via #define RLSW_IMPLEMENTATION
• Avant la compilation, plusieurs constantes de configuration fine permettent une personnalisation utilisateur
  • ex. Ajustement du nombre/taille max du framebuffer ou des textures

Structure et types

• Définition de plusieurs enums et types compatibles OpenGL, ainsi que de structures internes dédiées (sw_vertex_t, sw_texture_t, etc.)
• La majorité des appels OpenGL peuvent être remappés vers des fonctions rlsw pour substitution
• Gestion d’état interne robuste pour les matrices, les états et la gestion des textures

Licence et usages

• Sous licence MIT, utilisation commerciale ou non commerciale et création d’œuvres dérivées autorisées
• Le projet privilégie la légèreté et le remplacement entièrement logiciel plutôt que la performance, avec un avantage pour l’intégration et le déploiement rapides

Résumé détaillé

Structure du header et explications

• rlsw remplace presque intégralement en software les fonctions OpenGL 1.1
• Ce header (rlsw.h) définit
  • les types de valeur, les enum et struct personnalisés
  • la substitution des commandes OpenGL par des fonctions internes rlsw via des macros
  • la déclaration de l’API (initialisation, copie/obtention de framebuffer, draw, clear, soumission de vertex/texture, etc.)

Fonctions phares

• Prise en charge interne de plusieurs stacks de matrices (réservées à Projection/ModelView/Texture)
• Gestion de l’état de rendu : manipulation de bits d’état pour Scissor, activation de texture ou Depth Test
• Fonctions de compatibilité OpenGL : getter variés, copie d’état, gestion d’erreurs
• Gestion des textures : formats non compressés, modes filter/wrap, copie mémoire, etc.
• Par défaut, la plupart des formes 2D/3D (point, ligne, triangle, quad) ainsi que la gestion de la couleur et de la profondeur sont prises en charge

Paramètres configurables

• Résolution et nombre de framebuffers/textures, largeur des bits des tampons couleur/profondeur, profondeur de la pile de matrices, nombre maximal de textures, etc.
• Possibilité d’ajuster des options avancées côté utilisateur comme SW_MAX_CLIPPED_POLYGON_VERTICES

Éléments clés des structures internes

• sw_context_t : regroupe l’ensemble des états et buffers de tout le contexte
• Gestion unifiée en interne du vertex buffer, du tableau de textures, du framebuffer, des drapeaux d’état, etc.

Atouts et cas d’usage

• Optimisé pour les appareils sans GPU, les environnements embarqués, la portabilité OS, les tests et l’automatisation du développement
• Exécution possible d’applications basées sur raylib en pur software, même sans OpenGL
• La structure légère le rend très adapté aux nouveaux prototypes ou développements, ainsi qu’au support d’environnements non standards

Licence et contributeurs

• Redistribution souple sous licence MIT
• Revu par Le Juez Victor et Ramon Santamaria (2025–2026)

Conclusion

• rlsw est un moteur de rendu purement logiciel pour raylib presque totalement compatible avec OpenGL
• Avec un seul fichier, une faible empreinte, une extensibilité élevée et la prise en charge complète des formats de texture raylib, il offre à la fois une faible barrière d’entrée et une bonne intégration par rapport aux autres solutions de graphisme software
• Sa valeur est particulièrement élevée pour les projets orientés graphisme bas niveau et portabilité

[GN⁺]

Avis Hacker News

• L’auteur de Raylib a annoncé avec beaucoup d’enthousiasme qu’il est possible de compiler un programme raylib complet sans dépendance externe, uniquement avec une application win32 lien
  • C’est vraiment intéressant, je cherchais pour le plaisir quelque chose capable de faire du rendu sur un écran LED afin de l’utiliser sur un processeur embarqué, et jusqu’ici rien de ce que j’ai trouvé ne m’a satisfait, si j’ai bien compris, je devrais pouvoir compiler ça et faire du rendu logiciel, et pour ma taille d’environ 192x128 pixels, ce sera probablement assez rapide sur n’importe quel système, il est donc temps de faire des animations amusantes
  • Win32 a déjà un renderer logiciel OpenGL 1.2 plutôt correct
  • Je me demande pourquoi il faudrait se donner cette peine
• Je suis curieux de connaître l’avis de Tsoding sur cette nouvelle
  • Maintenant que c’est devenu mainstream et que c’est même arrivé sur HN, Tsoding va probablement perdre tout intérêt
• C’est cool de voir que les ordinateurs sont devenus si rapides qu’on peut faire un jeu 2D tout à fait correct rien qu’avec ce type de bibliothèque OpenGL 1.1 en rendu logiciel
  • En gardant une faible résolution, en maîtrisant soigneusement la complexité des scènes et en faisant des choix clairs côté style artistique, on pouvait déjà créer un jeu 3D raisonnable qui tourne sur du matériel d’il y a 20 ans, j’ai d’ailleurs fait moi-même des essais en développant un jeu1 2, et maintenant que je sais que c’est possible, je prévois de faire un deuxième jeu plus « sérieux » et plus abouti, on sent vraiment à quel point les performances des ordinateurs se sont améliorées, et la nouvelle autour de Raylib est aussi vraiment excellente, au point que j’envisage sérieusement de l’adopter
  • Modification : je n’avais pas réalisé qu’il s’agissait de rendu logiciel, mais malgré tout je pense que mon jeu pourrait aussi être rendu avec seulement un algorithme optimal de tri en profondeur des sprites sur CPU (c’est un pixel art isométrique à la RollerCoaster Tycoon), dans le projet Metropolis 1998 inspiré des années 90 il a fallu utiliser l’antique pipeline fixed function d’OpenGL (heureusement, j’ai découvert dans le fichier gl.h qu’on pouvait transmettre des champs supplémentaires au GPU via des fonctions d’extension), j’utilise SFML comme framework graphique et c’est probablement basé sur OpenGL 1.x, et comme exemple récent, le jeu Metropolis 1998 montre bien ce que cette approche peut permettre de faire
  • Je pense que le rendu logiciel est au fond l’avenir, à condition de pouvoir exploiter agressivement l’accélération matérielle comme avec le GPGPU
  • Il existait déjà il y a des décennies Unreal Tournament entièrement en 3D rendu par logiciel, et ça fonctionne encore très bien en 2023 lien
• Fabrice Bellard avait aussi écrit TinyGL autour d’OpenGL lien
  • Ce qui est remarquable, c’est que TinyGL 0.4.1 est sorti le 5 mars 2022, alors que TinyGL 0.4 avait été publié pour la première fois le 17 mars 2002, « notre plan de développement s’étend sur plusieurs siècles »
  • Cette personne est un modèle absolument impressionnant, capable de presque tout faire
  • J’ai vu beaucoup de renderers logiciels de ce genre dans les années 90, et franchement à l’époque ce n’était pas terrible : c’était lent et lourd, ou alors bourré d’artefacts, et pour avoir de bonnes performances il fallait une intégration étroite entre le jeu et le renderer, il y a là une certaine ironie historique
  • À noter qu’il existe aussi tinygl, un fork par C-Chads, maintenu bien plus récemment que l’original et enrichi de diverses fonctionnalités comme le multithreading, même s’il a été archivé fin 2023
• Grâce à pikuma.com, j’ai découvert la beauté des renderers logiciels, et je suis très fier de pouvoir comprendre la majorité du code
• En voyant la description « OpenGL 1.1-style implementation on software », je me demande combien de lignes il faudrait pour implémenter OpenGL 2.0 (version non ES)
  • Au minimum plusieurs dizaines de fois plus, la partie la plus difficile étant l’implémentation des shaders programmables côté utilisateur (assembleur ARB/GLSL), avec en plus un parseur GLSL et un interpréteur de shaders à développer, sans parler du multitexturing et des divers texture combiners, au total je dirais qu’il faut au moins 40 000 lignes même en restant très conservateur, bien sûr cela pourrait être moins si on n’implémente pas toute la spec et qu’on se limite au strict minimum
  • J’ai déjà implémenté par le passé une API OpenGL pour du matériel fixed function, avec une prise en charge jusqu’à la version 1.5 plus quelques extensions comme les framebuffer objects, la série 1.x contient beaucoup d’éléments inutiles mais reste facile à implémenter, alors que la série 2.x (avec l’introduction des shaders) est très difficile à implémenter en logiciel
  • Je ne connais pas le nombre exact de lignes, mais il existe aussi PortableGL, un renderer logiciel 3.x, c’est un projet vraiment chouette et très amusant à expérimenter
• À propos de l’expression OpenGL-style
  • Si on se base seulement sur le header, félicitations, c’est une implémentation logicielle OpenGL 1.1 tout à fait respectable, même si elle ne couvre évidemment pas toute la spec, mais plutôt juste ce qu’il faut pour faire tourner des jeux, un peu comme les anciens drivers MiniGL, et ce projet fait pareil en implémentant juste assez pour que le backend OpenGL de Raylib fonctionne, avec pour objectif de pouvoir l’utiliser sans dépendance graphique externe
• Je me demande s’il y a un support CUDA
  • Non, c’est du rendu CPU uniquement, sans même utiliser SIMD, juste du code direct basé sur des entiers et des flottants
• Ça semblerait parfaitement adapté à la Nintendo 3DS
  • Du coup, je me demande si on pourrait aussi s’en servir pour développer des jeux pour des consoles comme la NES, la SNES ou la Genesis