Introdução

Recentemente, vi uma postagem numa rede social com uma pessoa comparando o jogo Half-Life na sua versão renderizada por software e na sua versão por OpenGL, argumentando que “Deveríamos voltar ao software renderer”. O post ganhou certa tração, com várias pessoas concordando, num viés um tanto saudosista e claramente iniciou um debate entre jogadores que, em sua maioria, não sabiam o que eles estavam falando.

Talvez você nem saiba do que essas pessoas estejam falando, então deixe eu dar um contexto. Software renderer (ou renderização por software) é uma técnica para gerar gráficos muito utilizada nos anos 90 em computadores pessoais — embora seja utilizada até hoje em diversos casos. Jogos clássicos que utilizavam renderização por software são Doom, Quake, Wolfenstein 3D, Duke Nukem 3D. Por conta disso, o software renderer é associado a essa estética de jogos 3d dos anos 90, como baixa resolução, texturas “pixeladas” e baixa fidelidade visual.

Imagem do jogo Doom de 1993.

O que eu quero discutir nesse post é sobre como isso é um mero fetiche técnico — algo comum da comunidade gamer — que confunde impacto visual e estética com técnica. Mas, para isso, eu preciso explicar o que é um software renderer e como ele funciona.

O que é um software renderer?

Você provavelmente já ouviu falar em pixels e resolução. Pixel — do inglês picture element — é a menor unidade de uma imagem digital, cada um contendo uma única cor sólida. Uma imagem é composta por milhares de pixels e a resolução dita a quantidade de pixels nessa imagem. O meu notebook, por exemplo, tem uma tela de resolução de 1920 por 1080 pixels; isso significa que nele há 1920x1080 pixels, ou 1920 pixels na horizontal e 1080 pixels na vertical.

Os dados da imagem que aparece em um monitor são armazenados na memória em um framebuffer como dados sequenciais. Ou seja, imagine uma lista de números, onde o primeiro número representa a cor do primeiro pixel da tela, onde o segundo número representa a cor do segundo pixel da tela etc. Para enviar uma imagem na tela, é preciso escrever um número equivalente a uma cor para cada pixel da tela nessa lista de números.

A renderização por software consiste em usar o processador (CPU) do computador — uma unidade do computador de propósito geral, responsável por realizar cálculos matemáticos, ler e escrever dados na memória — para calcular e escrever o valor de cada pixel.

Como a CPU é uma unidade de propósito geral, ela é muito poderosa. Você pode fazer praticamente qualquer cálculo matemático para calcular a cor do pixel, como multiplicações de matrizes, exponenciais, derivadas, o que for. A desvantagem, ironicamente, é porque ela é de propósito geral. Ela não é usada só para gerar imagens; ela também é usada para processar dados de física do jogo, dados de lógica, leitura de dados do jogo do disco rígido etc. Cada ciclo da CPU gasto em renderização é tempo a menos gasto na lógica e na física do jogo.

Isso não era um problema em animações ou imagens, já que essas não eram visualizadas em tempo real, eram renderizadas por horas ou até dias na CPU e depois transformadas em imagens ou vídeos. Tanto que, nos anos 90, computadores conseguiam fazer imagens realistas usando Raytracing — a mesma técnica que “ficou famosa” devido às placas RTX — mas demorando horas.

Todavia, em jogos isso era um problema. Os jogos tinham que renderizar uma imagem em tempo real e processar dados de física e de lógica. Por conta disso, a renderização era drasticamente simplificada para que pudesse ocorrer em tempo real. Um exemplo é Wolfenstein 3D: um dos primeiros jogos em primeira pessoa que era bastante rudimentar, não possuindo texturas no teto e tendo paredes todas de mesma altura.

Imagem do jogo Wolfenstein 3D.

Os processadores foram evoluindo, surgiram técnicas mais otimizadas para renderização de gráficos 3d e foi assim que surgiram jogos como Doom, Duke Nukem e Quake — este último sendo o mais impressionante na época. Eles tinham limitações claras: resoluções baixas (para conseguir renderizar em tempo real), texturas com paleta de cores limitadas (diminuir uso de memória e facilitar cálculos de iluminação), texturas “pixeladas” (a CPU não conseguia fazer uma “suavização” da textura, por isso ela ficava com um aspecto de pixel art) e vértices “tremendo” (falta de precisão porque usar números racionais para cálculos era caro).

Todo esse visual ficou associado com “software renderer”, mas veja: nem todo software renderer era assim, isso era apenas uma limitação de renderizadores por software em tempo real da época. Esse é um dos primeiros “mitos” a ser quebrado: de que a técnica renderização por software tinha a ver com esse visual que eu descrevi.

O surgimento das placas de vídeo

Por mais que tanto técnicas de renderização quanto CPUs avançassem, ainda existia um problema claro: era irracional gastar grande parte do tempo de processamento da CPU simplesmente calculando cores de pixels, ainda mais quando os jogos ficavam cada vez mais complexos. Para isso, foram criadas as primeiras Graphical Processing Unit (GPU), que eram hardwares especializados em rasterização (transformação de triângulos em pixels). Assim, a renderização por GPU é chamada de Hardware Rendering (Renderização por Hardware) ou renderização acelerada por hardware.

Por serem um hardware especializado, as GPUs conseguiam desenhar triângulos de forma muito mais rápida que a CPU. As primeiras GPUs tinham hardware especificamente para cálculos de aplicação de texturas, transformações em três dimensões, iluminação etc. E, como vantagem, ainda deixavam a CPU livre para poder fazer cálculos de física e de lógica do jogo.

O principal problema, no início, é que a GPU era uma máquina “burra”. Ao contrário da CPU, que você tinha controle total sobre a cor de cada pixel, nas primeiras GPUs você tinha controle só sobre alguns parâmetros, como textura, iluminação, posições de vértices, transformações aplicadas aos vértices etc. Então, se você queria algum efeito especial que precisasse ser calculado por pixel, na GPU não era possível, enquanto na CPU era trivial.

Voltando ao exemplo do início, temos o jogo Half-Life, que possuía opções de ser jogado tanto com um renderizador por software quanto por OpenGL (uma camada de abstração para GPU). Um dos efeitos notáveis era a diferença na renderização de água, justamente porque na CPU (renderização por software), havia um controle maior da aplicação de textura por pixel, o que levava a efeitos que não podiam ser reproduzidos em GPUs da época. O vídeo seguinte ilustra bem essa diferença:

Superando as limitações da GPU

Obviamente, os programadores logo sentiram as limitações dessas primeiras GPUs. Eles queriam a dinamicidade do software renderer, essa possibilidade de programar especificamente a cor de cada pixel, mas com a velocidade da GPU. Foi assim que surgiram GPUs com pipeline programável, em que você podia programar cada etapa da GPU, através de shaders (programas que rodavam na GPU).

Por exemplo, na vertex shader, você pode programar como cada vértice de um triângulo será transformado para a imagem final, utilizando multiplicações de matrizes diversas e tudo mais. Você pode até calcular alguns efeitos de iluminação (gouraud shading) já nessa etapa. Você tinha flexibilidade total para programar como seria transformado o vértice de cada triângulo da cena.

A fragment shader talvez seja a verdadeira transformação. Ela permite que você programe como a GPU vai computar a cor de cada pixel! Finalmente voltamos a etapa inicial de renderização por software. Você tem de novo a flexibilidade para fazer qualquer coisa que a CPU fazia, mas de forma muito mais rápida e eficiente. Por exemplo, você pode gerar texturas a partir de funções matemáticas, pode deformar texturas, escolher diversas formas de interpolação, modificar as cores da textura, calcular a iluminação por pixel entre muitas outras coisas.

Ou seja, note que agora as “vantagens” de renderização por software, no caso de jogos, acabaram. Uma GPU consegue replicar os mesmos efeitos de um renderizador antigo; só que com muito mais velocidade, muito mais eficiência energética, menos necessidade de otimizações malucas e sem ocupar o tempo precioso de processamento da CPU com cálculo de cor de pixels.

E a volta do software renderer?

Esteticamente, jogos como Doom, Quake, Duke Nukem 3d são muito válidos. Eles criaram uma identidade única que transcendem suas “limitações técnicas” e viraram hoje em dia ícones próprios. Eu mesmo sou um grande fã de Quake e Doom e até hoje os jogo com frequência. Entretanto, embora a técnica da época tenha influenciado a estética, a estética criada por eles já não depende mais da técnica original.

É possível fazer um jogo com baixa resolução, triângulos que tremem e texturas pixeladas completamente com uma GPU moderna, rodando muito mais rápido e com mais eficiência. Como eu expliquei, a GPU é completamente programável, a ponto de ser possível imitar perfeitamente o visual desses jogos antigos.

Aqui, não importa se a cor do pixel foi calculada na GPU em uma fragment shader ou na CPU com milhares de otimizações bizarras e paleta de cores limitadas. O que importa na arte é a sensação. Qual a sensação que esse visual nos traz?

É uma situação parecida com a fetichização recente de “efeitos práticos” no cinema — como se um filme fosse automaticamente melhor por ter explodido um avião em vez de ter feito a explosão em 3d. A guinada para CGI (gráficos gerados por computador) em filmes recentes trouxe muita gente “nostálgica” que começa a fetichizar “efeitos práticos” como se fossem inerentemente melhores, sendo que esteticamente importa como a técnica é usada e não qual técnica é usada. Se o impacto é o mesmo, pouco importa como aquela cena foi filmada.

Esse fetiche técnico vem muito por um público gamer que não tem vocabulário para discutir videogame enquanto arte (embora defenda esse ponto de vista). Historicamente, a crítica e o marketing focou muito na técnica, numa fidelidade visual e em usar a “técnica” para validar a estética. Por isso que os consoles eram vendidos a partir de seus números de “bits”, o Super Nintendo pelo seu Mode 7, o Mega Drive pelo seu Blast Processing etc.

O problema é continuar com esse discurso que confunde técnica com estética. Sim, estudar sobre software renderers é algo excelente, muito legal, tanto que eu dediquei esse post inteiro a isso e eu mesmo sou um programador escritor de software renderers. Mas, isso é uma discussão para entusiastas, programadores, engenheiros, assim como a discussão de efeito prático versus CGI é uma discussão de diretores e cinematografistas. Ambas as discussões não são discussões sobre a estética do filme ou jogo no espectador ou jogador.

Conclusão

Voltando ao post que motivou esse texto: a pessoa não queria um software renderer, ela queria a estética causada por esse software renderer. Ela só não tinha vocabulário para descrever isso. Dá para ter essa mesma estética sem o custo técnico de fritar sua CPU fazendo ela renderizar algo em 1920x1080 a 165 FPS.

Sinceramente, é um pouco frustrante que uma pessoa faz um post numa rede social sem pensar e com um fetichismo técnico absurdo só para eu ter que vir aqui e escrever um artigo inteiro explicando como GPU e renderização por software funciona para poder mostrar como isso é uma grande baboseira.

Eu tenho minha “guerra pessoal contra o gamer” aqui, já é quase uma série desse blog. Caso você queira conferir e ler um pouco mais dos meus pensamentos, eu gosto bastante desses meus outros dois textos:

• Remake e a morte do real: eu discuto nesse texto sobre forma e conteúdo e como “remakes” muitas vezes apagam as ideias dos jogos originais, como se os jogos originais fossem “versões imperfeitas” e não completas em si mesmas. Também falei um pouco do fetichismo gamer em torno de tecnologia.
• Quake e a falsa nostalgia: eu discuto nesse texto sobre a experiência falsa que “boomers shooters” dizem recriar, que embora seja válida, muitas vezes apaga a memória e o que os clássicos de FPS dos anos 90 realmente representavam.

Última modificação em 2026-06-29