rlsw – Renderizador OpenGL de software do Raylib com menos de 5 mil linhas de código

• rlsw é um renderizador de software no estilo OpenGL 1.1, oferecendo um backend alternativo para executar o raylib em ambientes sem GPU
• Suporta diversos modos de renderização, como ponto, linha, triângulo e quad, além de amplo suporte a clipping, textura, buffers de cor e profundidade múltiplos
• As texturas suportam todos os formatos sem compressão que o raylib suporta, e também é possível controlar de forma detalhada as configurações de filtragem e wrap
• Possui recursos gráficos 3D principais como pilha de matrizes, teste de profundidade, blend e cull face, com extrema compatibilidade obtida por meio do uso de vinculações de funções OpenGL
• Com menos de 5 mil linhas, o projeto tem vantagem de simplicidade e facilidade de integração em relação a outros renderizadores de software, em termos de desempenho e leveza

---

rlsw: Visão geral do renderizador OpenGL de software do raylib

Introdução

• rlsw é uma biblioteca de renderizador de software no estilo OpenGL 1.1 que implementa por software o conjunto completo de recursos fornecidos por rlgl.h do raylib
• Foi projetado como um backend substituto direto para permitir executar o raylib em dispositivos sem GPU

Recursos principais

• Renderização em framebuffer interno customizado, com suporte a vários modos de cor/profundidade (RGB 8, 16, 24 bits, Depth 8/16/24 bits)
• Modos de renderização suportados: ponto, linha, triângulo, quad
  • Espessura de ponto, largura de linha e configurações adicionais de modo de polígono
  • Todos os modos de renderização possuem clipping
• Recursos de textura: suporta todos os formatos não comprimidos suportados pelo raylib
  • Verificação de minificação/magnificação
  • Filtro point/bilinear
  • Aplicação granular de modos de wrap por coordenada S/T
• Suporte direto a vertex arrays, permitindo desenho de primitivas imediatamente
• Suporte a pilha de matrizes (Push/Pop)
• Outros recursos: getters no estilo OpenGL, redimensionamento de framebuffer, correção de perspectiva, recorte por scissor, teste de profundidade, blend, cull face

Uso e personalização

• Estrutura de único cabeçalho e fonte, com geração da parte de implementação via #define RLSW_IMPLEMENTATION
• Suporta personalização pelo usuário antes da compilação com múltiplas constantes de microconfiguração
  • Ex.: ajuste do máximo de framebuffers ou texturas, tamanho máximo etc.

Estrutura e tipos

• Define vários enums e tipos compatíveis com OpenGL, além de structs internas (sw_vertex_t, sw_texture_t etc.)
• Remapeia a maior parte das chamadas OpenGL para uso de funções rlsw
• Estrutura de gestão de estado interno robusta para matrizes, estados e gerenciamento de texturas

Licença e uso

• Licença MIT, permitindo uso comercial e não comercial livre, bem como criação de obras derivadas
• Como dá mais ênfase a leveza e à substituição totalmente em software do que ao desempenho, tem vantagem em integração e distribuição simplificadas

Resumo detalhado

Estrutura do cabeçalho e explicação

• rlsw substitui quase totalmente por software as funcionalidades do OpenGL 1.1
• Este cabeçalho (rlsw.h) define
  • tipos de valor, enums e structs personalizados
  • substituição de comandos OpenGL por funções internas do rlsw via macros
  • declarações de API (inicialização, cópia/obtenção de framebuffer, draw, clear, entrada de vértices/texturas etc.)

Recursos representativos

• Suporte interno a múltiplas matrizes baseadas em pilha (dedicadas a Projection/ModelView/Texture)
• Gerenciamento de estado de renderização: manipulação de bits de estado como Scissor, textura ativa ou Depth Test
• Compatibilidade com OpenGL: diversos getters, cópia de estado, tratamento de erros
• Manipulação de textura: formatos não comprimidos, modos de filtro/wrap, cópia de memória etc.
• Em modo padrão, suporta a maioria de formas 2D/3D (ponto, linha, triângulo, quad) com tratamento de cor e profundidade

Valores configuráveis

• Resolução e quantidade de framebuffers/texturas, bit depth dos buffers de cor/profundidade, profundidade da pilha de matrizes, número máximo de texturas, entre outros
• Ajustes avançados pelo usuário como o valor de SW_MAX_CLIPPED_POLYGON_VERTICES também são possíveis

Principais elementos de estruturas internas

• sw_context_t: engloba todos os estados e buffers do contexto inteiro
• Gere internamente de forma integrada vertex buffer, array de texturas, framebuffer, flags de estado etc.

Vantagens e casos de uso

• Otimizado para dispositivos sem GPU, ambientes embarcados, portabilidade por SO, testes e automação de desenvolvimento por SO
• É possível executar apps baseados em raylib em software completo, mesmo sem OpenGL
• Estrutura leve favorece bastante novos experimentos/desenvolvimento e suporte a ambientes não padrão

Licença e contribuidores

• Redistribuição flexível por licença MIT
• Revisão 2025–2026: Le Juez Victor, Ramon Santamaria

Conclusão

• rlsw é um renderizador puramente por software para raylib com compatibilidade quase total com OpenGL
• Em um único arquivo, com leveza e extensibilidade, além de suporte a todos os formatos de textura do raylib, apresenta baixa barreira de entrada e alta integrabilidade em comparação com outras soluções gráficas de software
• Possui grande valor especialmente em projetos com objetivo de gráficos de baixo nível e portabilidade

[GN⁺]

Opinião no Hacker News

• O autor do Raylib anunciou com muita empolgação que é possível compilar um programa completo em raylib usando apenas um app win32, sem dependências externas link
  • História realmente interessante; eu estava procurando algo que conseguisse renderizar alguma coisa em uma tela de LED para usar por diversão com um processador embarcado, e nada do que encontrei até agora tinha me satisfeito. Se entendi direito, parece que dá para compilar isso e fazer renderização por software; no meu tamanho de algo como 192x128 pixels, parece que seria rápido o bastante em qualquer sistema, então agora é hora de fazer umas animações divertidas
  • O Win32 já tem um renderizador OpenGL 1.2 por software bem decente
  • Fico me perguntando por que alguém iria querer fazer isso
• Queria saber a opinião do Tsoding sobre isso
  • Provavelmente agora que virou mainstream e até foi parar no HN, o Tsoding vai perder o interesse
• É legal que os computadores sejam tão rápidos que dê para fazer um jogo 2D bem decente só com esse tipo de biblioteca OpenGL 1.1 de renderização por software
  • Mantendo a resolução baixa, gerenciando a complexidade da cena com cuidado e tomando decisões firmes sobre o estilo de arte, já era possível fazer jogos 3D razoáveis que rodassem em hardware de 20 anos atrás. Eu mesmo fiz um jogo como experimento 1 2, e agora que sei que isso funciona, pretendo fazer um segundo jogo mais "sério" e polido. Dá para sentir o quanto o desempenho dos computadores melhorou, e essa novidade do Raylib também é muito bacana, a ponto de eu estar realmente considerando adotá-la
  • Edit: eu não tinha percebido que isso era renderização por software; ainda assim, parece que meu jogo também poderia ser renderizado só com um algoritmo ideal de ordenação de profundidade de sprites na CPU (é pixel art isométrica, tipo RollerCoaster Tycoon). No projeto Metropolis 1998 dos anos 90, foi preciso usar o ancientíssimo pipeline de fixed function do OpenGL (felizmente descobri no arquivo gl.h que dava para passar campos adicionais para a GPU por meio de funções de extensão). Estou usando SFML como framework gráfico e provavelmente ele é baseado em OpenGL 1.x; como exemplo mais recente, o jogo Metropolis 1998 mostra o que esse tipo de abordagem pode fazer
  • Acho que renderização por software é o futuro no fim das contas, desde que haja uma condição: poder aproveitar agressivamente aceleração por hardware, como no GPGPU
  • Décadas atrás já existia Unreal Tournament totalmente em 3D renderizado por software, e ele ainda funciona bem em 2023 link
• O Fabrice Bellard também escreveu o TinyGL relacionado a OpenGL link
  • O impressionante é que o TinyGL 0.4.1 saiu em 5 de março de 2022, enquanto o TinyGL 0.4 foi lançado pela primeira vez em 17 de março de 2002; "nosso plano de desenvolvimento se desenrola ao longo de séculos"
  • Esse cara é um modelo incrível, realmente faz quase tudo
  • Vi muitos renderizadores por software desse tipo nos anos 90, e sinceramente eu não gostava muito deles na época, porque eram lentos e pesados ou produziam muitos artefatos. Para ter desempenho, era necessário integrar jogo e renderizador de forma bem estreita; sinto uma certa ironia histórica nisso
  • Só como referência, também existe o tinygl, um fork feito pelo C-Chads, mantido até bem mais recentemente que o original e com vários recursos adicionados, como multithreading, embora tenha sido arquivado no fim de 2023
• Graças ao pikuma.com, passei a apreciar a beleza dos renderizadores por software e fiquei muito orgulhoso por conseguir entender a maior parte do código
• Ao ver a descrição "OpenGL 1.1-style implementation on software", fiquei curioso sobre quantas linhas seriam necessárias para implementar até o OpenGL 2.0 (versão não ES)
  • No mínimo seriam dezenas de vezes mais; o mais difícil é implementar shaders programáveis pelo usuário (assembly ARB/GLSL), além de exigir um parser de GLSL e um interpretador de shaders. Também seria preciso adicionar multitexturing, vários texture combiners e outras coisas. No total, mesmo chutando bem por baixo, eu diria que seriam necessárias pelo menos 40 mil linhas; claro, se não implementar toda a spec e fizer só o mínimo, talvez dê para reduzir isso
  • No passado eu realmente implementei a API OpenGL para hardware fixed function e cheguei até a versão 1.5, com parte de algumas extensões como framebuffer objects. A linha 1.x tem bastante coisa inútil, mas é fácil de implementar; já a linha 2.x (com introdução de shaders) é muito difícil de implementar em software
  • Não sei o número exato de linhas, mas existe também o PortableGL, um renderizador por software 3.x. É um projeto muito bacana e divertido de mexer
• Sobre a expressão OpenGL-style
  • Se você está dizendo isso só de bater o olho no header, parabéns: é uma implementação por software de OpenGL 1.1 bem decente. Claro, ela não segue a spec inteira, mas implementa só o necessário para os jogos rodarem, como os antigos drivers MiniGL. Este projeto também é parecido nesse sentido: implementa apenas o suficiente para o backend OpenGL do Raylib funcionar, com o objetivo de poder ser usado sem dependências gráficas externas
• Será que tem suporte a CUDA?
  • Não, é renderização só em CPU; nem SIMD usa, só código direto baseado em inteiros e ponto flutuante
• Isso parece combinar perfeitamente com o Nintendo 3DS
  • Então fico curioso se isso também poderia ser aproveitado para fazer jogos para consoles como NES, SNES e Genesis