Dado que el Saturn es la primera 'consola 3D' que analizamos en esta serie, repasemos primero los cambios fundamentales de diseño que allanaron el camino a la nueva generación de gráficos 3D.
Metodologías revisadas
En primer lugar, la GPU trabaja ahora con un frame buffer: ya no es necesario renderizar los gráficos al vuelo. En su lugar, la GPU reserva una porción de VRAM para dibujar un bitmap con toda la geometría computada que le solicita la CPU. Un codificador de vídeo recoge luego esa región y la emite a través de la señal de vídeo. A decir verdad, el Saturn combina ambos modelos... esto lo explico más adelante.
En consecuencia, disponer de este 'espacio de trabajo' reservado permite a la GPU seguir manipulando el bitmap incluso después de renderizar la escena. Esto posibilita que la CPU le delegue tareas adicionales de gran carga computacional (como iluminación y antialiasing), y es aquí donde el concepto de pipeline gráfico empieza a cobrar protagonismo.
En segundo lugar, se precisa más VRAM: el uso de un frame buffer aumenta los requisitos de memoria (algo que ya no supone un problema grave). La cantidad de RAM necesaria para un frame buffer es proporcional a las dimensiones de la pantalla y al número de colores utilizados (a.k.a. colour depth). Por ejemplo, 600 KB de VRAM pueden albergar un frame buffer de 640×480 píxeles con 32k colores (16 bits por píxel).
Además, los programadores tienen libertad para organizar el uso de la VRAM: no todos los bits tienen que destinarse al frame buffer. ¿Por qué no usarla también para cachear texturas, renderizar otros frame buffers de forma simultánea y añadir tablas de consulta de color para agilizar las operaciones?
Por último, la CPU incorpora operaciones vectoriales: una GPU con capacidades 3D no estaría completa sin una CPU capaz de suministrarle la geometría necesaria. Por eso, las CPU de siguiente generación incorporan algún tipo de instrucciones especializadas que aceleran los cálculos vectoriales, conocidas como extensiones de Una Instrucción, Múltiples Datos (SIMD, del inglés Single Instruction Multiple Data). No obstante, su diseño dista mucho de estar estandarizado en la industria.
En el caso del Saturn, las operaciones vectoriales las acelera la Saturn Control Unit, no las CPU SH-2.
La propuesta de Sega
Esta consola incluye dos GPU propietarias: la VDP1 y la VDP2. Cada una cumple una función distinta mientras opera de forma simultánea. Algunos podrían afirmar que las nuevas GPU son una evolución del VDP clásico, mientras que otros consideran que se trata de un rediseño completo... Creo que es un poco de ambas cosas.
Dicho esto, veamos los dos chips.
VDP1
Arquitectura del VDP1.
El Video Display Processor 1 (VDP1) es un chip que dibuja sprites con transformaciones geométricas . Los resultados se escriben en un frame buffer que, a continuación, se transmite al VDP2 para su visualización.
Este chip se programa mediante comandos de dibujo. Así, los programadores disponen de 512 KB de RAM dedicada para almacenar estos comandos junto con los materiales necesarios para procesarlos (texturas/tiles, tablas de consulta de color, etc.).
En consecuencia, el VDP1 está diseñado para utilizar cuadriláteros como primitivas, lo que significa que solo puede componer modelos con polígonos de cuatro vértices (sprites). El chip aplica Forward Texture Mapping para proyectar los puntos de textura sobre el cuadrilátero en esa dirección. No incorpora técnicas de filtrado ni interpolación, por lo que el renderizado está sujeto a aliasing.
El VDP1 también ofrece estos efectos:
- Dos algoritmos de sombreado (plano y Gouraud) para la iluminación.
- Antialiasing: en este caso, duplica píxeles para cubrir los huecos que aparecen durante el texture mapping.
- Clipping para descartar polígonos fuera del campo de visión de la cámara.
- Transparencia para mezclar dos bitmaps no opacos.
Se dispone de dos chips de frame buffer de 256 KB para dibujar nuevas escenas del juego de forma simultánea sin interrumpir la que se está mostrando en ese momento. Cuando el buffer secundario termina de dibujarse, el VDP1 pasa a emitir ese y el ciclo se repite. Esta técnica se denomina page flipping.
VDP2
Arquitectura del VDP2.
El Video Display Processor 2 (VDP2) se especializa en renderizar planos de gran tamaño (hasta 4096×4096 píxeles) con transformaciones aplicadas (rotación, escala y traslación) .
Y lo más importante: el VDP2 renderiza al vuelo (sin frame buffer), de manera muy similar a los motores basados en tiles anteriores. Admite hasta 16,7 millones de colores (24 bits).
Este chip también se encarga de mostrar el buffer de salida del VDP1, que puede a su vez transformarse y mezclarse con las capas del VDP2. El 'fotograma' del VDP2 consta de hasta cuatro planos 2D y un plano 3D, o bien solo dos planos 3D.
Este chip recurre a tile-maps para componer los planos y aplica perspective correction para el texture mapping 3D. Este es un enfoque más sofisticado que tiene en cuenta el valor de profundidad al calcular las rotaciones.
Los efectos disponibles incluyen:
- Multitexturizado para proyectar más de una textura sobre un único polígono.
- Sombreado: tras recibir los sprites generados por el VDP1, el VDP2 puede reducir su brillo y mezclarlos con semitransparencia.
- No obstante, el VDP2 solo recibe un flujo de sprites del VDP1 (al ritmo del haz CRT), por lo que esta función tiende a ser complicada de codificar y gestionar.
Este chip también alberga 4 KB de Colour RAM (CRAM), que se utiliza para convertir los valores de color personalizados del VDP1 (colores indexados) en colores RGB de 24 bits.
Por último, aunque el VDP2 tiene un límite de dos planos 3D, nada impide a la CPU usar su VRAM como frame buffer por software para renderizar gráficos 2D o 3D adicionales.
Si esta sección ha despertado tu interés, te recomiendo consultar las fuentes al final del artículo: los VDP tienen muchas más particularidades interesantes que escapan al ámbito de este análisis.
Definiendo el problema
Como puedes ver, la arquitectura del subsistema gráfico es bastante compleja, y su interpretación varía con frecuencia según las necesidades:
Como una potente consola 2D
Las capacidades del Saturn para dibujar escenas en 2D eran vastas comparadas con las de la Mega Drive o la SNES, aunque no eran el principal argumento de venta de la consola.
Para una demostración rápida, usaré Mega Man X4 (1997) como ejemplo.
Sprites
El plano de sprites del VDP1.
En este caso, el VDP1 tiene la tarea de dibujar sprites tradicionales sin aplicar ninguna distorsión 3D.
La CPU configura el VDP1 escribiendo en sus registros y cargando la VRAM con comandos y tiles. El proceso también puede acelerarse mediante el controlador DMA.
Fondos
Plano 2D 1.
Plano 2D 2.
Plano 2D 3.
A continuación, el VDP2 recibe instrucciones para dibujar los planos de fondo. Estos, junto con la capa de sprites, se componen automáticamente para formar una escena con todo su color.
La parte de configuración es fundamentalmente similar a la del VDP1: los programadores tienen acceso a registros y VRAM para configurar el chip de la manera adecuada.
Ciertas funciones del VDP2 pueden aprovecharse para crear escenarios más realistas, como efectos de escala para simular la distorsión por calor, tal como se aprecia en el 'Plano 2D 2' .
Resultado
Planos mezclados (¡Tachán!).
Sin mucho misterio, el VDP2 se encarga del último paso: transmitir la señal procesada al codificador de vídeo.
El VDP2 opera en sincronía con el haz CRT, lo que significa que sus cálculos en curso corresponden a los píxeles que están a punto de aparecer en la siguiente línea de escaneo.
Como una consola 3D exigente
Aquí es donde el Saturn brilló y tuvo dificultades a partes iguales. Aunque contaba con ocho procesadores para sacar partido, todo se reducía en última instancia a:
- Si los programadores serían capaces de dominar la mayor parte de las características de la consola en un plazo reducido (recordemos que la vida comercial de la consola acabaría en cuanto se lanzara su sucesora, o incluso cuando se anunciara).
- Si su juego podría salir en un plazo razonable.
Por eso, la calidad de los juegos variaba enormemente de un título a otro, con cada estudio desarrollando enfoques únicos.
Modelado 3D
Modelos 3D de personajes sin texturas ni fondo. Observa las primitivas usadas para construir los modelos.
Virtua Fighter Remix (1995).
Hasta ahora, los ejemplos anteriores usaban cuadriláteros regulares individuales para formar sprites o capas de fondo. Pero ¿qué ocurre si agrupamos múltiples primitivas irregulares y las disponemos para formar una figura más compleja? Así es como cobran vida los modelos 3D.
En términos sencillos, las consolas 2D clásicas como la Super Nintendo organizan sus gráficos (fondos y sprites) en áreas cuasirectangulares. En algunos casos, como con el Modo 7, los programadores pueden aportar una matriz de rotación para aplicar transformaciones a algunas de esas áreas. El Saturn, en cambio, permite a los desarrolladores definir cuadriláteros de cuatro vértices con ángulos arbitrarios entre sus aristas; Sega los denomina sprites distorsionados. Luego, las capacidades de texture mapping de los VDP recubren el área del cuadrilátero con una textura que se escala para adaptarse a la forma del polígono.
En cuanto a las operaciones requeridas en un juego 3D, las CPU y la SCU tienen la tarea de formular un mundo 3D y proyectarlo en un espacio 2D. Después, ambos VDP reciben instrucciones para renderizarlo, aplicar efectos y, finalmente, emitirlo al televisor.
Procesado de píxeles
Escena renderizada con modelos 3D y fondos.
Virtua Fighter Remix (1995).
Cualquiera de los VDP puede dibujar el nuevo espacio 3D proyectado y aplicar texturas y efectos. Sin embargo, cuál de los dos está 'al mando' varía de un juego a otro.
Algunos desarrolladores priorizaban el VDP1 para renderizar los polígonos cercanos, dejando al VDP2 que gestionase el escenario lejano. Otros idearon ingeniosas soluciones alternativas que permitían al VDP2 dibujar polígonos más próximos (reduciendo así la cantidad de geometría enviada al VDP1). El desafío central reside en diseñar un motor eficiente capaz de mostrar gráficos impresionantes manteniendo a la vez una tasa de fotogramas aceptable.
Los nuevos diseños
Estos son algunos ejemplos de personajes rediseñados específicamente para esta consola. Inicialmente construí un visor de modelos interactivo para la edición web y, posteriormente, adapté las visualizaciones para los formatos físicos.
Modelo interactivo disponible en la edición moderna
Sonic en Sonic R (1997).
185 cuadriláteros.
Modelo interactivo disponible en la edición moderna
Tails en Sonic R (1997).
254 cuadriláteros.
Aunque el Saturn solo puede dibujar cuadrangulares, la vista Wireframe muestra dos triángulos en lugar de un único cuadrangular. Esto se debe a que el formato moderno utilizado para codificar este modelo —glTF, un estándar abierto para el modelado 3D contemporáneo que permite a los dispositivos actuales seguir renderizándolo— no admite cuadrangulares en el momento de redactar este artículo. Este comportamiento no se aprecia en la vista de superficie.
En cierto modo, esto pone de manifiesto lo difícil que puede resultar para la tecnología gráfica moderna emular fielmente a sus predecesoras de hace ~30 años.
Una introducción al problema de visibilidad
Cuando los polígonos 3D se proyectan en un espacio 2D, es fundamental determinar qué polígonos son visibles desde la perspectiva de la cámara y cuáles quedan ocultos detrás . De lo contrario, los modelos no se dibujan correctamente, efectos como la transparencia aparecen rotos y los recursos de hardware se malgastan.
Este proceso se conoce ampliamente como Determinación de Superficie Visible (VSD, del inglés Visible Surface Determination), y es un reto fundamental en el campo de la informática gráfica. Numerosas publicaciones describen algoritmos que abordan este problema en distintas etapas del pipeline gráfico; algunos ofrecen resultados de gran precisión, mientras que otros sacrifican exactitud en aras de un mejor rendimiento.
Ahora bien, a diferencia del equipamiento académico o profesional, el hardware doméstico está muy limitado, lo que significa que la elección de algoritmo a menudo se reduce a muy pocas opciones... o ninguna en absoluto.
Project Z-Treme , un motor homebrew de 2019. Abandonó el Z-sort en favor de un enfoque de Particionado de Espacio Binario (BSP, del inglés Binary Space Partitioning), corrigiendo numerosos fallos visuales.
El enfoque del Sega Saturn es lo que yo consideraría un caso semirresuelto. El VDP1 no implementa ninguna funcionalidad VSD: o bien se suministra la geometría en el orden correcto, o el resultado es un caos. Sin embargo, Sega proporcionó una biblioteca de gráficos llamada 'SGL' que implementa una solución denominada Z-sort o algoritmo del pintor . Esta realiza el ordenamiento de polígonos por software.
En esencia, SGL reserva un buffer para ordenar los polígonos según su distancia a la cámara (del más lejano al más cercano). Después, emite los comandos de dibujo correspondientes al VDP1 en ese orden.
Una de las limitaciones del Z-sort en entornos 3D es que su valor de distancia (orden Z) es solo aproximado, lo que significa que pueden seguir apareciendo fallos visuales. Por ello, los programadores pueden prescindir de SGL e implementar sus propios algoritmos.
En artículos posteriores verás enfoques alternativos para la determinación de superficie visible. Algunos siguen dependiendo del software, mientras que otros se benefician de la aceleración por hardware.
El problema de la transparencia
Como parte de su propio conjunto de efectos de color, el Sega Saturn es capaz de renderizar gráficos semitransparentes, es decir, mezclar capas de colores superpuestas para dar la ilusión de que podemos ver a través de ellas (también conocida como translucidez). Sin embargo, esta funcionalidad presenta importantes limitaciones :
- Solo el VDP2 puede mezclar píxeles con semitransparencia, mientras que el VDP1 únicamente genera un buffer renderizado sin distinción entre sprites superpuestos. En consecuencia, los sprites semitransparentes superpuestos ocluyen a los que están por debajo.
- El proceso de Forward Texture Mapping del VDP1 corrompe la semitransparencia cuando se aplica a sprites distorsionados (es decir, polígonos).
- Los píxeles semitransparentes tardan seis veces más en dibujarse.
Como solución alternativa, los juegos 2D pueden activar la propiedad 'mesh' en una textura. Con las texturas 'mesh', el VDP1 establece las coordenadas de textura X/Y impares como 'totalmente transparentes' (es decir, vacías), lo que permite que las capas inferiores sean visibles. Curiosamente, cuando la consola está conectada al televisor mediante la señal de vídeo compuesto (un estándar en la época, junto al RF), el patrón mesh aparece difuminado. Esta consecuencia accidental pero eficaz proporcionó una forma de simular la semitransparencia .
No obstante, las partes opacas de un mesh seguirían ocultando otros sprites. Además, esto no resolvía el problema para los juegos 3D. Al final, algunos títulos no tuvieron más remedio que prescindir por completo de la semitransparencia... aunque ciertos estudios encontraron soluciones ingeniosas. Veamos dos casos .
Video - Daytona de Sega (1993).
Video - Sonic R de Traveller's Tales (1997).
En ambos ejemplos, el juego ordena al VDP1 dibujar los objetos del primer plano y el escenario de fondo. A su vez, el VDP2 renderiza las imágenes del paisaje lejano y superpone las estadísticas del HUD sobre los modelos 3D. En consecuencia, los modelos 3D del VDP1 (renderizados como sprites distorsionados) no pueden emplear semitransparencia, lo que les impide mezclarse de forma natural con las capas del VDP2.
Sin embargo, los dos juegos exhiben comportamientos distintos. Durante el gameplay, el fondo de Daytona aparece de golpe (ya que la semitransparencia está desactivada). En cambio, Sonic R logra no solo semitransparencia sino también un efecto de fundido. Traveller's Tales ideó una solución: ajustó los registros de 'relación de mezcla' del VDP2 (que definen el alfa de la textura) y modificó manualmente los niveles de iluminación a medida que el personaje se acerca .