Flangolinos y las mentiras de la Next Generation sobre Sega Saturn

Comentario original:

😮 cuando dijiste que aún quedaban entradas sobre los gráficos en consolas antiguas, pensé que como mucho te quedaban la 3do,atari jaguar y alguna portatil, no pensé que harías también de estas consolas.

Dado que en noticias no hay nada interesante y he perdido la fe después de los del GamerGate, he decidido ampliar la serie hasta finales del S.XX y hacer otra serie paralela (la de rarezas japonesas), pero tengo que aclarar que es una serie prototipo para algo que publicare en unas semanas (o meses) y no será en el blog precisamente.

Un par de preguntas a todo esto, decís que la consola tuvo algunos errores de diseño y ello llevó a varios problemas, pero el 1er error no sería ya de entrada el haber usado el sh 2 como procesador y encima doble?….recuerdo que dijiste que era odiado por muchos desarolladores, de entrada lo mejor no hubiese sido usar una sola de esas fpu de fujitsu que había en la model 1?….y por supuesto una única cpu distinta.

El problema es que la gente toma como referencia la PlayStation de Sony cuando realmente si te fijas en el diseño de Saturn parece una consola que fue desarrollada para competir contra la 3DO.

Sony presento su PlayStation en Noviembre de 1993 y Sega en el CES de Enero de 1994 ya tenía la Saturn definitiva, demasiado poco tiempo como para lo del doble procesador venga de ahí y al final si usas la cabeza en vez de asentir te das cuenta que esa historia no cuadra para nada y que se hizo para darle mala propaganda a Saturn.

¿El origen de dicha historia? La revista Next Generation, la misma que:

¿El problema de Sega? Que a nivel de hardware y para la época la PlayStation era sublime y eso acabo eclipsando a Saturn que en potencia no estaba precisamente manca y estaba muy por encima de lo que se había visto hasta la época, pero claro llego la PlayStation de Sony y el impacto fue tal que dejo al hardware de la consola de Sega como ineficiente. La historia de Next Generation sobre el doble procesador de Saturn dijo lo siguiente:

Next Generation1 (2): 36–43. Febrero 1995 . ” La reacción de Sega fue retrasar el programa de desarrollo de Saturn por unos meses e incorporar un nuevo procesador de video en el sistema, esto no solo mejoraría las capacidades 2D de la consola considerablemente (algo en lo que la máquina de Sony es menos buena en ello), pero que le daría un mejor mapeado de texturas para los gráficos en 3D”.

Hablan de un doble procesador gráfico, no hablan de una doble CPU. Es más, esa historia es un bulo por un motivo muy simple, nadie se inventa un chip a medida en pocas semanas y lo coloca en una máquina. Es físicamente imposible, lo triste es que durante años muchos nos hemos creído ese bulo como sí fuese verdad sin contrastarlo ni una sola vez y hemos ido todos como borregos y entre ellos me incluyo.

Yo me pregunto porque Sega no incorporo un co-procesador al estilo GTE dentro del SH2, esto habría tenido mucho más sentido que no lo que hizo Sega con el doble procesador, pero creo que el motivo de no hacerlo es lo siguiente:

  • Un cambio así en un procesador requiere una mayor cantidad de tiempo ya que se ha de volver a la mesa de diseño.
  • Un segundo SH2 al ser un procesador de propósito general da mucha más versatilidad en el código y es posible que los programadores de Sega prefieriesen tener esa versatilidad antes que una unidad especializada.

Una vez lei en Sega-16, que el motivo por el cual Saturn tenía doble procesador y no un SH2 con su propio “GTE” es que Sega puso un limite al tamaño de los chips con tal de que le salieran más baratos, no se hasta que punto esto es verdad pero viendo como la placa base de Saturn son muchos chips pequeños en vez de pocos y grandes es posible que haya algo de verdad en eso.

La otra pregunta es que comúnmente se dice por ahí que saturn se programaba en ensamblador y esto dificultaba más el desarollo de juegos, es cierto esto?…me cuesta creerlo, yo pensaba que se programaba en C también como en ps1, pero al tener estas cosas que comentaste, había que sudar más y reescribir código para conseguir ciertos niveles visuales en lo que al 3D respecta.

Era un popurri, ciertas partes se programaban en ensamblador y otras partes se programaban en C.

  • EL SCU/DMA y el SCSP (chip de sonido) se programaban en el ensamblador de los respectivos chips.
  • Los Hitachi SH2 se podían programar en ensamblador o en C, según convenga. Sega proveía una versión del compilador de C de la GCC

¿Y los gráficos? Ah, bendita ignorancia y manía de no documentarse:

SaturnSGL

 

Sega tenía una librería en C llamada SGL incluida en el SDK de Saturn para programar los gráficos en 3D a tiempo real en la consola. Es cierto que al principio estaba falta de librerías que permitiesen aprovechar bien el hardware, pero ahí a decir que durante toda su vida se tuviese que programar en ensamblador y Sega s quedase de brazos cruzados como que no. La gente olvida que la forma en la que Sony se gano a los desarrolladores fue con una librerias y herramientas de alta calidad que permitían hacer las cosas en menos tiempo y ya se sabe que tiempo=dinero.

En todo caso el SGL no salvo a Saturn.

Y por último, viste que en los juegos de saturn (y de ps1 también) pareciera que todo se mueve como si fuese gelatina? 😛 como que tiemblan las cosas, estoy en lo correcto si digo que esto es porque no soportan coma flotante?, es por eso?.

En fin, muy buen articulo, saludos!.

(La información a partir de este punto es errónea respecto a la forma en la que PlayStation y Saturn renderizan la escena, perdonad las molestias)

Es más bien por la falta de un búfer de profundidad, dicho búfer es un mapa de la imagen que a través de un valor por pixel no marca el color sino la distancia en la que se encuentra respecto a la cámara, cuando PlayStation y Saturn fueron lanzadas esa técnica era prohibitiva y no se incluyo. En N64 lo continuo siendo (recortaba su tasa de relleno enormemente) y en algunos juegos de N64 se tiro por una medida mucho más simple que son los Arboles BSP (Arbol de partición binaria), pues bien, dicha técnica era utilizada en PSX y Saturn para colocar los elementos en la escena pero no era tan precisa como el hecho de tener un búfer de profundidad.

Al utilizar un arbol BSP se renderiza desde delante hacía atrás:

 Si te das cuenta la vision de la cámara de la escena es la siguiente:

BSP2

 

Por lo que podemos representar la posición de los objetos en un arbol binario donde el nodo raiz sea donde se encuentra la cámara:

arbol-binario

Tan pronto como los sistemas pudieron utilizar el búfer de profundidad de forma rápida y eficiente esta técnica se fue olvidando, durante un tiempo para ganar precisión se combino con el búfer de profundidad para ganar precisión, pero una vez dicho búfer alcanzo los 24 bits de precisión ya no fue necesario el uso de arboles BSP. Por otro lado lo de la coma flotante es un medio bulo porque  N64 tampoco soportaba coma flotante, pero hacía uso de una técnica llamada Corrección de Perspectiva para que las texturas no bailaran, claro esta que para aplicarse necesitaba la información del búfer de profundidad. La corrección de perspectiva también se encuentra en NintendoDS que no soporta coma flotante pero sí soporte para un búfer de profundidad por hardware (aunque la forma de renderizar de DS requiere una entrada aparte).

La explicación correcta en una futura entrada.

Anuncios