SEGA SATURN: Análisis /técnico de consola y juegosSaturn fue la consola de 32 bits de Sega que intentó repetir el éxito de la Megadrive.
Para entender cómo está diseñada la consola y como funciona, vamos a analizar la consola y los motivos de su peculiar diseño. Lo cierto es que es un HW muy curioso y voy a tratar de mostrar su funcionamiento interno de una forma sencilla. No voy a entrar en detalles de bajo nivel, no se pretende, simplemente vamos a ver el funcionamiento genérico.
La idea, como siempre, aprender algo nuevo, por Internet hay bastante información confusa. Así podremos contestar a las preguntas típicas con un poco de conocimiento:
¿Por qué tiene una doble CPU y una doble VDP?
¿Es verdad que es un sistema difícil de programar?
¿Puede hacer transparencias?
¿Es verdad que era un sistema pensado para el 2D y no para el 3D?
¿Sus juegos representan el techo del HW o hay espacio para la mejora?
Saturn es similar, hasta cierto punto, a 32X, una solución low-cost para darle vida a la Megadrive. Algunas partes son comunes y he hecho un copy-paste aquí.
Si estás interesado en saber más de 32X
mira este post.Por supuesto, si veis errores o desvaríos se agradecerá cualquier comentario.
ESPECIFICACIONESCPU: Dual SH-2 RISC a 28.6 MHz
RAM Principal: 2 MB
Sega/Hitachi VDP1 + RAM 512KB + (2x256KB framebuffers)
Sega/Yamaha VDP2 + RAM 512KB
Resolución: Varias soportadas, desde 320×224px a 704×480px, hasta 16M de colores.
Audio: Sound processor: Yamaha SCSP YMF292
Sound DSP: Yamaha FH1 DSP
Sound CPU: Motorola 68EC000
CD: Velocidad x2, memoria 512KB
DE ARRIBA A ABAJOSaturn es un HW bastante complejo para explicarlo de una vez. Voy a hacer un recorrido top-down de la consola, esto es, empezamos por conceptos genéricos y luego volvemos a verlos más ampliados. De esta forma primero nos hacemos una idea global y luego ya podemos profundizar. Y creedme, se puede profundizar bastante. Tened varios cafés preparados.
PRIMERA APROXIMACIÓN: ParaísoSaturn está divida en 3 grandes bloques:
- Bloque CPU: Aquí tenemos el doble procesador SH-2 y la RAM principal entre otras cosas.
- Bloque VIDEO: Aquí tenemos el doble VDP, la “gráfica” de la consola, y la salida de vídeo a la TV.
- Bloque SOUND: Aquí tenemos los procesadores de audio y la salida de audio.
Aparte tenemos la conexión con el CD-ROM y la entrada de cartucho opcional (para ampliar memoria o usar un decodificador MPEG para ver CD-vídeos).
BLOQUE CPUSe compone de la (doble) CPU, la RAM principal, la ROM, la SCU y el SMPC.
La
doble CPU son dos procesadores Hitachi SH-2 funcionando a 28Mhz. Ambos procesadores son iguales, y están configurados para funcionar como maestro-esclavo. Esto es, el maestro va encargando tareas al “esclavo” y le va ayudando.
La
memoria RAM de este bloque es la
memoria principal del sistema, son 2 MB.
La
memoria ROM es el equivalente a la “bios de un PC”, no la vamos a comentar.
El
SMPC se encarga, entre otras cosas, de recibir las entradas de los mandos.
El
SCU comunica el bloque CPU con el bloque de sonido o de vídeo. También al CD o a los cartuchos.
BLOQUE VIDEOSe compone del
doble VPD, su memoria RAM y los
framebuffers.
Los VDPs son la “gráfica” del sistema. Reciben una serie de instrucciones (llamadas
comandos) por parte de la CPU, y mientras los VDPs dibujan, la CPU puede dedicarse a otras tareas. Esto no es nuevo, la Master System ya tenía un VDP.
El bloque de vídeo de Saturn está pensado para trabajar de forma [/b]secuencial[/b]. Primero le pasamos los comandos necesarios a los VDPs. El VDP1 dibuja su parte, el VDP2 dibuja la suya y la combina con lo que dibujó el VDP1. El resultado es lo que aparece en pantalla.
VDP1 es el encargado de dibujar los patrones (sprites, polígonos, etc). Además de su RAM propia, tiene dos memorias especiales llamadas
framebuffers. Escribe=Dibuja en una, cuando ha terminado su contenido lo cede al VDP2, entonces el VDP1 “salta” al otro framebuffer para seguir trabajando. De esta forma evitamos que esté parado.
VDP2 es capaz de dibujar hasta 5 fondos distintos simultáneamente, con scroll en todas direcciones, rotaciones y planos abatidos (estilo modo 7 de SNES). Tras esto el VDP2 integra lo dibujado por él con lo dibujado por el VDP1 (en el framebuffer que corresponda) y saca la señal por pantalla.
BLOQUE SONIDOEl bloque de sonido se compone del SCSP, un motorola 68k y una RAM compartida para el sonido. Es capaz de manejar hasta 32 canales simultáneos. Se soporta sonidos FM, sonidos PCM, MIDI. Calidad CD.
OTROS ELEMENTOSPodemos ampliar la RAM de Saturn con un cartucho a tal efecto.
Podemos usar un cartucho MPEG para ver video CDs, el cartucho llevaría un decodificador MPEG.
El bloque CD y la descompresión MPEG funcionan, hasta cierto punto, de forma independiente, gracias a que dicho bloque está comandado por un SH-1.
CONCLUSIONESA primera vista tenemos un sistema muy interesante. El salto desde los sistemas de 16 bits es notorio. Comparando con la Sega Megadrive, pasamos de tener una cpu a tener dos, mucho más potentes. De tener un VDP a tener dos y mucho más capaces y versátiles.
La memoria RAM es enorme comparados con los 64 KBs de la Megadrive.
Los colores, el punto débil de la Mega, ya no son un problema. Y el sonido, el otro punto débil, ha sido mejorado de forma ostensible.
SEGUNDA APROXIMACIÓN: PurgatorioEn este diagrama se ven nuevos detalles. Arriba el bloque de CPU, abajo vídeo y sonido, a la derecha el puerto de cartucho y la entrada del CD-ROM.
BLOQUE CPUfuente:
http://pdf.datasheetcatalog.com/datashe ... Xwuttu.pdfAmpliemos lo que sabemos de los
procesadores. Tenemos 2 procesadores Hitachi SH-2 como CPU de la Saturn. A diferencia de las cpus que tenemos en ordenadores y móviles hoy día, no es una cpu dual, si no que ambos procesadores están montados siguiendo un esquema
maestro-esclavo. El SH-2 maestro es el que decide cuándo y cómo va a trabajar el SH-2 esclavo. Ambos comparten la memoria RAM principal. Ambos se conectan a ella a través del
mismo bus, llamado “bus de sistema” .
Por tanto tenemos
un sólo bus que conecta CPUs, RAM, ROM, SMPC y SCU. Cuando cualquiera de estos elementos intente conectarse al bus, sí otro también lo intenta, se produce una colisión y se hará un arbitraje del cual saldrá un
ganador que tendrá acceso al bus, los otros deberán esperar.
En el caso de los SH-2, será la CPU maestra siempre la que gane y consiga el acceso al bus. La esclava esperará. No obstante, sí es la esclava la que accede previamente a memoria, será la maestra la que tenga que esperar. Nótese que la CPU esclava es exactamente igual que la maestra y puede hacer lo mismo. No está limitada en absoluto.
Por tanto y debido a la forma en que ambas cpus están conectadas, a menudo un SH-2 tiene que esperar a que el otro termine. Para evitar esto cada SH-2 tiene una
pequeña memoria propia para poder trabajar internamente, llamada
caché, de 4 Kbytes de tamaño. Es responsabilidad del programador que su programa se apoye en esos 4KBs para trabajar y evitar colisiones, también debe pensar el programador en minimizar la espera.
Podéis encontrar más información sobre los SH-2 en el
análisis no técnico de 32X, pues es la misma doble CPU a menor frecuencia.
No obstante ampliaremos lo dicho allí con una pincelada, y es que los SH-2 tienen una
potente unidad aritmética interna, que se encarga de hacer operaciones matemáticas a gran velocidad. En concreto tenemos en cada chip 4 unidades de cálculo especializadas (
2 multiplicadoras, 2 divisoras), además es capaz de hacer una operación compleja llamada MAC (multiplica y acumula) de forma muy rápida. Esta operación es muy útil para cálculos relacionados con el 3D.
Hablemos ahora de la
RAM principal. Recordemos que tenemos
2MB, es decir, 2048KB.
La
RAM principal está formada por chips de distinta tecnología. Los SH-2 pueden manejar varios tipos de memoria sin problemas así que SEGA decidió mezclar una memoria más moderna, cara y rápida (SDRAM) con otra más lenta y económica (FPM RAM).
De esta forma tenemos una memoria “alta” y una memoria “baja”, cada una con 1 MB en total. La idea es poner el código y los datos más críticos en la memoria “alta” y los otros datos en la memoria “baja”. Es el programador el que decide cómo usar la memoria “alta” y la “baja”, no es un proceso automático.
Hay que tener en cuenta que el sistema se reserva parte de esta memoria para sí mismo, por eso vemos “1.5MB work RAM” en el diagrama, en la práctica es lo que tiene el programador para su programa.
Vamos a ver ahora un elemento no comentado hasta ahora.
El SCU (System Control Unit). El SCU es un elemento que conecta los distintos bloques (CPU,VIDEO,SONIDO,otros) de forma transparente. De forma que se pueden comunicar a pesar de que cada uno de ellos funciona de manera distinta. Además posee un DSP y un controlador DMA.
El SCU le hace la vida más fácil al desarrollador y a los SH-2. Cuando un procesador tiene que comunicarse con un elemento “externo” al bloque CPU, no necesita hacer ninguna gestión extraña, hace exactamente lo mismo que si fuera interno. ¿Cómo? con un
mapa de memoria unificado. El mapa de memoria está
dividido en bloques o tramos, cada elemento HW tiene un tramo reservado para sí mismo. Esto es, la memoria principal tendrá 2MB, habrá un bloque reservado para la RAM del VPD1, otro para la RAM del VDP2, un bloque para un framebuffer y un segundo bloque para el otro framebuffer, etc.
Imaginemos que un SH-2 quiere mandar un dato al VPD1. Lo que hace es ejecutar una instrucción con un dato y una dirección de memoria, en este caso de la zona reservada para el VPD1. El SCU transmitirá el dato al lugar adecuado a través de los distintos buses del sistema.
No es que tengamos una memoria real que lo agrupe todo, simplemente aprovechamos que tenemos la capacidad teórica de direccionar todas esas direcciones.
Así que el SH-2, al ejecutar la instrucción anterior, le dice al SCU que quiere escribir allí, y es el SCU el que “traduce” esa petición al elemento que corresponda.
Además, el SCU tiene un
controlador DMA que tiene la capacidad de enviar datos entre distintos elementos sin intervención de los SH-2, y mucho más rápido. Por ejemplo podemos enviar datos de la memoria principal a la memoria del VDP1 mientras los SH-2 están efectuando otros trabajos.
Otro elemento presente en el bloque CPU es el
SMPC.
Es el chip que “resetea” la consola al pulsar el botón adecuado. Es capaz de encender/apagar los distintos chips de la consola y establecer la frecuencia de trabajo de cada uno.
Este chip es el que recibe las entradas de los mandos y es el encargado de grabar partidas en la memoria interna de la consola.
Es capaz de guardar la fecha (gracias a la batería que tenemos en la placa como en los PCs), y dar la fecha como dato al sistema si el programador desea usarla en su juego.
BLOQUE VIDEOVDP significa
video digital processor, sabemos hasta ahora que el VDP1 dibuja los objetos y el VDP2 los fondos. Luego se combinan para la imagen final. Ampliemos.
El VDP1
(Hitachi) trabaja a 28MHz. Hasta 32768 colores (256 en alta resolución). Su memoria es de 512KB, además tiene acceso a los framebuffers, dos memorias de 256 KB cada una. El VDP2
(Yamaha) trabaja a 28MHz. Hasta 16M de colores. Su memoria es de 512 KB (dividida en 4 bancos de 128KB). La memoria de los VDPs se llama
VRAM (vídeo RAM), es una memoria muy rápida.
Tenemos que entender que
para un procesador dibujar es poner los datos adecuados en una memoria. Más tarde el HW leerá esa memoria y según los valores que lea, sacará, por cada pixel, un color. Ambos VDPs tienen varios “lienzos” donde “pintar”, combinándolos resultará un lienzo final que se llevará a la pantalla. Además de su memoria, los VPDs tienen ciertos registros que definen cómo se “pinta” en sus lienzos.
VDP1El
VDP1 es un chip que puede trabajar, según reza la documentación oficial de SEGA, con
patrones. Patrones son
líneas, polilíneas, polígonos (planos) o polígonos texturados, a los que llamaremos sprites. Se dice que Saturn trabaja con
quads (“quadrangle”, cuadrilátero).
Se utiliza erróneamente para definir todo lo que pinta la Saturn. SEGA define un
polígono texturado como un sprite (similar al sprite de las consolas clásicas), no como un quad.
Sin embargo, cuando hablamos de cómo representar un entorno 3D, sí que vamos a usar “quad”. Se refiere al peculiar forma de trabajar de Saturn en 3D, usando cuadriláteros (sean texturados o no), en oposición al uso de triángulos, que es el estándar.
El VDP1 utiliza su propia memoria de 512KB, y por tanto es independiente del procesador, a diferencia del VDP de 32X que tenía poca autonomía.
El programador le pasa al VDP1 una lista de comandos, el VDP1 lee esa lista y escribe (dibuja) en el
framebuffer. También guardamos los bitmaps que necesitemos en dicha memoria.
El VDP1 puede
escalar, estirar, rotar, recortar y espejar un sprite. Es decir, tenemos un “motor” HW que no necesita del procesador principal (a diferencia de Megadrive o de 32X):
Cuando hacemos ampliaciones, rotaciones o estiramientos, VDP1 realiza un antialiasing o suavizado para evitar pixelaciones y rellenar los “huecos” que puedan generarse.
Por otro lado el VDP1 puede crear “gratis” tramas con el patrón que nosotros queramos. Es decir, le damos un patrón y al sprite en cuestión lo “marcamos” para aplicar la trama, Saturn “tramará“ dicho sprite automáticamente. El uso de las tramas lo veremos luego, resumiendo diremos que simulan transparencias.
Es posible aplicar algunos efectos sobre los sprites (como transparencias, iluminación, mezclas de colores) pero esto
consume muchos ciclos del VDP1, por tanto hay que usarlo con cuidado.
También puede crear un sombreado Gouraud interpolando los colores en cada vértice de un polígono:
Este tipo de sombreado se usaba para disimular lo “toscos” que eran los modelos 3D de la época, también para simular iluminación. Bien usado daba gusto verlo.
El VDP1 tiene acceso a un
doble framebuffer. Escribe en uno de ellos mientras el otro es leído por el VDP2. Cuando termina, cambia al otro framebuffer, de esta forma no necesita esperar y puede tener un gran rendimiento. Por defecto se muestran 60 imágenes por segundo, pero es posible cambiar manualmente este parámetro.
VPD2El
VDP2 es un chip muy versátil. La idea es que el VDP2 cree los fondos, pero además el VDP2 recoge el contenido de uno de los framebuffers y lo mezcla con su propio contenido para crear la imagen final. En su memoria guardará, además de los comandos, los tiles o bitmaps que necesite para crear sus capas.
VDP2 soporta hasta
5 capas (los lienzos que mencionamos antes) , 4 de ellas
capas de scroll y la última es la capa de
backplane, que se situaría siempre al “fondo del todo”.
Una capa de scroll puede tener varios tipos de scroll (horizontal, vertical, ambos a la vez), es capaz de moverlos, rotarlos y escalarlos, puede aplicar efectos sobre estos fondos como la transparencia, efectos de raster, blur, etc. Puede aplicar sobre una capa un escalado para tener un suelo “infinito” ya sea con texturas o tiles (tipo modo 7).
Como en el VDP1, el programador le pasa al VDP2 una serie de comandos para que trabaje independiente del resto del sistema.
Además de sus capas, el VDP2 trabaja con uno de los framebuffer como si fuese una capa más (aquella en la que el VDP1
no está trabajando), puede manipularla a su antojo (independientemente del VDP1 y de la CPU). Por ejemplo puede rotarlo. Esto parece una tontería, pero si tenemos una pantalla donde todo “gira”, nos ahorra tener que rotar cada uno de los sprites con el VDP1, el ahorro es tremendo.
VDP2 puede hacer diversos
efectos sobre sus capas (
transparencias, disolver una capa progresivamente, crear sombras, etc.) A diferencia del VDP1, el VDP2 puede hacer estos efectos de forma muy “barata”, es decir, es muy rápido haciéndolo, mucho más que el VPD1.
El VDP2 puede operar a nivel de pixel/patrón/búfer-de-imagen-entero a la hora de realizar una manipulación.
BLOQUE SONIDOEl
SCSP (Saturn Custom Sound Processor) puede aplicar varios efectos (como reverberación, ecos, distorsiones, filtros,etc) a cada uno de sus 32 canales PCM o 8 FM.
Playstation sólo soportaba 24 canales PCM por ejemplo.
El
motorola 68EC000 funciona a 11.3MHz y es el encargado de todo lo relacionado con el
MIDI. MIDI es un estándar para crear música, permite tocar varios instrumentos desde un solo dispositivo, gracias a esto un músico no necesita saber nada de programación (como sucedía con algunas consolas antecesoras a Saturn).
OTROS ELEMENTOSEfectivamente podemos conectar un cartucho de memoria para ampliar la memoria principal de Saturn. Gracias al SCU los SH-2 no necesitan hacer nada extraño para usarla, (parte) de su contenido podrá accederse dentro del mapa de memoria (tiene reservados 32MB).
Pero hay que tener en cuenta que el acceso a esta memoria estará limitada primero por el
bus “A” (que es de 16 bits) y luego porque el acceso a los datos estarán bajo arbitraje, ya que acceder al cartucho implica acceder al bus de Sistema y al bus A
La diferencia entre un cartucho y el CD-ROM es que el cartucho se puede tratar como una memoria (lenta) más mientras que el CD-ROM requiere volcar los datos a memoria.
¿Qué hay de las
escenas de vídeos pre-renderizadas? Estamos en el punto álgido de los juegos con vídeos metidos de-cualquier-manera-porque-vende.
Aquí tenemos dos posibilidades. Una es usar el códec por defecto que es CINEPAK, que da un resultado bastante pobre pero para salir del paso nos vale. Otra es usar el cartucho MPEG para reproducir por HW vídeo codificado para este códec, con resultados muy superiores. Inconveniente: El cartucho era MUY caro.
Independientemente del elegido, el vídeo lo vamos a tratar como una capa del VDP2, por lo que podemos combinar vídeo con imágenes de un juego sin problemas
Hay otras posibilidades, no dejéis de ver éste vídeo, que incluye otros códecs que fueron usados y ejemplos de juegos (poned los subtítulos)
https://www.youtube.com/watch?v=ev7x8MwLq2ACONCLUSIONESEn esta segunda aproximación sí que hemos visto un salto importante respecto a los sistemas de 16bits. Aunque algunas cosas ya existían en estos sistemas, ahora lo tenemos elevado al cubo, con muchas facilidades ya integradas en el sistema.
La forma de trabajar del sistema gráfico de Saturn, por etapas, es ideal para juegos 2D tradicionales, hasta ahora no hemos tocado el tema 3D en gráficos.
Hay que decir que para un juego tradicional 2D, el VPD1 va
sobradísimo, en Megadrive tenemos unos 80 sprites en pantalla como máximo, en Saturn 16383 sin aplicar efectos (vamos, antes llenas la pantalla que superas el límite). El VPD2 hace cosas nunca vistas en una consola Sega.
TERCERA APROXIMACIÓN: InfiernoBLOQUE CPUAmpliemos nuestros conocimientos sobre el
SCU. Además de lo comentado sobre el mapa de memoria del sistema, el SCU posee un
DSP y un controlador
DMA.
El DSP es un
procesador programable muy rápido. SEGA recomienda usar este procesador cuando tenemos los SH-2 saturados. No obstante sólo tiene 1KB para almacenar datos y 1KB para almacenar instrucciones.
Fue poco usado, al principio de vida de la consola la documentación oficial no era precisamente abundante. Se especula mucho con que se podría haberse usado para acelerar cálculos de geometría, es decir, para 3D. ¿Qué hay de cierto en ello?
En la documentación de SEGA se menciona un posible uso para realizar transformaciones 3D de rotación. La idea es cargar el programa adecuado en el SCU-DSP, se le pasa la matriz de vértices y aprovechando que el SCU está conectado a todo, el resultado se escribe directamente en la RAM del VDP1, liberando a los SH-2 de ese trabajo.
En cuanto al potencial para el 3D, tenemos un ejemplo
https://segaretro.org/images/c/c7/ST-TECH.pdf“Saturn SCU DSP Demonstration Program”
“The DSP sample program performs 3D point transformation, i.e. it multiplies a 4x3 homogeneous matrix by an arbitrary list of 3-element vectors (the fourth element of each vector is presumed to be 1). The program attempts to take full advantage of the parallelism built into the DSP, and the transformation matrix, the input points, and the output points are transferred using the SCU’s DMA capability. The sample code performs point transformations roughly a third faster than the equivalent code written in SH2 assembly language, even allowing for the time spent transferring data into and out of the DSP’s memory. It is hoped that this program is general and useful enough to be used in an actual development environment.” Por tanto el DSP puede ayudar y mucho con algunas tareas para el 3D, pero claro, hay que programar en paralelo otro chip, distinto, en ensamblador, este chip tiene poca memoria interna y además tiene otra faena que es comunicar los SH-2 con VDPs, CD-ROM, chips de sonido, etc.
¿Hasta qué punto se usó o no el DSP? MISTERIO!!!
Buceando en la documentación de SEGA he sacado algunas cosas en claro, transcribo las que me han parecido importantes:
fuente:Saturn SCU DSP Tutorial, de
https://segaretro.org/images/c/c7/ST-TECH.pdfVentajas de usar el DSP
Es un procesador especializado en hacer sumas de productos y realizar cálculos con vectores y matrices como transformaciones 3D o cálculos rápidos. Para estos procesos el DSP puede ser más rápido que los SH2, porque puede hacer en paralelo varias operaciones: cargar los operandos de un primer cálculo, realizar un segundo cálculo y almacenar el resultado de un tercer cálculo a la vez.
Puede también multiplicaciones de 32x32 arrojando resultados de 48bits en un solo ciclo.
Desventajas
Funciona a la mitad de velocidad que los SH2, por tanto aunque puede multiplicar en un solo ciclo, ese ciclo es dos veces más lento que un ciclo de los SH2. Como no tiene casi memoria, y esa memoria NO está mapeada en el sistema, significa que el DSP constantemente tiene que ir copiando/leyendo los datos a/de la RAM principal, durante lo cual está parado.
Es difícil de programar. Una rutina que puede ser hecha para los SH2 en ensamblador en media hora, puede tardar en ser re-escrita para el DSP 1 día entero (incluye aquí el proceso de creación, debug y optimización).
El DSP tiene dos unidades funcionales (ALU y multiplicador) que pueden operar en paralelo.
Tiene 4 buses y 4 bancos de datos…. debido a ello, los datos deben estar en diferentes bancos para poder operar en paralelo… Por ejemplo, si queremos multiplicar una matriz con una serie de vectores, la matriz debe estar en un banco, los vectores en otro y los resultados irían a un tercer banco. Si no es así, se perderá tiempo innecesariamente moviendo los datos entre bancos.
El DSP es mucho más eficiente cuando puede leer y escribir datos secuencialmente, por tanto así deben encontrarse en la estructura de datos creada por el programador. Así puede que valga la pena re-formatear los datos antes de ser tratados por el DSP... Imagino que el que ha escrito esto lo ha sufrido. Aprender a usar en paralelo los SH-2 para alguien que nunca hubiese programado de esta manera, y hacerlo de forma eficiente, ya tenía mérito. Aprender además a usar otro chip también, diferente, y que tiene que coordinarse con los otros… difícil señores, difícil.
Como los SH-2 ya tienen capacidad para hacer cálculos matemáticos a gran velocidad, entiendo que la mayor parte de los programadores optaron por limitarse a usarla y no usar el DSP del SCU. Y es que en un proyecto, hay plazos, y por tanto si algo es confuso y difícil, y el rendimiento a ganar es superior pero no inmensamente superior, se ignora.
En la práctica usar el DSP implica pre-cargar los datos y luego copiar los resultados a la memoria principal. Es muy probable que la diferencia con usar directamente los SH-2 no fuera muy grande en el momento de usar una gran cantidad de datos, ya que el DSP apenas tiene memoria interna y habría que estar cargando y descargando datos de y hacia la memoria cada pocos cálculos.
BLOQUE VIDEOVamos a ver cómo se hacían algunos efectos con los VDPs.
TRANSPARENCIASSaturn puede hacer transparencias, eso dicen las especificaciones. Pero hay gran cantidad de juegos con tramas. Es… complicado.
Para seguir esta sección impagable seguir este pedazo vídeo del taiwanes
Low Score Boyhttps://www.youtube.com/watch?v=f_OchOV_WDgOs recomiendo poner la velocidad de reproducción a 0.75 (y subtítulos),
de esta forma podréis seguir el vídeo y el artículo sin problemas.
TRANSPARENCIAS EN JUEGOS 2Dfuente:
http://www.mattgreer.org/articles/sega- ... nsparency/Veamos un ejemplo para un juego 2D, “Megaman X”:
Los focos de luz del fondo son tramas, se ven los puntos perfectamente. Pero si jugamos y avanzamos en esa misma fase:
Avanzamos por un tubo transparente! ¿Qué es lo que ocurre aquí?
Vamos a ver cómo trabaja Saturn de forma “tradicional”. Esto es,
VPD1 dibuja los sprites.
VPD2 dibuja los fondos e incorporará los sprites a la imagen final.
fuente:
http://www.mattgreer.org/articles/sega- ... Blowup.svg 
Empezamos por el
VDP1.
Este chip dibuja los sprites como megaman y los focos de luz (tramas). Los focos no pueden, en principio, ser transparentes porque para ello tendríamos que saber qué hay detrás (el fondo), pero éste aún no se ha dibujado, o bien se ha dibujado pero al estar la información en un chip distinto, el VDP1 no puede hacer una transparencia si no tiene dicha información. Nótese que la luz amarilla del foco es en origen un polígono amarillo, no hay trama aquí.
Ahora sigue el
VDP2.
Este chip va a preparar varios fondos, recordemos que por HW Saturn puede usar hasta 5 capas distintas. Como se ve en la imagen hay varias capas por detrás de los sprites (fondo negro, fondo de edificios, parte trasera del tubo), y capas por delante de ellos (la parte delantera del tubo y los “adornos” industriales que se presentan abajo).
El VDP2 puede acceder a la información del framebuffer creado por VDP1, es decir, a los sprites, por tanto los sitúa en la capa que le interese y la capa delantera del tubo puede hacerla transparente juntando la información de la capa anterior (que incluye los sprites) con la capa superior (que incluye el bitmap del tubo).
Como tiene la info de las capas por detrás de los sprites, tubo-trasero y edificios, no hay problema para calcular la transparencia con respecto a ellos.
Cuando VDP2 “ve” que la luz amarilla del foco tiene un bit especial activado (el de tramas), aplica el “efecto trama” y al componer la imagen lo muestra como una trama.
Por tanto
con esta forma de trabajar VDP2 hace transparencias y el VDP1 tramas.
¿Es esto un atraso? Realmente si ves la Saturn con la TV de tubo de toda la vida utilizar tramas es una buena idea, porque mucha gente utilizaba video compuesto o cable antena RF para conectar la consola a la TV, y con esas señales las tramas parecen transparencias.
Además, como comentamos en el apartado de VDPs, es “gratis”, no gastamos nada de potencia de los SH2 ni más ciclos de los necesarios en los VDPs.
Pero ¿hay otras formas de usar el HW? Efectivamente, esto es “lo bonito” de Saturn.
Veamos otro ejemplo con “The Story of Thor”:
Los personajes y la sombra que hay debajo ¡son transparentes!
Fuente:
https://segaretro.org/images/c/c7/ST-TECH.pdf Apartado: “Using VDP1 Sprites to Cast Shadows on VDP2 Backgrounds”
Saturn tiene dos formas para crear
sombras: MSB Shadow y Normal Shadow.
MSB Shadow: El sprite de la sombra lo vamos a marcar en el VDP1 con un bit especial, que va a indicar que NO va a ser dibujado. Cuando el VDP2 lee el framebuffer, y ve dicho bit, en vez de dibujar el sprite, lo que hace es oscurecer aquellos píxeles que coinciden en la misma posición donde iría el sprite. Tanto de otros sprites (que coincidan en la misma posición) como con el fondo (capas inferiores claro, recordemos que pueden ser varias). Este modo tiene el inconveniente de no poder ser usado en modos de “alta resolución” y no todos los tipos de sprites soportados por Saturn pueden ser usados, los sprites basados en paletas de colores no pueden usarse en esta forma, sólo aquellos en formato RGB.
Esta podría ser la forma de obtener la sombra que vemos en “Story of Thor”.
Normal Shadow: Esta forma es parecida y sirve para crear sombras sobre los fondos. Esta forma soporta todo tipo de sprites y puede ser usado en alta resolución, de igual forma el fondo se oscurecerá donde irían el sprite de la sombra, pero tiene un gran inconveniente. Y es que los píxels de cualquier otro sprite (
con menos prioridad) que coincidan con la sombra, no serán dibujados.
Es decir, la parte “sombreada” será sólo sobre el fondo, si hay otro sprite “por detrás” que coincida (en parte o todo) con la sombra, dicha parte coincidente NO será dibujada, aunque el resto sí, será como si se hubiesen comido un cacho justo donde esté la sombra.
Por supuesto esto nos limita mucho. En un juego 2D clásico como una plataformas, un run & gun o un matamarcianos por ejemplo, no sería un problema, pues detrás de los sprites suele estar el fondo (el típico con scroll), pero en un entorno 3D, podrían solaparse varios polígonos(=sprites para la Saturn, para que nos entendamos) dando lugar a desapariciones.
Veremos un ejemplo a continuación.
Ambas formas de crear sombras son
trucos, no transparencias reales, pero sirven para hacer el trabajo de una forma muchísimo más rápida que si hiciéramos lo mismo con una transparencia real.
Veamos otros ejemplos pero esta vez con transparencias. Juego “Guardian Heroes”:
Fuente:
http://www.mattgreer.org/articles/sega- ... nsparency/
El personaje que manejamos, Nicole, tiene una capa transparente violeta, ¡funciona! Se ve el fondo a través de ella. Sin embargo si avanzamos un poco y tapamos el soldado del fondo…
No se le ve el pie derecho a través de la capa. Lo mismo que explicamos antes con una de las formas de crear sombras. ¿Qué está pasando? ¿Por qué sucede?
Exactamente lo que explicamos con las sombras pero es igual con las transparencias.
Si trabajamos con la 2a forma, que es la menos restrictiva y por tanto la más usada por los programadores, tendremos algunos problemas. En el ejemplo anterior sucede lo siguiente.
VDP1 trabaja con 2
framebuffers. Uno de ellos permanece bloqueado ya que se está mostrando por la TV, el VPD1 escribe en el otro mientras tanto. Ahí escribirá/”dibujará” los sprites de Nicole y del soldado. Y se hará de forma que el sprite con más prioridad (más cercano a la “cámara”), se dibuja por encima, se dibuja después.
Es decir, cuando VDP1 termina de dibujar los sprites de una frame, la parte de Nicole que coincide con el soldado ha “machacado” la parte del pie, que se ha borrado. En ese momento, la capa de Nicole es un sprite de un color violeta que elimina parte del soldado, no es transparente, aunque tiene el bit de transparencia activo, ésta sólo se aplica cuando el VDP2 lee el framebuffer. El VDP2 no puede, aunque quiera, poner el pie que falta, ya que la información se ha perdido, y hace transparente la capa con el fondo.
VDP2 lee el framebuffer pero no de la RAM interna del VDP1. Y el framebuffer no tiene varias capas, solo 1.
Sin embargo, al mismo tiempo, en el mismo juego…
El soldado rojo sí que se dibuja y coincide con la capa. ¿Brujería? No, simplemente al tener más prioridad se dibuja después en el framebuffer. Por tanto cuando el VDP2 lee el framebuffer, dichos píxeles del soldado rojo han machacado los de la capa en dichas posiciones.
¿Vaya lío no? Por eso mismo se utilizaban tanto las tramas, la trama deja ver lo que hay detrás (hablamos de varios sprites juntos), y no había que darle tantas vueltas como programador.
Los programadores fueron
creativos para evitar este problema.
En algunos juegos hay ciertos efectos (como explosiones) que parecen transparentes y se ven por encima de sprites sin problemas.
Por ejemplo, en este juego realmente lo que sucede es que se aplica la transparencia en algunos frames y en otros no, en algunos sprites primero y luego en los otros, por tanto no nos damos cuenta de las “mordidas” en los sprites.
Juego pausado:
Juego sin pausar, no se nota:
En otros juegos, dependiendo de si hay o no solapamiento de sprites, se usaban transparencia con el fondo o tramas. Ejemplo con “Silhouette Mirage”:
La explosión roja abajo-izq es transparente (con el fondo).
El personaje tiene un halo rojo transparente (con el fondo), pero un rayo de otra explosión le “da” en parte, vemos como la parte coincidente es una trama y el resto transparente (con el fondo)
Y luego hay juegos, como “Cotton Boomerang”, que lo que hacen es alternar la prioridad de uno de los sprites en el momento de aplicar la transparencia, de forma que se aplica la transparencia sólo cuando el sprite en cuestión está detrás, en el siguiente frame se coloca delante sin transparencia:
En marcha el efecto es casi perfecto:
Finalmente hay que tener en cuenta que podemos utilizar
la primera forma para crear transparencias, es decir, la forma
más restrictiva. En esta forma, si dibujamos 2 sprites con el VPD1 de esta forma, ambos sprites sufrirán una operación matemática consistente en hacer una media entre los valores de color de ambos, la parte coincidente se hace “transparente” y la no coincidente se queda igual.
¿Sin problemas? No.Veamos un ejemplo con el juego “Keio Flying Squadron 2”
Sprite del protagonista se tapa con el sprite del agua.
Vemos al protagonista a través del agua… pero el agua no es transparente con el fondo. Así que esta manera tiene sus inconvenientes. Pero hay más. Este simpático oso sujeta una linterna:
Aquí el sprite sin el “halo” de la linterna.
Si añadimos el sprite amarillo del halo, aplicamos el efecto transparencia, tal y como he explicado el halo se vuelve transparente con el oso, ¿pero qué ocurre con el fondo? No se ve el fondo!
Y es que la parte no coincidente con el sprite del oso se queda tal cual es el sprite original, por tanto tapa el fondo. En este caso no se nota porque el fondo es oscuro, pero como se ve en el agua, el fondo no se ve a través del halo.
Así que en vez de tener esto:
Tenemos esto:
Según la documentación de SEGA la transparencia puede customizarse, en la práctica los juegos parecen utilizar la fórmula:
pixel final = 0.5*a+0.5*b donde a y b son los pixeles de cada sprite
TRANSPARENCIAS EN JUEGOS 3DEn la práctica los problemas son los mismos que en los juegos 2D, pero debido a que la perspectiva de un juego 3D puede mostrar varios sprites unos detrás de otros, el problema se agrava porque una sombra o una trasparencia “delante” se comería todo lo situado detrás.
En este apartado hay un problema añadido, y es que el VPD1 va a ser usado al límite para el 3D, crear sombras, transparencias y otros efectos por este mismo chip es desperdiciar ciclos de trabajo, a más efectos menos polígonos va a poder generar, y al revés.
Así que lo que vamos a ver es un uso habitual de tramas en detrimento de las transparencias.
Así que podemos tener una escena simple con transparencias en un objeto 3D, nótese que no hay nada debajo:
O muchos varios objetos 3D (aviones) con tramas en los objetos 2D (nubes):
En Battle Arena Toshinden “canta” mucho, las transparencias de esta señorita son objetos 3D con tramado:
SALIDA DE VIDEO A TVJustifiquemos el uso de tramas con una sola imagen:
Para la época, los programadores se dejaban de rollos, tramas y a correr. Incluso en un juego de alta resolución como VF Kids, con S-Video se ve de lujo:
Hagamos zoom:
Sólo se ven las mallas en la salida digital, ni siquiera en S-Video no se aprecian.
¿CORRECCIÓN DE PERSPECTIVA? Una de las cosas en las que el uso de quads es una ventaja con respecto a los triángulos es que aplicar texturas a polígonos rectangulares
parece se hace perfectamente.
A la izq la imagen que queremos abatir, es decir, la textura original. Queremos mostrarla en una pseudo perspectiva 3D, la parte inferior estará “cerca”, la superior “lejos”.
Si usamos triángulos, necesitamos 2, pero en cada uno se aplica la textura de una forma distinta. Si usamos en cambio un sprite, queda perfecto.
Lo vemos fácilmente en el suelo, en PlayStation hay extrañas ondulaciones. También se aprecia en las vetas de madera de la casa, en Saturn son bastante rectas.
Esto
no es una sofisticada técnica de corrección de perspectiva, simplemente es por la forma de trabajar de los sprites. En estos casos, sin ningún esfuerzo salen bien las texturas.
Saturn
no tiene corrección de perspectiva por HW, por si había dudas.
Pero no todo iban a ser ventajas. Lo que acabamos de mostrar sólo funciona si el polígono texturado se manipula para ser más menos regular. Si nuestro polígono no lo es (lo que SEGA llama “sprite distorsionado”), Saturn tratará de rellenar los huecos añadiendo colores de píxeles contiguos.
Como consecuencia, los resultados son imprevisibles aunque en una textura sencilla serán aceptables. Ejemplo:
¿CACHÉ DE TEXTURAS?En el mundo PC actual, la caché de texturas es una
pequeña memoria, muy muy muy rápida, que permite almacenar unos pocos datos(texturas). La idea es tener estos datos a
mano de forma que se puede aplicar esta textura en múltiples polígonos.
Saturn
no tiene caché de texturas, al fin y al cabo hablamos de la prehistoria del 3D.
No tenerla significa que si tenemos un montón de polígonos con la misma textura tenemos que repetir el (casi) mismo trabajo cada vez. Pongamos que tenemos un árbol con hojas, unas 30 hojas en ese árbol, cada una con un sprite ligeramente distinto. Para cada hoja el VDP1 generará un sprite y adaptará la textura a él. A lo tonto hemos hecho un trabajo (casi) igual 30 veces.
PlayStation, sin embargo, tenía una pequeña caché de texturas (4 KB), pero hacía su papel, pudiendo poner la misma textura en múltiples triángulos.
END CODESSaturn por defecto samplea por completo un sprite cuando lo dibuja. ¿Qué significa esto? Pongamos un ejemplo, vamos a dibujar el sprite del jugador y vamos a aplicarle un efecto de color (como subirle un par de tonos de rojo para representar el jugador ha sido golpeado). Para ello, VDP1 recorre
uno a uno cada pixel del sprite en la VRAM (cada posición en memoria), línea por línea. Para cada píxel hace los cálculos pertinentes y escribe el resultado en el framebuffer, ya tenemos el sprite del jugador con el efecto deseado.
Ahora supongamos que vamos a dibujar un sprite pero por el motivo que sea sólo queremos escribir
parte de él, por ejemplo la mitad superior. VDP1 por defecto va a samplear todo el sprite, incluso la parte que no se va a ver. Esto hace perder ciclos del VDP1 innecesariamente pero así es como trabaja. Si tenemos un sprite con partes totalmente transparentes, al dibujarlo las partes transparentes también se samplean, aunque luego obviamente no se dibujen.
La solución a esto es usar
end codes, que son marcas que podemos asociar a un sprite. Estas marcas le dicen al VDP1 que partes nos podemos “saltar” en el sampleado y ahorrar ciclos. Esto nos puede ayudar si tenemos sprites grandes con partes transparentes, por ejemplo en este sprite:
Si ponemos end code cuando empieza la parte en rojo (que es la parte transparente), cuando hace el sampleado al encontrar el end code directamente saltará a la siguiente línea del sprite sin tener que recorrer la línea entera.
Es una ayuda, aunque hay que
hacerlo a mano para cada sprite y tampoco es la panacea.
BLOQUE SONIDOSaturn puede manejar samples de 8 o 16 bits. A más calidad, necesitamos más memoria y capacidad de proceso. La RAM de audio es compartida entre SCSP y el Motorola.
Por lo que tengo entendido, el sistema de audio de la Saturn es bastante bueno, y no tiene nada que envidiar al de PSX o N64, es más, por lo que leo es incluso mejor.
OTROS ELEMENTOSEsta es la placa base de Saturn (revisión VA8):
Obviemos la parte trasera (que tiene algunos chips más), llama la atención la cantidad de chips existentes. Las
revisiones del HW de una consola es algo que existe desde el pleistoceno. Saturn era muy jodida en ese sentido, se revisa el HW para corregir algún fallo de diseño pero sobre todo para abaratar costes cambiando e integrando componentes.
Al tener tantos y tan variados poco se pudo hacer para ir bajando el precio.
CONCLUSIONESLos problemas más conocidos en el diseño de Saturn los hemos visto en esta aproximación.
La forma de trabajar “por capas” utilizando chips distintos e independientes tienen sus ventajas pero también sus inconvenientes, no hubiese sido para tanto si Playstation y sus juegos no hubiesen sido tan transparentes, fue una moda que llegó en esta generación y Saturn la sufrió porque hacer cierto tipo de efectos es difícil, que no imposible.
El uso de tramas lo veo lógico aunque es un recurso ya visto en Megadrive, podrían haber mejorado un poco ese tema.
Pero ¿y el 3D? ¿Dónde dice que la Play era superior en 3D y la Saturn una consola 2D?
Sigamos descendiendo
CUARTA APROXIMACIÓN: 3D, el talón de AquilesINTRODUCCIÓN AL 3DLas consolas clásicas estaban diseñadas para trabajar con sprites y tiles en un espacio 2D. Es decir, sobre un plano, representamos un mundo con personajes planos. Estos pueden moverse sobre ese plano, para ello nos basta con matemáticas básicas, el HW de las consolas clásicas basta para ello. Una posición en ese plano se define en una coordenada (x,y).
Por supuesto, el
aspecto podía ser plano o no, pero al final, internamente manejamos 2 coordenadas. Knight Lore de Spectrum, es un ejemplo de pseudo 3D.
De ahí a Virtua Racing de Megadrive, hay un recorrido interesante, pero al final estos aparatos de 8 y 16 bits solían trabajar con dos dimensiones. Los sprites del juego pueden aparentar ser 3D pero no lo son, al fin y al cabo son sprites, ¿no?
Al no estar preparadas para 3D real, cuando se trataba de calcular y dibujar en un espacio 3D, o recurrimos a dopajes interesantes (chips externos) o la lentitud es la norma.
Cuando hablamos de 3D, añadimos una coordenada más, la “Z”, la profundidad o distancia hasta la “cámara”. Además dejamos atrás los sprites, ya que un objeto también va a tener profundidad. La representación básica de un punto en el espacio 3D se representa en una coordenada tipo (x,y,z):
Para poder trabajar realmente en 3D, tenemos que tener una serie de herramientas que nos permitan hacer una serie de cálculos de forma rápida y precisa. Un objeto puede moverse sobre un plano o sobre otro, rotar de varias formas, acercarse o alejarse a la “cámara”. Es más, los objetos pueden permanecer quietos, y ser la cámara la que se mueva.
Los objetos son tridimensionales, cada vértice se encuentra en un punto distinto.
Además tenemos que representar ese 3D en una pantalla, que es un plano 2D, es necesario cálculos adicionales para crear la proyección de ese mundo 3D en 2D.
Además tenemos que ver qué se ve y qué no se ve, porque unos objetos pueden estar detrás de otros, total o parcialmente, o salirse de la vista de la cámara, total o parcialmente.
Las matemáticas necesarias son bastante más complicadas. Aquí se hace necesario el uso de matrices y cualquiera que haya tenido que hacer cálculos a mano con matrices sabe que es un buen dolor de muelas.
Saturn dispone del HW necesario para hacer operaciones matemáticas a gran velocidad. Tenemos que crear la función adecuada para hacer las multiplicaciones, sumas e ir pasando los datos. Esto podemos hacerlo en los SH-2 o en el SCU, tenemos ambas posibilidades, pero ni el VDP1 ni el VDP2 nos van a ayudar con esto. La geometría es cosa de los procesadores.
QUADS Y TRIÁNGULOSTodos los objetos 3D que vemos en pantalla están hechos de pequeños objetos geométricos llamados primitivas. Quads y triángulos, son un ejemplo (hay otros),
La industria adoptó los triángulos como estándar por un motivo principal: todo polígono puede ser dividido en triángulos, pero un triángulo no puede ser dividido en otra cosa que no sea triángulos. Al final todo polígono puede ser descompuesto en triángulos. En cambio, con quads no puedes representar todo tipo de polígonos.
Dibujar triángulos es más fácil que dibujar otros polígonos (como los quads), menos lados y menos vértices. Los triángulos tienen propiedades interesantes que les dan ventajas sobre otros polígonos a la hora de dibujarlos y aplicar ciertos efectos sobre su superficie.
Al ser los triángulos la primitiva más simple, los algoritmos que trabajar con ellos pueden ser optimizados de forma más sencilla que si tratáramos con primitivas más complejas.
Trabajar con quads no es tecnología alienígena. La
primera tarjeta NVIDIA, la NV1, comercializada como Diamond Edge 3D trabajaba con quads. Por eso SEGA hizo diversos ports de juegos de Saturn para PC para este tipo de tarjetas. No duraron mucho en el mercado y todos los fabricantes pasaron a usar triángulos como base.
AHORA SE VE, AHORA NO SE VEEn una escena 3D, y debido a la profundidad, hay objetos que pueden quedar por detrás de otros, total o parcialmente. Si establecemos un método que nos diga si un objeto no se ve, nos podríamos ahorrar su dibujado. Es lo que se llama Z-buffer
Ni Saturn ni Playstation tienen por HW nada que evite dibujar un objeto no visible.
Así que por defecto pintamos TODO. Pintaremos lo más cercano después, para pintar encima de lo ya pintado (lo lejano). Esta forma de pintar se denomina “algoritmo del pintor”, teniendo el desarrollador que establecer de forma manual lo que está lejos y lo que está cerca.
Ni que decir que es un algoritmo muy poco eficiente.
Saturn tiene, al menos, una característica y es que podemos marcar sprites con prioridad para que aparezca por encima de otros en todo momento. Si queremos evitar desperdiciar ciclos de CPU dibujando cosas que no vemos, hay implementar un algoritmo por parte del programador aunque claro, irónicamente, estos cálculos también costarán ciclos.
CÓMO TRABAJA SATURN EN 3DVamos a resumir el proceso 3D
habitual de Saturn.
La CPU hace los cálculos necesarios (y/o la SCU si el desarrollador los tiene bien puestos) para calcular la geometría de la escena. Calcula entre otras cosas las posiciones de los vértices de cada polígono.
A continuación, dibujamos los quads (VDP1) tomando como posiciones los vértices antes calculados. Si los polígonos son texturados=sprites, para cada uno sampleamos la textura (su sprite) y la adaptamos al polígono (rotación,forma no regular,efectos). Si no son texturados, rellenaremos con el color elegido el interior del polígono. Si tenemos un degradado gouraud, calcularemos los valores y luego pintaremos el polígono.
El resultado queda en el framebuffer. VDP2 crea los fondos necesarios y con la información del framebuffer crea la imagen final.
Sin embargo, utilizar el VDP2 de forma inteligente puede ayudarnos al descargar de trabajo a la CPU y al VDP1 para
simular entornos 3D.
Lo más habitual es que el suelo sea una capa abatida del VDP2 que éste rote y mueva. Además una o varias capas pueden ser usada para simular fondos y objetos (como edificios, árboles, rocas), escalando y rotando la capa donde están dichos “objetos”, dando sensación de profundidad.
Esto lo vemos p.e. en juegos de lucha, con capas que simulan suelo, techo y fondo. Sólo los personajes y algún objeto cercano están hechos en 3D.
IGNORANDO AL VPD1Una de las cosas más curiosas que podemos encontrar es que algunos desarrolladores decidieron
ignorar parte del hardware para obtener más rendimiento. Evitaban usar el VDP1. ¿Por qué lo hicieron? ¿Cómo lo hicieron?
Los SH-2 pueden acceder al VDP2 y a su VRAM directamente, sin pasar por el VDP1.
El SCU también puede pasar datos de la RAM principal a la VRAM del VDP2 (por DMA).
La gracia está en que si manejamos de forma hábil esta capacidad de escribir en la VRAM del VDP2, podemos conseguir resultados notables. La idea es que los SH-2 “dibujen” los polígonos en la memoria principal, y luego pasar esto directamente a la VRAM del VDP2 (en una de las capas del VDP2, es decir, dibujando=escribiendo en una de sus memorias). Una vez hecho esto, el VDP2 hace su trabajo habitual (generar el suelo p.e.), combina sus capas y, magia, tenemos una imagen por la TV tan válida como si lo hubiese hecho el VDP1.
Al mismo tiempo podemos usar el VDP1 para dibujar algunos de los objetos mientras los SH-2 “dibujan” otros.
Esto es viable, pero como programador tendremos que evitar saturar a los procesadores con “dibujos”, al fin y al cabo tendrán que sobrarnos ciclos para manejar la IA del juego, enviar instrucciones para ir pidiendo datos del CD, controlar las puntuaciones, etc.
Como ejemplo tenemos a DOOM, que funciona (en parte) de esta forma. Aunque no es un ejemplo brillante, rinde bastante mal.
FALLOS DE DISEÑOCÓNCAVO Y CONVEXOHablando de polígonos planos, Saturn puede dibujar quads cóncavos y convexos. Sin embargo, si hablamos cómo el VDP1 rellena dichos polígonos, los polígonos cóncavos pueden dar problemas, el relleno puede “salirse”. En la siguiente figura tenemos el polígono definido con sus vértices y el relleno en gris:
No obstante lo habitual es usar quads convexos, matemáticamente un polígono convexo tiene una serie de propiedades que no tiene uno cónvaco.
RE-RE-RE-RENDERIZANDORecordemos esta ilustración:
Sin problemas ¿verdad? Saturn recorre horizontalmente la textura (izquierda) y la adapta al polígono (derecha). El problema surge cuando rotamos un polígono, si tiene una forma inclinada, si el tamaño no es el mismo de la textura, si el tamaño de un lado no es el mismo del otro lado:
¿Qué hace aquí el VDP1? Va a recorrer la textura de forma horizontal, línea por línea, pero el polígono está inclinado y cada línea tiene un tamaño distinto al anterior, tanto a lo largo como en altura. Por tanto, tal cual, no puedes poner la textura en el polígono, porque te quedarían huecos donde la consola no sabe exactamente qué poner.
El algoritmo interno del VDP1 lo que hace es “interpolar”, es decir, para cada pixel que no tiene info, va a coger un valor medio de los píxels que tiene arriba, abajo, izquierda y derecha. De esta forma no quedan agujeros.
Pero claro, hacer esto implica calcular múltiples veces el valor del color (de la textura) para muchos píxels. Muchos ciclos de trabajo del VDP1 se desperdiciarán.
Un problema similar con este polígono:
En la zona del cuadrado azul, vamos a re-escribir una y otra vez el valor de la textura.
El estándar de la industria 3D es utilizar triángulos, podemos representar un triángulo en Saturn haciendo coincidir dos vértices en la misma posición, es una forma “rápida” de hacer funcionar un motor 3D en Saturn:
¿Qué ocurre con el renderizado? Si lo hacemos tal cual funciona Saturn, quedará algo raro, todo muy estrecho cerca de los vértices 3 y 4. Para evitarlo los desarrolladores modificaban la textura original para que “quedara bien” al estrecharla. Pero en realidad lo que quiero destacar es que, para una figura aparentemente triangular, vamos a usar la textura en su totalidad, es decir, vamos a recorrerla entera aunque solo nos haga falta la mitad (suponiendo una textura rectangular). Más ciclos perdidos = Motor 3D poco eficiente.
KISSEl principio KISS establece que la mayoría de sistemas funcionan mejor si se mantienen simples que si se hacen complejos; por ello, la simplicidad debe ser mantenida como un objetivo clave del diseño, y cualquier complejidad innecesaria debe ser evitada.
“Un sólo procesador central, muy rápido, hubiese sido preferible. No creo que todos los desarrolladores tengan la habilidad para programar dos cpus, la mayoría sólo podrá obtener una vez y media la velocidad de un SH2. Sólo 1 de cada 100 programadores será lo suficientemente bueno como para obtener una potencia de 2 SH2”
Yu Suzuki durante el desarrollo de Virtua Fighter (traducción chustera).
SEGA desde luego no aplicó este principio para su consola, demasiados chips, algunos demasiados específicos (VPDs) otros no lo suficiente para alguna tarea determinada (los SH-2 y el 3D).
Como comentado, luego simplificar y unificar chips es esencial para abaratar costes, pocos chips fueron unificados a lo largo de la vida de Saturn (SH-1 con HW del CD por ejemplo).
HERRAMIENTAS DE DESARROLLOEsto no es un fallo HW, pero lo meto en esta sección. Contrariamente a lo que se cree, la diferencia entre la PlayStation y la Saturn no es abultada. Sony se preocupó de dar facilidades a los desarrolladores: herramientas sencillas, basadas en C, fáciles de comprender.
Debido a que el HW de Playstation era más que adecuado para el 3D, obtener buenos resultados era sencillo. Tenemos un procesador de geometría dentro del propio procesador (el GTE), con eso de un plumazo liberamos al procesador de un montón de trabajo, y como tenemos un montón de funciones de serie para el manejo de 3D, es pan comido desarrollar un motor 3D.
SEGA también ofrecía unas librerías para programar en C. Pero los programas resultantes eran de 2 a 5 veces más lentos que los hechos en ensamblador, en la práctica te obligaban a usar ensamblador. Estas herramientas se mejoraron más tarde, por las quejas de los desarrolladores. Para cuando estas llegaron, Sony liberó el acceso en ensamblador para utilizar el GTE, con lo cual podrías sacar más rendimiento al HW si te lo currabas, notándose la diferencia en el desempeño del 3D entre una consola y otra.
CUELLOS DE BOTELLAComo todo HW Saturn tiene sus cuellos de botella, repasemos los más cantosos.
VDP1 es un chip fundamental para el tratamiento de sprites. Mientras más sprites, más efectos, más ampliaciones/rotaciones/etc más faena tiene. ¿Cómo podríamos haber mejorado esto? El VDP1 está conectado a su memoria VRAM, y es con ella con la que interactúa constantemente para luego escribir el resultado en el framebuffer.
Esa RAM es del tipo SDRAM. Este tipo de RAM es muy rápida si hacemos muchas lecturas seguidas, o muchas escrituras. Pero si combinamos ambas, el rendimiento cae en picado.
Por otro lado, los SH-2 son los responsables de generar la geometría en el 3D. Su capacidad es buena, pero tener que lidiar con las colisiones penaliza y mucho el rendimiento. Fue un fallo no darle algo de memoria propia adicional al SH-2 esclavo, los 4KB de caché están muy bien (dentro del contexto de la época), pero algo más hubiese sido mejor.
Tenemos 2 memorias diferentes que conforman la memoria principal, pero ambos están unidos al mismo bus. ¿Por qué no dar un acceso alternativo?
Es decir, si el SH-2 maestro quiere acceder a la “memoria alta” (un chip) y el SH-2 esclavo a la “memoria baja”, darles esa posibilidad implicaría que ambos estarían trabajando a la vez sin molestarse mucho. Esto aumentaría mucho el rendimiento general.
Por supuesto esto haría que los desarrolladores tendieran a utilizar las memorias por separado, pero creo que sería incluso mejor, menos confusión.
En su época, los vídeos pre-renderizados eran la moda. Sony incluyó HW dedicado en la Playstation, de nuevo, una facilidad para el desarrollador.
Por supuesto el “fallo de diseño” más importante es la geometría por quads, cuando todo lo relacionado con el 3D se trataba con triángulos, pero toda esta consola está construida en torno a ello, cambiar esto supone cambiarlo todo.
JUEGOSVeamos algunas de las cosas antes mencionadas en juegos reales. No se trata de repasar los juegos del sistema, si no de ilustrar lo antes comentado.
VIRTUA FIGHTER’sVirtua Fighter fue el título de lanzamiento de Saturn. Un título que quizá fue lanzado prematuramente, ya que ni siquiera AM2 dominaba completamente el HW.
Esta es una captura de VF1 en un emulador de Saturn:
En pantalla tenemos dos personajes compuestos por polígonos planos.
El suelo también son polígonos, nótese que gastar ciclos de la cpu para el suelo deja menos ciclos para los luchadores, pero así está hecho este VF1. Incluso parte del marcador está dibujado por el VDP1. Si quitamos lo dibujado por el VDP1, solo queda el fondo.
Ahora nos vamos a VF2
Tenemos un montón de texturas que disimulan muy bien los “poligonazos” de la primera versión. Los luchadores siguen siendo creados por el VDP1, pero ahora el VDP2 tiene más tareas a su cargo, una capa es el edificio en ruinas, otra el fondo, otra el marcador y finalmente la capa de rotación es la que dibuja el suelo (que ya no son polígonos como sucedía en VF1).
Por tanto los personajes 3D están compuestos por polígonos
texturados y el suelo es un plano abatido
texturado. La evolución es más que evidente. Poner texturas nos ahorra poner polígonos en ciertas partes y meter más polígonos en otra. Por ejemplo, el pelo en VF1 son varios polígonos. En VF2 también pero al meter una textura de pelo, nos basta con poner un par (es una forma de hablar), y la textura hace el resto.
¿Cómo se aplican las texturas a los polígonos?
Esta es una captura de un emulador, aquí vemos como los luchadores son una suma de polígonos y en cada uno un sprite. Hay cientos de ellos.
Estas texturas están ubicadas en la memoria del VDP1.
DAYTONA USAEste juegazo fue lanzado con un popping exagerado (es decir, los polígonos aparecen “de golpe”), debido a esas críticas, una versión mejorada fue lanzada más tarde.
Daytona usa es el ejemplo perfecto que un juego que no “casa” con el HW de Saturn. Tanto los coches como el escenario son polígonos 3D, por tanto no podemos usar el VDP2 para liberar de trabajo al VPD1, no podemos hacerlo porque el suelo no es plano, porque no hay paredes planas ni techos. Sólo podemos usarlo para pintar el cielo y los marcadores.
Así que el recurso básico para ahorrarnos unos ciclos de computación no los tenemos.
Esta es la pantalla que vemos por la tele:
Esto es lo que pinta el VDP1, vamos, casi todo:
Suelo, coches, gradas, la noria...
Ahora sólo el VDP2:
En una capa el fondo, en otra el marcador.
Como en VF, los sprites distorsionados están en memoria del VDP1, por ejemplo, la noria:
Esta sólo aparece en un lugar y por tanto está solo una vez en la VRAM, pero en cambio el público no está compuesto solo de un polígono, si no de varios. Como la textura del público ha de adaptarse a cada polígono, en memoria tenemos varios sprites distorsionados repetidos:
Esta son algunas de las texturas de nuestro coche, el VDP1 rotará y distorsionará:
En cuanto al reflejo en el cristal, obviamente no es calculado si no simulado.
GRANDIAEn este juego podemos andar por una ciudad con nuestro personaje. Los edificios proyectan sombras y los personajes, al entrar en la sombra, aparecen más oscuros. No parece haber problema alguno.
Este juego es un ejemplo de uso del VDP2 para ayudar en el 3D.Veamos:
- Los personajes son sprites (VDP1).
- El suelo es un plano abatido y texturado (VDP2).
- La sombra de los edificios está incluida en el suelo, es el mismo gráfico (VDP2).
- Los edificios están en 3D (VDP1).
Si el juego ve que las coordenadas de los personajes están dentro de una “zona de sombra”, cambia su sprite a un sprite oscuro y si salen de la sombra pone el sprite normal. Realmente parece haber una pequeña transición así que es posible que utilicen los cambios de color (brillo) del VDP1 para ello. Como no hay ningún sprite debajo, no hay problema en usar estos efectos.
No hay proyección de sombras en 3D ni cálculos exóticos, es simplemente habilidad del programador. Irónicamente la versión de Playstation no tenía este efecto
BURNING RANGERSUn must-have si queremos ver de primera mano el uso de transparencias en Saturn.
Programado por el Sonic Team.
Veamos esta pantalla:
Ponemos unos recuadros para señalar las transparencias:
(1),(2) son parte del marcador del jugador, intuitivamente es una capa transparente del VDP2 situada por encima de todo. Hasta aquí nada extraordinario.
(3) es la sombra del jugador, vemos una trama. Esto es cosa del VPD1, parece lógico pues coincide en parte con los polígonos del jugador. Hasta aquí todo normal.
Luego tenemos (4) un fuego transparente en el fondo, aparentemente un sprite, está animado, intuimos que por tanto es creado por el VPD1. Pero el escenario está hecho en 3D no? Creado por tanto también por el VPD1. Por tanto aplicar transparencias podría resultar en problemas.
¿Y (5)? En la captura no se aprecia pero es una ventana transparente que deja ver lo que hay detrás, que son edificios.
De nuevo, la habilidad del programador supera las restricciones del HW.
Así funciona el juego en esta escena:
Las explosiones y la ventana son sprites, creadas por VDP1, y no son transparentes en este momento. Los sprites (llamas y ventana) son dibujadas a la mitad de la resolución original (se nota mucho pixelado). Esto se hace para acabar este paso lo más rápido posible.
Nótese que el perfil del personaje aparece “en negro”, es decir, el programador respeta ese “hueco” tanto si hay llamas como si movemos la cámara para que el personaje “tape” la ventana.
A continuación el VDP2 copia el framebuffer en una de sus capas por DMA. Por tanto tenemos los sprites en una capa del VDP2. No son transparentes.
El VDP1 borra el framebuffer y crea la escena 3D. Todo lo que no va a ser transparente, personaje y escenario.
Ahora el VDP2 puede mezclarlo todo:
La capa de fondo.. al fondo (lo que se ve por la ventana).
La capa del framebuffer con todo lo 3D no transparente encima (personaje, escenario). Se reescala a la resolución normal.
La capa de sprites (llamas, ventanas) la ponemos encima y activamos la transparencia de esta capa sobre las que están debajo (las antes comentadas).
Realmente las llamas están en la capa situada “por encima” del personaje, pero como el programador ha sido hábil y se ha dejado el hueco del personaje, no aparecen por encima.
Esto se ve perfectamente en otra escena del juego:
En esa escena las llamas de la izquierda “se salen” de la habitación, aparecen por encima de la puerta. Se tiene en cuenta el personaje pero no el marco de la puerta para dibujarlas.
Otro truco de este juego es que los objetos “a pasar” del VDP1 al VDP2 son dibujados en un tamaño más pequeño del que vemos en pantalla. Es decir, VDP1 dibuja una versión reducida y luego VDP2 escala estos sprites (escala la capa claro), de forma que VDP1 acaba antes (con las llamas del ejemplo anterior) y puede dedicarse al 3D. El VDP2 es muy rápido escalando y haciendo transparencias.
Claro está, esto no evita pixelaciones pero es otro ejemplo de habilidad del programador. Además dependiendo de cuantos objetos transparentes tengamos en pantalla, este procesado hace que el framerate el juego se resienta.
En concreto este juego tiene ese defecto, al haber tanto procesado no puede llegar a mantener un framerate estable.
Es por eso que sigue usando tramas en ciertos casos, por ejemplo el personaje muestra una sombra todo el tiempo, esta es una trama.
TOMB RAIDERLara Croft debutó en Saturn, Sega se reservó la exclusividad 1 mes en su consola. Fue una exclusividad un tanto ridícula.Por tanto se puede decir que la versión de Play fue lanzada “al mismo tiempo” de cara al desarrollo.
Ambas versiones fueron realizadas por separado para sacar lo mejor del HW en ambos casos, por tanto es una buena muestra de lo que daba de sí cada HW al principio de su carrera comercial. La versión de Saturn está muy conseguida, aunque la de Playstation es ligeramente mejor. En el apartado BONUS hablaremos sobre ambas versiones.
SATURN DOOMEsta versión no aprovecha el HW de Saturn. ¿Por qué?
Lo leemos en estas declaraciones del desarrollador del port para Saturn, Jim Bagley:
“Cuando empecé el proyecto tuve que hacer una demo para que Id Software lo aprobase. Comencé extrayendo los niveles, el audio y las texturas de los archivos WAD de la versión PC, e hice mi versión de Saturn, que renderizaba aprovechando el hardware 3D (se refiere a los VDPs). Envié la demo y un par de días después recibí una llamada de John Carmack, que me dijo que bajo ninguna circunstancia podía usar el hardware 3D para dibujar la pantalla. Tenía que usar los procesadores como en el PC. Por suerte me gustan los desafíos. Así que usé los SH-2 para dibujar la pantalla, cada uno dibujaba la mitad de la pantalla. Para reducir la complejidad decidí usar los niveles de Playstation. Estoy bastante contento con el resultado.” El motivo de no usar los VDPs era que el aspecto del juego difería del de PC. Es decir, si suelos y techos son hechos por el VDP2, con planos abatidos no va a verse igual que con polígonos. La demo también usaba el VDP1 para tratar las texturas de las paredes, ya hemos visto como trata el VDP1 los sprites estirados, rotados y deformados, a veces se ven bien, a veces no. Curiosamente esta demo iba muy rápida pero Carmack no dió su conformidad.
La versión final, que corre entera desde los SH-2, no va precisamente fina. Curiosamente mientras más lenta va, peor responden los controles, porque el juego da preferencia al renderizado del 3D sobre el procesado de los controles. Quizá por ello “tunearon” la cadencia de disparo de esta versión, que es superior al resto de versiones.
¿Hasta qué punto aprovechan los SH-2? No puedo dar una respuesta lamentablemente, no sé si podían haberles sacado más jugo. Lo que sé es que, como la versión de 32X, fue hecha a toda prisa para sacar el juego en la fecha que SEGA estableció.
PANZER DRAGOONUno de los emblemas de la Saturn. El juego corre todo el 3D desde el VDP1, el VDP2 se encarga del cielo, el mar, las paredes de los interiores.
Esto es lo que vemos en el juego:
Esto es lo que renderiza el VDP1:
Tenemos al protagonista, a los enemigos, los objetos 3D del escenario y los marcadores.
Realmente no hay “tanto” 3D, la carga es mucho menor que en el Daytona USA por poner un ejemplo, pero la imagen final queda perfecta, muy bonita.
Como curiosidad los reflejos sobre el mar están hechos por el propio VDP1, pero no es una distorsión real, son sprites ya hechos con esa forma:
Esto es lo que hace el VDP2:
El mar está animado, es un plano abatido que además tiene un efecto sobre el propio fondo que simula el oleaje. Desde luego queda bonito y da el pego. En movimiento:
SONIC RSonic R es un juego de carreras con algunas cosas interesantes a comentar.
Aquí dos vídeos del creador donde podemos verlos:
https://www.youtube.com/watch?v=WDJgeuoaSvQhttps://www.youtube.com/watch?v=RvRG_v8XpC0Para empezar tenemos un par de pantallas donde tenemos objetos 3D con reflejos “metálicos” (environment mapping), con la cabeza de Sonic o la R del logo del juego.
Este efecto no puede hacerse por HW en Saturn (pero sí en PlayStation).
Lo he señalado con las flechas:
Para conseguir este efecto, el equipo de desarrolladores hicieron un motor de renderizado por triángulos similar al que tiene la Playstation, que corre en el SH-2 esclavo. El SH-2 maestro, mientras tanto, puede correr otro código en paralelo.
El motivo de hacer un motor propio es la forma que tiene la Saturn de trabajar con polígonos texturados. El VDP1 coge un polígono y le aplica la textura al polígono, completa, pero no puedes coger un trozo determinado de la textura, solo podría cortarla y en forma rectangular. En el caso de la pantalla de carga (donde vemos a Sonic, Tails y Knuckles), la R tiene un reflejo. El reflejo es de esta textura:
Lo que hace el motor software es coger un trozo determinado de esa textura (en el frame que he capturado parte de la cara de Sonic), aplicarle un efecto y luego encajar ese trozo en la “R”. A medida que se mueve la “R”, el trozo que se refleja cambia. El VDP1 te obliga a coger toda la textura entera.
En el caso de la cabeza metálica, a lo Terminator T-1000, sucede lo mismo. Curiosamente el creador comenta en el vídeo que no usaron este efecto en el juego, sólo en las pantallas de carga. Imagino porque con ese procesado ya saturan el SH-2 esclavo.
Como prueba, aquí podemos ver que no hay polígonos, es el SH-2 esclavo el que crea, al vuelo, el sprite:
En cuanto al juego en sí, utiliza muy bien todos los recursos de Saturn.
Veamos esta pantalla:
Tenemos personajes 3D (como Sonic), hecho por el VDP1.
El camino también 3D, también VDP1. De forma inteligente este juego aplica a la parte final del camino (y de todo escenario 3D), transparencia sobre el fondo (no se ve mucho en la captura). De esta forma no aparece “de golpe” como en Daytona USA.
El agua y sus reflejos son cosa del VPD2, como en Panzer Dragoon. Veamos una captura sin el VDP1 (solo VDP2):
En una capa los marcadores, en otra el fondo, en otra el agua… muy bien repartido.
Hay un nivel secreto lleno de transparencias y efectos de colores.
BONUS: Entrevista con Ezra Dreisbach, desarrollador. Voy a extraer algunas frases de una entrevista a un desarrollador de Saturn.
Powerslave y Duke Nukem 3D en PC fueron creados con el mismo motor. ¿Se usó ese motor para portar juegos a la Saturn? Ambos juegos fueron rehechos desde cero en Saturn. No hay código compartido con las versiones de PC. Esos juegos (PC) funcionan de una manera diferente a como funciona la Saturn, así que no hay manera de portar un juego, hay que rehacerlo. Hacer ports no es el trabajo más rentable desde el punto de vista financiero o personal…
Además de las texturas y los modelos 3D,¿qué más aprovechasteis de la versión PC? Para Quake, todos los niveles fueron reconstruidos a mano utilizando una herramienta de creación que llamamos "Brew". En Duke Nukem, pudimos pasar los datos de los niveles usando esa herramienta, pero aun así requirió mucho trabajo a mano.
¿Qué opinas sobre Saturn y PSX? Hice algún trabajo para la PSX después (de trabajar con Saturn). Después de terminar Quake para Saturn, hice un port rápido en la PSX. Lobotomy (la compañía donde trabajaba) necesita dinero urgentemente, tenía la esperanza que podrían contratarnos para portar Quake a la PSX, pero nadie lo hice y la compañía se hundió.
Un port de Quake para PSX? Hubiese sido muy interesante ver Quake en PSX para poder comparar las tres consolas de su generación… ¿puedes comparar la versión de Saturn y la de PSX y, si la viste, la de N64? Lo más sorprendente de PSX era lo rápido que era en gráficos comparado con Saturn. La escena inicial iba a 20fps en Saturn, en PSX iba a 30, pero podría haber alcanzado, quizá, a 60 (era un port rápido). Quizá no 60, pero tenía potencial
Por otro lado, eran idénticas, aunque los colores se veían mejor en PSX.…PSX es más simple y más rápida. Hay un montón de cosas absurdas en Saturn. Lo principal es que no puedes dibujar triángulos, sino quads.
Creo que he visto un ejemplo de ello en Tomb Raider. Al principio del juego, en las cuevas, puedes encontrar unas rocas triangulares. En la versión PSX, una textura rectangular fue cortada por su diagonal y mapeada en un triángulo. En la versión de Saturn, tuvieron que mapear toda la textura en el triángulo, poniendo uno de los vértices encima de otro (un triángulo puede verse como un cuadrilátero con un lado de tamaño cero). Sí, es un buen ejemplo. Para que se vea bien has de, previamente, pre-distorsionar la textura de forma que cuando la distorsiones se vea de la forma correcta. Nosotros tuvimos que hacer eso para los monstruos de Quake de Saturn.
Creo que se refiere a esta roca (aunque hay varias parecidas).
Interesante el hecho de que para hacer triángulos “plegaran” uno de los lados del cuadrilátero.
BONUS: Entrevista a HIDEKI SATO, el arquitecto.Hideki Sato es una leyenda segera. Dirigió el departamento de I+D de Sega durante la época del auge de los 16 bits y más tarde se convirtió en el presidente de SEGA en 2002. Pensé que sería interesante recabar declaraciones suyas sobre la Saturn. Este es un extracto una interesante entrevista.
En inglés
http://shmuplations.com/segahistory/En español
http://overdrivengamers.com/retro/2018/ ... ideki-sato
“Estábamos entonces en el proceso de investigar qué tipo de juegos podríamos crear usando la tecnología CG. Juegos de conducción, simuladores de vuelo, pero ¿qué más ...? Yu Suzuki estaba trabajando en un proyecto experimental para renderizar y animar humanos en 3D CG. Finalmente nos mostró en qué había estado trabajando, y todos vimos algo que antes habíamos creído imposible: figuras humanas realistas representadas en CG. Una vez que vimos eso, ya no nos preocupamos por los tipos de juegos que podríamos hacer con esta nueva tecnología.
Al principio, no pudimos decidir qué formato de medios usar para nuestro nuevo sistema de 32 bits: cartucho o CD-ROM. Internamente, llamamos a la versión de cartucho Júpiter, mientras que la versión de CD-ROM se llamaba Saturn. Trabajamos en ambos sistemas en paralelo hasta la mitad, cuando la mayor capacidad de almacenamiento de CD-ROMs ganó.
También nos quedamos estancados en sí enfocarnos en el desarrollo de juegos en juegos basados en sprites o en nuevos juegos 3D de CG. Los juegos basados en Sprite fueron lo que Sega había hecho hasta entonces, teníamos mucha experiencia acumulada en ellos, tanto en el sentido personal como tecnológico; Parecía un desperdicio simplemente tirarlo todo. Y Sega sólo tenía algunos equipos internos trabajando en el diseño de juegos CG. Por lo tanto, decidimos darle al Saturn la capacidad de manejar ambos tipos de juegos, con un robusto motor de sprites y un motor CG. Sin embargo, aunque habíamos separado los dos motores lo suficientemente bien en el sentido del hardware, la creación de juegos para el Saturno resultó ser un poco difícil. Las bibliotecas de desarrollo de software también fueron insuficientes, las 3rd parties se quejaban de que era un sistema difícil de desarrollar. Vendimos 5 millones de sistemas en Japón, pero tuvimos problemas en el mercado de ultramar.”
[...]
“Cuando Saturn comenzó a ser diseñado, la industria de los videojuegos estaba justo en la transición de los sprites al CG. En el mundo de los arcades, podías notar el contraste entre las placas System 32, capaces de desplegar 300,000 sprites, y las placas Model 1 que corrían al Virtua Fighter y mostraban el futuro de los polígonos. Para no perder estos logros y el cómo se hace que habíamos adquirido los años anteriores, nuestra primer idea fue basar el Saturn en las placas System 32, pero inevitablemente nos dimos cuenta de que sería mejor tener polígonos y CG también, así que incluimos ambas capacidades en el diseño. Fue hecho con el espíritu de tener lo mejor de ambos mundos, pero también sentimos como que estábamos separándonos de nuestro bebé, sin hacer justicia a ninguno. (risas)
Habían dos candidatos para la CPU. El primero, por el que Sega de América estaba pujando, era el 68020. Tenía una buena compatibilidad con el 68000 y sería fácil de usar, pero sus limitaciones estaban claras. La otra opción era una CPU RISC: parecía más potente, pero por varias razones, el riesgo era más alto (¡justo como el nombre “RISC” lo decía!). Como siempre ha sido en Sega, necesitábamos una consola casera que fuera lo suficientemente poderosa para hacerse cargo de nuestros ports. Siendo ese el caso, tomamos el camino arriesgado pero realista y elegimos el procesador RISC, el SH2 de Hitachi.“ BONUS: PANORAMA ARCADEMucha gente se pregunta porqué SEGA no hizo como con megadrive, simplificar una de sus placas recreativas. Aquí salen todas.
https://en.wikipedia.org/wiki/List_of_S ... tem_boardsSaturn fue concebida al final de la época de las máquinas basadas en sprites y en el inicio de la era poligonal. SEGA tenía en la System 32 su plataforma arcade basada en sprites, y más tarde lanzaron la model 1 y la model 2, que lo cambiaron todo.
La
System 32 (Golden Axe: The Revenge of Death Adder) , lanzada en los 90, combinada características de placas anteriores de SEGA. Era una máquina de capaz de manejar sprites como nadie, con capacidades para rotar, escalar, mezclar colores, manejar varios planos de scroll,etc. No tenía capacidades 3D.
CPU: NEC V60 a 16Mhz ( 3.5 MIPS)
GPU: Sega Super Scaler chipset. 4 backgrounds tiles, 1 capa texto, 1 capa bitmaps, 2 capas de sprites...Hasta 512 colores por sprite.
SONIDO: 2× Yamaha YM3438 + Ricoh RF5c68
MEMORIA: 584 KB de memoria principal, 320 KB de memoria video, 768KB framebuffer,...
La
model 1 (Virtua Racing) , lanzada en el 92, fue revolucionaria, y por supuesto cara.
Estaba enfocada a los juegos poligonales y su precio era prohibitivo. Más allá de sus capacidades poligonales, tal y como está hecha no parece adecuada para el mercado doméstico. No puede manejar texturas, soporta 65K colores (que está bien pero los 16M eran, bajo mi punto de vista, indispensables), no tiene nada pensado para sprites (que era la norma), muy poca memoria para juegos de sprites.
CPU: NEC V60 a 16Mhz ( 3.5 MIPS)
GPU: 5 x Fujitsu TGP MB86233 (geometría, rasterización, DSP, cálculos en coma flotante, cálculo de matrices 3D, rotaciones). Hasta 65K colores.
SONIDO: Motorola 68000 + 2 chips customs de SEGA.
MEMORIA: 408 KB de memoria ppal, 1464 KB SRAM (192 KB display list, 576 KB tiles, 64 KB colors).
Lanzada en el 93, la
model 2 (Daytona USA) , una placa MUY burra, MUY cara, MUY potente.
CPU: Intel i960-KB ( 25 MIPS, 13.6 MFLOPS)
GPU: 6 x Fujitsu TGP MB86234 (geometría, rasterización, DSP, cálculos en coma flotante, cálculo de matrices 3D, rotaciones) + Sega/Lockheed-Martin (rasterizador,texture mapping) + 2 x Fujitsu MB86272 (Z-buffer) + Sega System 24 Tilemap Engine.
SONIDO: Motorola 68000 + 2 chips customs de SEGA.
MEMORIA: 1152 KB de memoria ppal, 5984 KB (1MB framebuffer, 4MB texturas,...)
Saturn es lanzada en el 94, y es superior a la model 1. Saturn es inferior a la model 2, que puede tener una cpu menos potente, pero tiene chips de manejo de geometría, coprocesadores en coma flotante capaces de hacer cálculo de matrices 3D por HW, rasterizadores, etc. Creo que era imposible simplificar la model 2 para tuviese un precio atractivo para el mercado doméstico.
CONCLUSIONESVamos ahora a contestar a la preguntas que hicimos al principio del texto.
¿Por qué tiene una doble CPU y una doble VDP? Porque en SEGA pensaron en segmentar el trabajo, repartirlo entre varios procesadores y que el trabajo se hiciera por etapas. Como en una línea de producción, pero con la versatilidad de un producto hecho a mano, la consola se presta a un control casi total por parte del desarrollador. No es mala idea pero tal y como está implementado el HW tiene sus defectos.
¿Es un sistema difícil de programar? Sí. Al principio de vida de la consola programar en C era posible, pero no todo y con un rendimiento alejado del que podrías obtener en ensamblador. Kits posteriores de las librerías de C de SEGA paliaron este defecto.
De cualquier forma había que lidiar con las colisiones del doble procesador, los defectos al pintar sprites deformados, los problemas de las transparencias, etc.
¿Puede hacer transparencias? Sí, es posible, pero en situaciones complicadas, con muchos sprites en pantalla o entornos 3D, lo tenemos difícil. Normalmente los desarrolladores usaban tramas y transparencias sólo cuando la situación no era proclive a problemas.
¿Es verdad que era un sistema pensado para el 2D y no para el 3D? Era un sistema versátil. Para 2D cojonudo, para 3D no tenía nada específico, simplemente confiaba en la capacidad de cálculo de los SH-2, que no era mala, no hay tanta diferencia con la Playstation. Y desde luego era mucho mejor que las otras consolas de la época (3DO, Jaguar).
¿Sus juegos representan el techo del HW o hay espacio para la mejora? Comentar que el SCU no es un recurso que pueda explotar demasiado porque no tiene memoria suficiente excepto para ayudas puntuales. En general yo creo que se rascó el techo en juegos como Burning Rangers o VF2.
Preguntas ya contestadas. Si buscamos por internet números leemos:
La Saturn tiene una cpu que rinde 25 MIPS (por cpu), el VDP1 puede poner hasta 500.000 polígonos planos, 200.000 con texturas, 140.000 con goraud.
La Playstation tiene una cpu que rinde 30 MIPS y su GTE puede manejar 360.000 polígonos planos o 180.000 con texturas.
La N64 tiene teóricamente una cpu y una gráfica bastante superior a las dos anteriores.
Entonces, ¿cómo es que la PlayStation tiene fama de manejar 3D mucho mejor que la Saturn?¿Cómo es que la N64 no tiene juegos muy superiores a la Playstation, o se cuentan con los dedos de las manos?
Tener procesadores potentes, buses rápidos y anchos, mucha memoria… todo esto es muy importante pero son las
cosas pequeñas las que acaban limitando un HW.
Saturn puede tener unos VDPs potentes y sofisticados, pero todo eso da igual si luego las cpus, que son las encargadas de la geometría, no igualan la capacidad de cálculo de las otras consolas. Si puedes aplicar efectos varios con los VDPs pero hacerlo te penaliza enormemente, al final o lo haces poco o no lo haces. Y Saturn tiene muchas pequeñas cosas a tener en cuenta.
En mi opinión,
Saturn es la última de las consolas clásicas 2D de sobremesa, sigue basándose en los sprites-para-todo, 2D y 3D, los “quads” parecen el paso lógico desde los sprites al 3D, para Saturn son (casi) lo mismo. Es su virtud y su principal problema.
Cambiar esto significa cambiar el enfoque entero de la consola. No obstante si hubiese sido más fácil de programar (1 cpu más potente o con un procesador de geometría adicional, 1 super-vdp ) estoy seguro que los famosos quads no hubieran representado un problema para los desarrolladores.
Espero que os haya gustado este análisis, me dejo muchas cosas por comentar y seguro muchos errores por subsanar.
Gracias por vuestra atención.
![[oki]](/images/smilies/net_thumbsup.gif "Ok!")
Que gran consola la Saturn. En su época no la supe valorar, en parte por el desprecio que sufrió por parte de la propia Sega aquí en Europa, y porque Playstation arrasaba (y porque fui muy Nintendero en mi infancia, todo hay que decirlo... 
) pero cuando descubrí su increíble catalogo japonés, me reencontré con esta pedazo de maquina, y a día de hoy es de las que más cariño le tengo.
![[carcajad]](/images/smilies/nuevos/risa_ani2.gif "carcajada")
![[facepalm]](/images/smilies/facepalm.gif "facepalm")
![[plas]](/images/smilies/aplauso.gif "Aplausos")
![[qmparto]](/images/smilies/net_quemeparto.gif "Que me parto!")
![[beer]](/images/smilies/nuevos2/brindando.gif "brindis")
![[tadoramo]](/images/smilies/adora.gif "Adorando")
