SATURN - BONUS Y CONCLUSIÓN

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 ARCADE

Mucha 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_boards

Saturn 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, Virtua Fighter), 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, no tiene soporte para manejar sprites por HW.

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, VF2), una placa MUY burra, MUY cara, MUY potente. Polígonos y mapeado texturas.

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.

CONCLUSIONES

Vamos 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 completo 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.