rlsw: Renderizador de OpenGL por software de raylib, con menos de 5 mil líneas LOC

• rlsw es un renderizador de software con estilo OpenGL 1.1 que ofrece un backend alternativo para ejecutar raylib en entornos sin GPU
• Soporta numerosos modos de renderizado, entre ellos puntos, líneas, triángulos y quads, además de funciones amplias como clipping, texturas, buffers de color/profundidad múltiples
• Las texturas pueden usar todos los formatos sin comprimir compatibles con raylib, y también permite controlar con precisión la configuración de filtrado y wrapping
• Incluye funciones 3D clave como pila de matrices, depth test, blend, cull face, y maximiza la compatibilidad usando bindings de funciones de OpenGL
• Con un tamaño de menos de 5 mil líneas, destaca frente a otros renderizadores de software por su simplicidad e integración, además de su ligereza

---

rlsw: Resumen del renderizador OpenGL por software de Raylib

Introducción

• rlsw es una librería de renderizado por software estilo OpenGL 1.1 que implementa completamente en software la funcionalidad completa ofrecida por rlgl.h de raylib
• Está diseñado como backend de reemplazo directo para ejecutar raylib incluso en dispositivos que no tienen GPU

Funciones principales

• Realiza el renderizado en un framebuffer interno personalizado y admite múltiples modos de color/profundidad (RGB 8, 16, 24 bit, Depth 8/16/24 bit)
• Modos de renderizado soportados: puntos, líneas, triángulos, quads
  • Configuración adicional de renderizado disponible, como grosor de puntos, ancho de líneas y modo de polígono
  • Todos los modos de renderizado admiten clipping
• Funciones de textura: soporta todos los formatos sin compresión que raylib soporta
  • Comprobación de minificación/magnificación
  • Filtrado point/bilinear
  • Aplicación detallada de modo wrap por coordenada S/T
• Soporte directo de arrays de vértices, con dibujo inmediato de primitivas
• Soporte de pila de matrices (Push/Pop)
• Otras funciones: getters estilo OpenGL, redimensionado de framebuffer, corrección de perspectiva, scissor clipping, depth test, blend, cull face

Uso y personalización

• Tiene una estructura de un solo encabezado y fuente, y permite generar la implementación mediante #define RLSW_IMPLEMENTATION
• Permite personalización por parte del usuario con múltiples constantes de configuración antes de compilar
  • Ejemplo: ajustar el máximo de framebuffer o texturas y sus tamaños

Estructura y tipos

• Define diversos enums y tipos compatibles con OpenGL, así como structs internos (como sw_vertex_t, sw_texture_t, etc.)
• Es posible reemplazar y reutilizar la mayoría de las llamadas de OpenGL como funciones de rlsw
• Una estructura de manejo de estado interno robusta para matrices, estados y texturas, entre otros

Licencia y uso

• Con licencia MIT, permite uso y distribución comercial y no comercial, además de la creación de derivadas
• Al priorizar la ligereza y el reemplazo total por software sobre el rendimiento, destaca en integración y despliegue sencillos

Resumen detallado

Estructura del encabezado y descripción

• rlsw reemplaza casi por completo en software, a nivel de función, las capacidades de OpenGL 1.1
• Este encabezado (rlsw.h) define lo siguiente
  • tipos de valor, enums y structs personalizados
  • reemplazo de comandos de OpenGL por funciones internas de rlsw mediante macros
  • la declaración de API (inicialización, copia/obtención de framebuffer, draw, clear, entrada de vértices/texturas, etc.)

Funciones destacadas

• Soporta internamente varias matrices basadas en stack (exclusivas de Projection/ModelView/Texture)
• Administración de estado de renderizado: manipulación de bits de estado como Scissor, activación de textura o Depth Test
• Compatibilidad con OpenGL: diversos getters, copia de estado y manejo de errores
• Manejo de texturas: formatos sin compresión, modos de filtro/wrap, copias de memoria, etc.
• De forma predeterminada puede gestionar la mayoría de formas 2D/3D (punto, línea, triángulo, quad), así como procesamiento de color y profundidad

Valores ajustables

• Resolución y cantidad de framebuffers/texturas, bits de buffers de color/profundidad, profundidad de stack de matrices, número máximo de texturas, entre otros
• Ajustes avanzados del usuario disponibles, como el valor de SW_MAX_CLIPPED_POLYGON_VERTICES

Elementos principales de las estructuras internas

• sw_context_t: incluye todos los estados y buffers de todo el contexto
• Gestiona de forma unificada internamente vertex buffer, texture array, framebuffer, flags de estado, entre otros

Ventajas y casos de uso

• Optimizado para dispositivos sin GPU, entornos embebidos y automatización de portabilidad/pruebas/desarrollo por sistema operativo
• Posibilita ejecutar aplicaciones basadas en raylib completamente en software, incluso sin OpenGL
• La arquitectura ligera es muy conveniente para experimentación y desarrollo nuevos, así como para soporte de entornos no estándar

Licencia y contribuidores

• Redistribución flexible bajo licencia MIT
• Revisión de Le Juez Victor y Ramon Santamaria (2025–2026)

Conclusión

• rlsw es un Pure Software Renderer para raylib con compatibilidad casi completa con OpenGL
• En un solo archivo, con ligereza, escalabilidad y soporte de todos los formatos de textura de raylib, supera en baja fricción de integración y de entrada a otras soluciones gráficas por software
• Es especialmente valioso para proyectos con enfoque en gráficos de bajo nivel y portabilidad

[GN⁺]

Comentario en Hacker News

• El autor de Raylib anunció con mucha alegría que se puede compilar un programa completo de raylib usando solo una app de win32, sin dependencias externas enlace
  • Está muy interesante; estaba buscando algo que pudiera renderizar en una pantalla LED para jugar con un procesador embebido, y hasta ahora nada de lo que encontré me había convencido. Si lo entendí bien, parece que podría compilar esto y hacer renderizado por software. Para mi tamaño de unos 192x128 píxeles, debería ser lo bastante rápido en cualquier sistema, así que ya es hora de hacer unas animaciones divertidas.
  • Win32 ya tiene un renderizador por software de OpenGL 1.2 bastante decente.
  • Me pregunto por qué habría que hacer esto a propósito.
• Me da curiosidad saber qué opina Tsoding de esto.
  • Probablemente ahora que ya se volvió mainstream y hasta llegó a HN, Tsoding perderá el interés.
• Está genial que las computadoras ya sean tan rápidas que incluso con una librería OpenGL 1.1 de renderizado por software como esta se pueda hacer un juego 2D bastante decente.
  • Si mantienes baja la resolución, controlas bien la complejidad de la escena y tomas decisiones claras sobre el estilo artístico, era posible hacer un juego 3D razonable que corriera en hardware de hace 20 años. De hecho hice uno como experimento 1 2, y ahora que sé que esto es posible planeo hacer un segundo juego más “serio” y pulido. Sí se nota cuánto ha mejorado el rendimiento de las computadoras. La noticia de Raylib también está buenísima, y de hecho estoy considerando adoptarlo.
  • Edit: no me había dado cuenta de que esto era renderizado por software, pero aun así creo que mi juego también podría renderizarse si uso solo el algoritmo óptimo de ordenamiento de profundidad de sprites en CPU (es pixel art isométrico, como RollerCoaster Tycoon). En el proyecto Metropolis 1998 de los 90 tuve que usar el ancient pipeline fixed function de OpenGL (por suerte descubrí que se podían pasar campos extra al GPU como funciones de extensión desde el archivo gl.h). Estoy usando SFML como framework gráfico y supongo que probablemente está basado en OpenGL 1.x. Como ejemplo moderno, el juego Metropolis 1998 muestra lo que se puede lograr con este enfoque.
  • Creo que el renderizado por software al final sí es el futuro, pero con una condición: que puedas aprovechar agresivamente la aceleración por hardware, como en GPGPU.
  • Hace décadas ya existía Unreal Tournament completamente renderizado por software en 3D, y en 2023 todavía funciona bien enlace
• Fabrice Bellard también escribió TinyGL relacionado con OpenGL enlace
  • Lo sorprendente es que TinyGL 0.4.1 salió el 5 de marzo de 2022, y TinyGL 0.4 se lanzó originalmente el 17 de marzo de 2002. “Nuestro plan de desarrollo se extiende a lo largo de siglos”.
  • Esa persona es un modelo a seguir impresionante que prácticamente hace de todo.
  • En los 90 vi muchos renderizadores por software de este tipo y, siendo sincero, en ese tiempo no me gustaban mucho porque eran lentos, pesados o producían muchos artefactos. Para lograr buen rendimiento se necesitaba una integración muy estrecha entre el juego y el renderizador. Qué irónica es la historia.
  • Como referencia, también existe tinygl, un fork hecho por C-Chads. Se mantuvo actualizado mucho más recientemente que el original y añadió varias funciones, incluido multithreading, aunque fue archivado a finales de 2023.
• Gracias a pikuma.com descubrí la belleza de los renderizadores por software, y me siento muy orgulloso de haber podido entender la mayor parte del código.
• Al ver la descripción “OpenGL 1.1-style implementation on software”, me dio curiosidad cuántas líneas harían falta para implementar hasta OpenGL 2.0 (la versión no ES).
  • Como mínimo serían varias decenas de veces más. Lo más difícil sería implementar shaders programables por el usuario (ARB assembly/GLSL); también haría falta implementar un parser de GLSL y un intérprete de shaders. Además habría que añadir multitexturing y varios texture combiners. En general, incluso siendo muy conservador, yo diría que harían falta al menos 40 mil líneas. Claro, si no implementas toda la especificación y solo lo mínimo, podría ser menos.
  • Antes implementé una API OpenGL real para hardware fixed function; llegué hasta la versión 1.5 y apliqué algunas extensiones como framebuffer objects. La serie 1.x tiene mucha basura innecesaria, pero es fácil de implementar. La serie 2.x (con la introducción de shaders) es muy difícil de implementar en software.
  • No sé el número exacto de líneas, pero también existe PortableGL, un renderizador por software 3.x. Es un proyecto muy genial y también muy divertido de trastear.
• Sobre eso de “OpenGL-style”
  • Si lo dices viendo solo el header, felicidades: sí es una implementación por software de OpenGL 1.1 bastante buena. Claro, no cumple toda la especificación completa, pero implementa solo lo necesario para que corran juegos, como los viejos drivers MiniGL. Este proyecto hace algo parecido: implementa solo lo suficiente para que funcione el backend OpenGL de Raylib. El objetivo es poder usarlo sin dependencias gráficas externas.
• Me pregunto si soporta CUDA.
  • No, es renderizado únicamente por CPU. Ni siquiera usa SIMD; solo código directo basado en enteros y flotantes.
• Esto parece encajar perfecto con Nintendo 3DS.
  • Entonces me pregunto si también podría servir para hacer juegos para consolas como NES, SNES o Genesis.