Como o Saturn é o primeiro "console 3D" analisado para esta série, vamos primeiro ver as mudanças fundamentais de design que abriram caminho rumo à nova geração de gráficos 3D:
- A GPU agora conta com um frame buffer: Os gráficos não precisam mais ser renderizados na hora. Em vez disso, a GPU reserva uma porção da VRAM para desenhar um bitmap com toda a geometria computada que a GPU solicita, e então um codificador de vídeo capta essa região e a reproduz através do sinal de vídeo.
- Consequentemente, essa "área de trabalho" reservada permite à GPU continuar manipulando o bitmap mesmo após concluir a renderização da cena, permitindo à GPU delegar certas tarefas exaustivas como iluminação e suavização de bordas para a GPU. É aqui que o termo pipeline gráfico começa a ganhar impulso.
- Maior demanda de VRAM: O uso de um frame buffer implica um aumento de demanda por memória (o que já não é mais um grande problema); a quantidade de RAM requerida para um frame buffer é proporcional à dimensão da tela e ao número de cores utilizadas. Como exemplo, com 600 KB de VRAM, podemos armazenar um frame buffer de 640x480 pixels com 32 mil cores por pixel (16 bpp).
- E os programadores ainda ficam livres para organizar o uso da VRAM: Nem todos os bits precisam ser alocados para o frame buffer, então por que também não usá-los para o cache de texturas, para renderizar outros frame buffers ao mesmo tempo, e também adicionar umas tabelas de busca de cores para acelerar as coisas?
- A CPU incorpora operações com vetores: Uma GPU com capacidades 3D estaria incompleta sem uma CPU capaz de alimentá-la com a geometria necessária. Por esse motivo, CPUs da próxima geração incluem um tipo de instrução especializada que acelera o cálculo de vetores. São conhecidas como extensões Single instruction, multiple data, ou "SIMD".
- No caso do Saturn, a operação de vetores é acelerada pela Saturn Control Unit (e não pelas CPUs SH-2).
A Oferta da Sega
O console inclui duas GPUs proprietárias, cada uma servindo a diferentes propósitos ao trabalhar simultaneamente. Alguém pode argumentar que as novas GPUs são uma evolução do clássico VDP, enquanto outros podem dizer que é uma total reformulação... Eu acho que é um pouco de cada.
Com isso dito, vamos dar uma olhada nos dois chips.
VDP1
Arquitetura do VDP1.
O Video Display Processor 1 (VDP1) é um chip que desenha sprites com transformações geométricas . Os resultados são gravados num frame buffer, o qual em resposta é transmitido para o VDP2 para exibição.
O chip é programado através do envio de "comandos de desenho". Assim sendo, os programadores têm 512 KB de RAM dedicada para guardar esses comandos de desenho e os materiais requeridos (texturas/blocos, tabelas de cores, etc).
Por consequência, o VDP1 foi construído para usar quadriláteros como primitivas, o que significa que ele pode apenas compor modelos usando polígonos (sprites) de 4 vértices. O chip aplica Forward Texture Mapping parta conectar pontos da textura no quadrilátero. Ele não vem com nenhuma técnica de filtro/interpolação, então os cálculos ficam sujeitos a aliasing.
O VDP1 também proporciona esta seleção de efeitos:
- Dois algoritmos de sombreamento (Plano e Gouraud) para iluminação.
- Anti-aliasing: Nesse caso, ele duplica pixels para cobrir espaços vazios durante o mapeamento.
- Clipping para descartar polígonos fora do campo de visão da câmera.
- Transparência para mesclar dois bitmaps não opacos.
Dois chips de frame buffer de 256 KB estão disponíveis para desenhar, ao mesmo tempo, novas cenas do jogo, sem quebrar a que estiver sendo exibida. Quando o buffer secundário termina de ser desenhado, o VDP1 começa a transmitir o segundo no lugar (page-flipping), e o ciclo continua.
VDP2
Arquitetura do VDP2.
O Video Display Processor 2 (VDP2) se especializa em renderizar planos grandes (4096×4096 pixels) com transformações (rotação, escala e translação) aplicadas aos mesmos .
Mais importante, o VDP2 renderiza na hora (sem frame buffer) tal como as engines baseadas em tiles anteriores. Ele pode exibir até 16.7 milhões de cores (24 bits). Este chip é também responsável pela exibição do buffer do VDP1, que também pode ser transformado e/ou misturado com as camadas do VDP2. O "frame" do VDP é composto de até quatro planos 2D e um plano 3D; ou dois planos 3D.
Esse chip utiliza tile-maps para compor planos, e faz a correção de perspectiva para o mapeamento de texturas 3D. Esse é um método mais sofisticado, que leva em conta o valor de profundidade para computar rotações.
Os efeitos disponíveis incluem multi-texturação (mapeamento de mais de uma textura por polígono) e sombreamento. Com este último, após receber sprites gerados pelo VDP1, o VDP2 consegue reduzir o brilho deles e mesclá-los com meia-transparência. Porém o VDP2 recebe apenas um fluxo de sprites do VDP1 (no mesmo passo do raio da CRT), então essa função tende a ser complicada de codificar e operar.
Esse chip também abriga 4 KB de RAM de cores (CRAM), que é usada para traduzir os valores customizados de cor do VDP1 (cores de índice) para cores RGB de 24 bits.
Por fim, ainda que o VDP2 seja limitado a dois planos 3D, nada impede a CPU de usar a VRAM dele como uma área de frame buffer para desenhar gráficos 2D ou 3D adicionais em software.
Eu recomendo dar uma olhada nas fontes (ao fim do artigo) caso essa seção tenha chamado sua atenção, já que os VDPs têm muitas outras peculiaridades que estão além do escopo desse artigo.
Definindo o problema
Como você pode ver, a arquitetura do subsistema gráfico é bem complexa, e portanto é interpretada de forma diferente a depender da necessidade:
Como um poderoso console 2D
As capacidades do Saturn em desenhar cenas em 2D eram imensas comparadas com as do Mega Drive e do SNES, ainda que não fossem o principal atrativo comercial do console.
Sprites
Mega Man X4 (1997).
Plano de sprites do VDP1.
Nesse caso, o VDP1 tem a tarefa de traçar sprites tradicionais sem aplicar qualquer distorção 3D.
A CPU configura o VDP1 gravando por cima de seus registradores e preenchendo sua VRAM com comandos e tiles. O processo também pode ser acelerado graças ao controlador DMA.
Backgrounds (Planos de fundo)
Plano 2D 1.
Plano 2D 2.
Plano 2D 3.
O VDP2 é então instruído a desenhar os planos de fundo. Esses, junto com a camada de sprites, são automaticamente mesclados para formar uma cena totalmente colorida.
A parte de comando é fundamentalmente similar à do VDP1: Os programadores têm os registradores e a VRAM para configurar como precisarem.
Algumas funções do VDP2 podem ser exploradas para a criação de cenários mais realísticos, tal como o redimensionamento usado para simular uma onda de calor (ver "plano 2D 2").
Resultado
Mega Man X4 (1997). Os planos mesclados (Tadaaa!).
Não tem muito mistério aqui: o VDP2 é o responsável pelo último passo, que é enviar o sinal processado para o codificador de vídeo.
O VDP2 opera em sincronia com o raio do CRT, o que quer dizer que suas computações correspondem aos pixels que serão exibidos na próxima scanline.
Como um console 3D desafiador
Aqui é onde o Saturn brilhou e sofreu ao mesmo tempo. Ainda que esse console tivesse oito processadores para se explorar, no fim tudo era uma questão de:
- Se os programadores seriam capazes de dominar a maior parte dos recursos do console num curto espaço de tempo (lembrando que a vida comercial do console chegaria ao fim assim que seu sucessor fosse lançado, ou sequer anunciado).
- Se o tempo disponível até o lançamento do jogo seria razoável.
Por esse motivo, a maior parte dos jogos acabava variando drasticamente de qualidade, já que cada estúdio trazia sua solução individual.
Modelagem 3D
Virtua Fighter Remix (1995).
Modelos 3D dos personagens, sem texturas nem fundo. Repare nas primitivas usadas na construção dos modelos.
Até agora haviam sido usados quadriláteros individuais regulares para formar sprites e/ou planos de fundo. Mas e se agruparmos múltiplas primitivas irregulares e as ordenarmos para formar uma figura mais complexa? É assim que surgem os modelos 3D.
Simplificando, consoles 2D clássicos como o Super Nintendo organizam seus gráficos (fundos e sprites) em áreas mais ou menos retangulares. Em alguns casos, tais como o do Mode 7, os programadores podem providenciar uma matriz de rotação para aplicar transformações sobre algumas dessas áreas. O Saturn, pelo contrário, permite a definição de quadriláteros de 4 pontos com ângulos arbitrários entre suas bordas (a Sega chama isso de "sprites distorcidos"). Então, as capacidades de mapeamento de texturas do VDP pinta a área do quadrilátero com uma textura, esta sendo escalada de acordo com a forma do polígono.
Quanto às operações de que um jogo 3D necessita, as CPUs e a SCU recebem a função de formular um mundo 3D e projetá-lo num espaço 2D. Daí, ambas as VDPs recebem o comando para renderizá-lo, aplicar efeitos e finalmente transmiti-lo para a TV.
Processamento de pixels
Virtua Fighter Remix (1995).
Cena renderizada com modelos 3D e planos de fundo.
Qualquer um dos VDPs pode desenhar esse novo espaço (projetado em) 3D e estampá-lo com texturas e efeitos. Agora, qual chip fica "encarregado" disso varia de jogo para jogo.
Certos jogos usavam o VDP1 prioritariamente para desenhar os polígonos mais próximos, deixando o VDP2 para o processamento de cenários mais distantes. Outros encontravam curiosas soluções para encarregar o VDP2 de desenhar polígonos mais próximos (portanto aliviando a carga de geometria do VDP1). O desafio está em projetar um mecanismo eficiente que possa exibir gráficos impressionantes enquanto mantém uma framerate aceitável.
Os novos designs
Estes são alguns exemplos de personagens que foram redesenhados para o console. Os modelos são interativos, tente mexer com eles!
Modelo interativo disponível na edição moderna
Sonic em Sonic R (1997).
185 quadriláteros.
Modelo interativo disponível na edição moderna
Tails em Sonic R (1997).
254 quadriláteros.
Ainda que o Saturn só seja capaz de desenhar quadrângulos, você logo percebe que esses modelos exibem dois triângulos ao invés de um único quadrângulo no modo "wireframe". Isso porque o formato usado para codificar esse modelo (gITF, um padrão aberto de modelagem 3D moderna), de forma que seu dispositivo moderno possa renderizá-lo, não tem suporte a quadrângulos até o momento em que esse texto foi escrito. Recomendo mudar para o modo "surface" para observar os quadrângulos.
De certa forma, isso demonstra o quão difícil é para a tecnologia gráfica atual reproduzir seus predecessores de 30 anos atrás!
Uma introdução ao problema da visibilidade
Quando polígonos 3D são projetados num espaço 2D, é crucial determinar quais polígonos são visíveis da posição da câmera e quais ficam ocultos no plano de trás . Senão os modelos não são desenhados corretamente, efeitos como transparência parecerão "quebrados" e, principalmente, recursos de hardware são desperdiçados. Esse processo é mais conhecido como Visible surface determination (determinação de superfície visível) ou "VSD", e é um problema fundamental no mundo dos gráficos computadorizados. Há múltiplos documentos publicados que descrevem algoritmos de abordagem a esse problema em diferentes estágios do pipeline gráfico. Alguns dão resultados bastante precisos, e outros trocam essa precisão por uma melhor performance.
Diferente de equipamento acadêmico/profissional, o hardware do consumidor é incrivelmente limitado, portanto a escolha do algoritmo fica reduzida a apenas alguns... Ou até mesmo nenhum.
Project Z-Treme (2019, Homebrew) .
Essa engine abandonou o Z-sort em troca de particionamento binário de espaço (BSP), corrigindo os glitches.
O método do Sega Saturn é o que considero um caso "meio resolvido". O VDP1 não implementa nenhuma função VSD: Ou você entrega a geometria a ele na ordem correta, ou recebe dele uma bagunça. Entretanto, a Sega tinha uma biblioteca gráfica chamada "SGL", que implementava uma solução chamada Z-sort ou Algoritmo do Pintor o qual faz a ordenação dos polígonos via software.
Essencialmente, o SGL aloca um buffer para ordenar os polígonos baseando-se na distância deles da câmera (do mais distante ao mais próximo), então envia os comandos de exibição para o VDP1 nessa ordem.
Um dos problemas do Z-sort com espaços 3D é que o seu valor de distância (Z-order) é aproximado, então podem haver glitches visuais. Por causa disso, os desenvolvedores podiam deixar o SGL pra lá e implementar seus próprios algoritmos.
Em artigos mais para a frente, você verá abordagens alternativas. Algumas ainda dependem de software, enquanto outras são aceleradas via hardware.
A questão da transparência
O Sega Saturn é capaz de desenhar gráficos semitransparentes, isto é, de misturar camadas sobrepostas de cores (blending) para criar a ilusão de que podemos ver através delas. Infelizmente, os VDPs não são tão coordenados como se esperaria, então esse efeito não funciona direito quando as camadas estão em VDPs diferentes.
Como alternativa, os jogos podem ativar a propriedade "mesh" numa textura. Com texturas em mesh, o VDP1 define as coordenadas X/Y da textura como "transparentes" (vazias). Isso torna possível misturar outras camadas usando os pixels transparentes. Curiosamente, o mesh aparecia borrado se o console estivesse conectado à TV usando o sinal de vídeo composto (o que era o padrão de antigamente, além do RF), o que resultava numa maneira acidental, porém efetiva de atingir a semitransparência .
Como você deve suspeitar, isso não era viável em alguns jogos. No fim das contas, esses não tinham opção além de deixar para lá a semitransparência. Alguns estúdios acharam métodos engenhosos, agora dê uma olhada nesses dois casos:
Video - Daytona, da Sega (1993).
Video - Sonic R, da Traveller's Tales (1997).
Além do meu terrível gameplay, você irá reparar que o plano de fundo do primeiro jogo brota do nada (sem semitransparência), enquanto o segundo jogo não apenas conseguiu a semitransparência como também um efeito de fading: A Traveller's Tales encontrou uma solução ao mudar os registros da "taxa de mistura" do VDP2 (usados para definir o canal alpha da textura), combinando isso com uma mudança nos níveis de iluminação à medida que o personagem se aproxima .