SATURN - TERCERA APROXIMACIÓN: Infierno

BLOQUE CPU

Ampliemos 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.pdf
Ventajas 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 VIDEO

Vamos a ver cómo se hacían algunos efectos con los VDPs.

TRANSPARENCIAS

Saturn 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 Boy
https://www.youtube.com/watch?v=f_OchOV_WDg

Os 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 2D

fuente: 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 mata marcianos 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 3D

En 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 TV

Justifiquemos 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 CODES

Saturn 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 SONIDO

Saturn 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 ELEMENTOS

Esta es la placa base de Saturn (revisión VA8):

Obviemos la parte trasera (que tiene algunosrevisiones 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.

CONCLUSIONES

Los 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