Sega Saturn al límite (V)

david.gamiz.jimenez david.gamiz.jimenez

Aviso entrada muy larga. En esta entrada he usado mucha información, compleja y en algunos aspectos poco precisa. Es posible que haya cometido errores de interpretación o entendimiento. Procurare corregir todo aquello que surja.

En esta hoja de cálculo tenéis los datos que he recopilado de 323 juegos. De los aprox. 1200 títulos en total. Que son un 20% aprox. del total:

Indice:

  1. Lo imposible de solventar: Triángulo vs Cuadrángulo.
    1.1 Triángulo vs Cuadrángulo – Bola EXTRA: Mapeado UV
  2. Lo menos complicado: Sombreado Gouraud e iluminación dinámica a color.
  3. Lo complicado I: Suavidad en juegos 3D = 500 / 1.000 / 1.500 / ~2.000 quads frame = 25/30/60 FPS estables.
    3.1 Lo complicado I – Bola EXTRA I: Uso del SCU-DSP
    3.2 Lo complicado I – Bola EXTRA II: Resolución pantalla SD/HD
    3.3 Lo complicado I – Bola EXTRA III: Teselación / LOD escenario / Mip Mapping
  4. Lo complicado II: FMV pantalla completa y calidad color.
    4.1 Lo complicado II – Bola EXTRA I: Función Calculo Color Avanzado “Gradation / Boken / Blur”
  5. Lo complicadísimo: Transparencias y/o semi-transparencias
    5.1 Transparencias y/o semi-transparencias – Bola EXTRA I: Transparencias + Gouraud = «Table FOG» o Depth Cueing
    5.2 Transparencias y/o semi-transparencias – Bola EXTRA II: Reflejos en suelos
  6. Lo complicadísimo II: Render-to-texture
  7. Lo difícil de «ver»: Efectos de sonido de Reverberación y/o Echo
    7.1 Lo difícil de «ver» – Bola EXTRA I: ADPCM y CD-ROM XA
  8. Lo difícil de “cargar”: Carga sin parar el juego
    Conclusiones
    Epilogo
    Referencias
    Glosario

5.1 Lo complicadísimo – Bola EXTRA I: Transparencias+Gouraud=»Table FOG»/Depth Cueing

Como ya hemos hablado antes combinar la transparencia con el Gouraud daba lugar a efectos muy interesantes y espectaculares. Pero sin duda uno de los más llamativos era este: Table FOG»/Depth Cueing

En PSX podemos leer como efecto posible o incluso ver juegos con efectos de «Table FOG». En realidad no era una feature como tal en la máquina. Está al poder calcular muy eficientemente Semi-Transparencias(en varios modos y capas) y poder hacer sombreado Gouraud, como SS. Combinaba ambos efectos sobre el Frame buffer único de la PSX, para lograr un «Table FOG» prácticamente igual. Usando de forma simplificada y accesible por los desarrolladores mediante una función que llama «Depth Cueing» que usaba el GTE.

En la SS que es lo que nos interesa, ¿fue posible? La respuesta es SÍ. Finalmente ya en la versión 3.0 del SGL de SEGA, se incluyó una función de igual forma que PSX. Llamándose incluso igual.

Se hizo de manera similar. Como en todo en SS, usando el VDP1 o VDP2 o sumando ambos. Hay algún juego que lo consigue muy bien. En el caso de la Saturn al carecer de Frame buffer único, y de las restricciones de sus modos de transparencia. El efecto no es igual de espectacular que el de PSX, pero en esencia, de nuevo, es lo mismo. Funcionaba de la siguiente manera:

Los polígonos más lejanos iban tomando un color similar a un color de horizonte o fondo. Y cuando se aproximaban al clipping de horizonte (zona de popping o generación del escenario) estos se desvanecían con un color de niebla(normalmente negro o blanco) con una transparencia del VDP1 o usando el modo mesh. O en el mejor de los casos usando la Semi-Transparencia VDP1>VDP2, vista en Sonic R. La suma de color degradado parecido al fondo más el uso de la transparencia o mesh, daba la sensación de que se perdía e el horizonte como si fuese niebla.

Una pequeña mejora de la anterior, era además de dar un color degradado en función de la distancia al horizonte. Añadir degradado en el polígono con Gouraud shading, así se suavizaba aún más el color en transición al fondo. Si esto le sumamos hacer transparencia sobre los valores del Gouraud el desvanecimiento es total. Aquí de nuevo nos encontramos que la SS lo hacía, con sus limitaciones. Y que PSX lo conseguía con mejor calidad final.

Claro, los desvanecimientos con la transparencia de SS, que no es a nivel de triángulo, y que en el caso del VDP1 generaba errores de cálculo, no mostraban una acabado final perfecto. Si usaban el mesh, mejor en un sentido(rendimiento) peor en otro(estético). Pero en esencia en PSX se hacía lo mismo. En el mejor de los casos en SS, sumando al uso de la VDP1, se usa finalmente la transparencia del VDP2, que es el caso de Sonic R, el efecto es limpio y además con transparencia gradual al usar la posibilidad de hasta 8 simultáneos de los 32 niveles de alpha de este chip. El efecto es muy suave, el mejor. Queda la duda de si era posible usar el modo “as is” para conseguir subir los niveles al máximo, 32 posibles. Usando el Gouraud en el VDP1 para que después con la mezcla del VDP2 interprete estos niveles de brillo como niveles de transparencia gracias a la mezcla aditiva.

Otros juegos, solo usaban el degradado de color hasta el color final del horizonte. Y ahí ya dejaban de dibujar el polígono. Es un efecto más sencillo y menos espectacular. Pero menos costoso para la máquina. En PSX también se usaba de la misma forma. Si el fondo es muy oscuro o con un color plano, sin textura. Se podía eliminar el uso de Semi-Transparencia, pues no aportaba nada y es un proceso caro.

También tenemos el caso de usar en una Screen/Pantalla del VDP2, normalmente una RGB, un degradado de horizonte, usando la opción de Line Color Screen Insertion para simular este efecto. La cual se podía definir a qué Screen o Screens afectaría. El efecto es limitado y muy plano. Pero a nivel de pixel, por línea. Y se puede usar junto con la Función de Cálculo de color para hacer transparencia en varias capas. Pudiéndose sumar esta a otra transparencia de capa de VDP2 normal(CC VDP1 incluida y sus variantes).

Por último también hay casos que usan un efecto aún más plano y sencillo usando el VDP2. Que es usar una Screen/Pantalla con transparencia una superior al fondo. Aparece en juegos donde la cámara no rota en su eje normal o donde la niebla está lejana o en el fondo “3D”. Lo he visto solo en unos pocos juegos.

Al final se trata de disimular el «popping» de la mejor manera posible. Al día de hoy se sigue usando, mucho menos… pero la generación de geometría no es infinita en ningún sistema.

¿Al final se consiguió arreglar esta situación de desventaja?

Podríamos decir que SI. Aunque, ante la falta de una fácil implementación desde el inicio, no había un criterio unificado. Dando como resultado resultados dispares.

He llegado a verlo en un 37% del total de juegos analizados. La mayoría de ellos con el VDP1 solo en un 50%. Algunos con el VDP1+VDP2 llegando al 45%. Y también solo usando el VDP2 de alguna de sus formas en un 5%.

Pasemos ahora una lista por tipo y fecha cronológica:

Juegos con efecto en 3D usando VDP1:

  • 1994
    • Gale Racer
  • 1995
    • Panzer Dragoon→ Cambio de paleta y LOD.
    • Robotica: Cybernation Revolt
    • Bug!
    • Off World Interceptor Extreme
    • Touge King – The Spirits / High Velocity: Mountain Racing Challenge
    • Dragon Ball Z: Shin Butōden
    • Hi-Octane
    • Black Fire
    • Devil Summoner: Shin Megami Tensei
  • 1996
    • GunGriffon
    • Panzer Dragoon II Zwei
    • Magic Carpet
    • Shellshock
    • Lifescape – Seimei 40 Okunen Haruka na Tabi Disc 1
    • Lifescape – Seimei 40 Okunen Haruka na Tabi Disc 2
    • Dragon Ball Z: Idainaru Dragon Ball Densetsu
    • Starfighter 3000 (Star Fighter)
    • Alien Trilogy
    • NiGHTS into Dreams
    • Shockwave Assault
    • Blam Machinehead
    • Dark Savior
    • Exhumed (E) / Powerslave (U)
    • Space Hulk: Vengeance of the Blood Angels
    • Tunnel-B1
    • Tomb Raider
    • Street Racer (Extra)
    • Hardcore 4×4
    • Bug too!
    • Black Dawn
    • Shining the Holy Ark
  • 1997
    • Die Hard Trilogy
    • Scorcher
    • Crypt Killer
    • Gundam Side Story 3   Kidou Senshi Gundam Gaiden III: Sabakareshi Mono
    • Independence Day
    • Doom
    • Touge King the Spirits 2
    • Krazy Ivan
    • Sonic Jam→ World 3D Area
    • Zero4 Champ Doozy J Type-R
    • Bulk Slash
    • Lifescape 2 – Body Bionics – Kyoui no Shouuchuu Jintai
    • Söldnerschild / Soldnerschild
    • NBA Action 98
    • Steep Slope Sliders
    • Duke Nukem 3D
    • Devil Summoner: Soul Hackers
    • Sonic R
    • Quake
    • Courier Crisis
  • 1998
    • Solo Crisis
    • Panzer Dragoon Saga
    • Stellar Assault SS
    • GunGriffon II→ Gouraud en objetos 3D
    • Baroque
    • Akumajo Dracula X: Gekka no Yasokyoku (aka: Castlevania: Symphony of the Night)
    • Code R

Juegos con efecto en 3D usando VDP1+VDP2:

  • 1996
    • GunGriffon (1996-03)→ Polígonos planos con transparencia en VDP2 ?
    • NiGHTS into Dreams (1996-07-05) → VDP1>VDP2 cc+ratio 8x Poligon flat degrade horizon over RGB0
    • Street Racer Extra (1996-11) → Depth cueing con transparencia VDP1+VDP2 en near clipping.
  • 1997
    • Doom (1997-03-26) → Depth cueing VDP1+VDP2.
    • Bulk Slash (1997-07-11) → Solo en algunos niveles sobre los layers del VDP2 como Sonic-R. En el resto posiblemente contra el Back Buffer.
    • Sonic R (1997-11) → en el último circuito, que es entero transparente. ¿Tiene menos niveles de degradado en el fundido o no tiene?
  • 1998
    • GunGriffon II (1998-04) → Polígonos planos con transparencia en VDP2

Juegos con efecto en 2D/3D usando VDP2: Line Color Screen Insertion (Difícil de detectar, lista aproximada):

  • 1994
    • SEGA GAME SAMPLE 1→Windows+screens y alfombra voladora.
  • 1995
    • Panzer Dragoon 1995-03-10
    • Wing Arms 1995-09-29
  • 1996
    • Guardian Heroes 1996-01-26
    • GunGriffon 1996-03-15
    • Panzer Dragoon II Zwei 1996-03-22
    • Dragon Ball Z: Idainaru Dragon Ball Densetsu 1996-05-31
    • NiGHTS into Dreams 1996-07-05
    • Decathlete / Athlete King 1996-07-12
    • Battle Arena Toshinden URA 1996-09-27
    • Street Racer (Extra) 1996-11-16
    • Sega WorldWide Soccer 97 / Victory Goal ’96 1996-11-29
    • Shining the Holy Ark 1996-12-20
  • 1997
    • Shinrei Jusatsushi Taroumaru 1997-01-17
    • Gundam Side Story 3 Kidou Senshi Gundam Gaiden III: Sabakareshi Mono 1997-03-07
    • Independence Day 1997-03-15
    • Doom 1997-03-26
    • J League – Go Go Goal! 1997-05-30
    • D-Xhird 1997-05-30→ Algunos escenarios
    • Sonic Jam 1997-06-20
    • Bulk Slash 1997-07-11
    • Thunder Force V 1997-07-11
    • G-Vector 1997-10-16
    • Sega Worldwide Soccer 98 / J. League Victory Goal ’97 1997-10-16
    • J.League Pro Soccer Club o Tsukurou! 2 1997-11-20
    • Sonic R  1997-11-21
  • 1998
    • Panzer Dragoon Saga 1998-01-29
    • Dragon Force II 1998-04-02
    • Savaki 1998-04-16
    • Gungriffon II 1998-04-23
    • World League Soccer 98 1998-06-05
    • Radiant Silvergun 1998-07-23
    • Pro Yakyuu Greatest Nine ’98 Summer Action 1998-08-06

Juegos con efecto en 2D/3D usando VDP2: Screen/Pantalla con transparencia superior:

  • From TV Animation Slam Dunk: I Love Basketball → Efecto en parque
  • D-Xhird → Nivel con niebla en el fondo.

De nuevo me quedo con una selección de tres juegos, que son buenos representantes de este apartado y como juegos para el sistema:

  • Blam MachineHead

    Lanzado en el 1996-08-30 es un juego de la 3ª ola de desarrollos third party Europeos. En este caso Core Design y sus componentes ya demuestran un conocimiento de la máquina sobresaliente. Un juego con un motor 3D realmente potente, pero con decisiones de base pensando en PS1 y PC que perjudican claramente el acabado final. Aunque fue lanzado primero en SS, 2 meses antes. No sabemos si como parte de los primeros acuerdos que SEGA tuvo con Core Design, como para el Tomb Raider. Tampoco podemos saber como perjudico esto también, al ser lanzado antes. Pero este Blam Machinehead si parece estar bien pulido, aunque mejorable.

Blam Machinehead posee un motor que mueve sin problemas, al menos, 800 quads con textura y Gouraud vistos en pantalla. Puede que más. Calculados 1100 aproximadamente. De los cuales aproximadamente 100 quads vistos son del vehículo y sus armas. Bien es cierto que a 20FPS totalmente estables, posiblemente bloqueados por Vsync. Todo ello a 352×224 puntos.

No vemos rastro de subdivisión en el terreno o LOD en las entidades aunque el clipping parece ser similar al del Tomb Raider para los terrenos y entidades. Así no con el dome, que siempre se está dibujando. Por otra parte el clipping del mapa rotado esta muy bien logrado jugando con las ventanas de recorte del VDP1.

Por la parte de la iluminación el motor muestra iluminación en el vehículo y en las armas de forma dinámica, más una iluminación por fuente. Posiblemente en los enemigos y entidades también haya iluminación básica por fuente. El escenario muestra una iluminación precalculada con Gouraud.

Tiene una distancia de dibujo realmente notable. Más el suavizado a negro del Depth cueing hace, la mayor parte del tiempo, casi imperceptible el poping. Es cierto que PS1, siendo exactamente igual, es mejor. La causa principal es como he dicho antes decisiones de base que se hicieron pensando más en PS1 y PC, y que, como suele ser habitual, perjudicaban a la versión de SS. Es cierto que SS se salia de la norma. Pero tampoco era tan complicado hacer lo mismo bien en SS. Me refiero al “dome”. El “dome” en los juegos 3D es el fondo total. En muchos suele ser 2D, más en SS, pero en la época con PS1 principalmente empezaron a verse más fondo en 3D. Con formas cilíndrica, esférica o de cubo con textura que simulan ser esférica. En este caso, esta entidad es una entidad básica que se repite en todos los escenarios solo cambiado el color y los degradados Gouraud. Hasta aquí la SS lo puede hacer sin problema. Ahora esta geometría con Gouraud está encima de un fondo total plano con un degradado de color. La primeras geometrías simulan, montañas, edificios o nubes en la penumbra de la lejanía. La segunda el degradado del cielo. La primera sobre la segunda tanto en PC como en PS1 tienen una transparencia, para dejar ver el fondo total y mezclarlo todo de forma muy eficiente y así ahorrar una gran textura o texturas para ello. Es más rápido también que mover y dibujar todo esto con texturas. Pero el problema es que usan exactamente la misma geometría que para las otra versiones, es decir, con muchos triángulos. Y además a falta de una transparencia para 3D que funcionen usan el modo mesh. Bien. Al no haber, en estas dos capas finales, degradados con transparencia, el Depth Cueing en la zona baja no funde contra negro o degradado del fondo. Si no contra el punteado de la malla del dithering, dejando este efecto final menos eficiente. Además de que se está dibujando siempre este dome, con esta gran cantidad de redibujado desperdiciado. Para la SS es un desperdicio total. Porque está haciendo Gouraud en triángulos, lo cual le hace tirar fillrate en cantidad. Se podría haber convertido a quads bien este dome, primero. Segundo, haber usado un degrado en el fondo final con el Back screen del VDP2, y finalmente haber usado la transparencia de Sprite con VDP2 de estos quads con Gouraud contra el Back Screen. Todo esto hubiese tenido un coste infinitamente inferior para SS y se hubiese visto igual que en PC y PS1. Incluso hubiese permitido subir los FPS a 25FPS o 30FPS, la distancia de dibujo o la resolución de las texturas del escenario de 24×24 a 32×32. También se podía haber hecho este dome con la capa RGB0 del VDP2, como en Exhumed, con la transparencia final sobre el Back Screen igual, pero bien es cierto que si hubiese sido una solución 100% adaptada a SS, y no algo más válido para todas la versiones. Por último también está el problema de que usan para la UI la transparencia del VDP2 podrían tener problemas de mezclado. Pero usando el modo extendido de cálculo de color del VPD2 correctamente(Como en Sonic R), en teoría se podrían haber mezclado sin problema ambas capas del VDP2.

El resto de elementos transparentes, incluso los billboards como llamas o flares hacen uso del modo mesh. Es cierto que en este juego están sobre otros elementos del VDP1 todo el tiempo, pero extrañamente los desarrolladores no lo usan en absoluto. Quizás pensando que tenia un problema de fillrate en el VDP1. Cuando realmente los problemas vienen más del mal uso del este, y además lo más probablemente de la parte de la CPU, en su código de transformación e iluminación.

Vemos un uso de la función de cálculo de gradación y de cálculo de color para el ratio y prioridad. En el caso de la primera deberíamos percibir un suavizado en las líneas horizontales tanto el los gráficos del VDP1 como en la capa del VDP2. Pero no funciona porque los desarrolladores no configuraron correctamente los registros del VDP2 para ello. De la segunda realmente desconozco para que lo usan, o cual era su intención. Ya que lo único que podrían hacer es algún elemento del VDP1 hacerlo transparente contra la única capa que están usando para la UI, o para el Back screen, pero no consigo ver en que.

Todas estas señales, más otras que hemos hablado, pueden ser resultado de la búsqueda temprana de soluciones mejores para el juego. Pero todas ellas sin finalizar.

Por la parte del sonido hicieron uso del driver 2.x de SEGA. El equipo de Core Design no se complica. Y no usa las posibilidades del DSP extras, que tanto hubiesen lucido en este juego. Como la reverberación o eco, que casi seguro se usaron en la versión del PS1. Aunque si vemos un uso del DSP típico para la reproducción de CD-DA para la música. Tampoco a nivel de sonido FX vemos grandes avances. Pareciendo que meten en la Sound RAM todo los sonidos por nivel, en modo raw. Seguramente a la mitad de calidad, o menos, que en PS1 para que quepan todos.

Puede que haya un posible uso de render de CPU al Frame Buffer del VDP1 en pantallas de carga. Aunque no estoy seguro.

Las cinemáticas son todas a pantalla completa, con una buena compresión. A 320×200 a 24FPS. El sonido sin embargo se queda en PCM mono a 22254 Hz. Con un bitrate de 1800kbps de pico. 1400 para el stream de video y 356 kbps para el audio. Aún quedaba algo de margen para algo más de calidad de sonido. Todo ello mostrado en el VDP1 mediante un distorted sprite a 15BPP.

El uso del hardware es notable. Usando los 2xSH2 para los FMV y el 3D. Podemos ver un uso típico del SCU-DSP en FMVs y 3D de hasta un 20% de memoria y 17,4% de registros. El juego usa el 70% de LRAM y el 80% de la HRAM. Hasta el 95% de la VRAM del VDP1 y finalmente de la VRAM del VDP2 el 60% y del CRAM el 60%.

  • SEGA WorldWide Soccer 97 / 98

    Lanzado en el 1996-11-29. Siendo un juego de la 3ª ola de desarrollos Japonés first parties. SWWS 97 es un gran juego de fútbol para la SS. El Team Aquila se encargó de esta saga en concreto y ya demostraba un gran maestría en el uso de la máquina. Aún más en hacer uso de las capacidades de transparencias de la misma, como pocos en el sistema.

Bajo mi punto de vista estamos ante el título de la saga Victory Goal que marcó un punto importante. Marcó la madurez de uno de los equipos de SEGA CS que mejor uso la máquina y en concreto en este género. Bien es cierto que había otros títulos importantes y buenos en SS. Pero por parte de SEGA, este era su título de fútbol estrella. Con el siguiente SWWS 98 solo añadieron, el modo liga, y mejoraron otros aspectos mínimos.

SWWS 97 se mueve a 352×256 a 15BPP de forma excepcional, a 30FPS totalmente estables. A 60FPS en los menús incluso con 3D. Es cierto que la carga poligonal en este juego no es alta y tampoco hay iluminación durante los partidos. Durante los cuales estamos hablando de 500 quads vistos, haciendo uso de hasta 2 niveles de LOD para jugadores y sombras.

Si podemos apreciar iluminación en el 3D en los menús. Cuando seleccionamos los estadios, con una fuente de luz. También en las banderas antes del partido.

Pero si en algo destaca técnicamente este juego y este equipo es en el uso inteligente y preciso de las capacidades de SS para las transparencias. En los partidos podemos ver gran cantidad de las mismas y usadas con inteligencia para que funcionen lo mejor posibles. Así pues podemos ver funcionando a la vez y casi sin problemas transparencias sobre el VDP2 nativas en los Screens y mediante el modo compartido entre VDP1 y VDP2. En este último podemos ver su uso principalmente en las sombras de los jugadores, pero también en el chapoteo del agua cuando llueve y la sombra del balón. Las transparencias de VDP2 las podemos ver usadas para la lluvia, radar de campo, letreros de la UI o menús.

Mención especial al uso de el modo de inserción en la Pantalla de color de línea o LCS. En este caso para simular la bruma hacia la lejanía en el campo de juego. Se ve solo en el modo de día. Este efecto lo eche a faltar en FIFA 98, que si estaba en PS1, pero Climax en la versión de SS no lo integro. Como podemos ver en este SWWS es totalmente posible. Además de haberlo visto en muchos otros juegos como hemos visto.

En los menús podemos ver como se usa también para sombras de botones o fondos de cuadrados de selección o de la UI. También he podido ver el uso del modo de cálculo de color extendido o ECC, no así en los partidos. Añadir como curiosidad que yo no he podido ver donde está siendo realmente usado, ya que no he visto ningún lugar donde 2 o mas Screens del VDP2 se estén solapando. Y el otro detalle es que el Tema Aquila huye del uso del modo mesh del VDP1. Pero en los menús en la parte de edición de jugadores cuando, dos ventanas se superponen. En la animación de escalado estos usan el modo mesh, posiblemente para evitar que la transparencia de esta tapa a la inferior. No deja de ser curioso que estos con el conocimiento que demuestran no lo hubiesen evitado de otras formas. Si tenía ya el modo ECC activado podían haberlo usado para un elemento hacerlo con el VDP2 nativo y otro con el VDP1>VDP2 con el ECC y así mezclarlo con el VDP2 ECC. O usar la transparencia del VDP1 para los dos elementos y ambos mandarlos por el modo VDP1>VDP2.

Como apunte final, es tal el uso de la máquina que hacen. Que es uno de eso pocos juegos del catálogo en el que se están usando todos los Screens del VDP2, con la mayoría de funciones activas y usadas. Tanto en menús como durante el juego 3D, es espectacular sin duda.

El sonido como en la mayoría de títulos first party es soberbio. En este título además tenemos el uso del modo CD-XA y de ADPCM de forma extra. Además de música MIDI con efectos de DSP activos de reverberación y eco. Haciendo un uso del SCSP-DSP en los menús de un 60% memoria y en juego 3D hasta un 30%. Por supuesto también hacen uso de pistas CD-DA. Los comentarios se pueden ver que están en archivos sueltos. En el SWWS 98 lo empaquetaron todo en uno solo archivo, supongo para agilizar el acceso al vuelo en los partidos y minimizar las paradas por las búsquedas en el CD al vuelo, típicas en estos casos.

En su momento la intro de este juego me impactó. A 320×176 y 15FPS. Con un sonido estéreo ADPCM. La verdad es que es muy buena. Aunque la compresión en Cinepak es mejorable, se ven demasiados artefactos típicos de codec y deslucen el resultado final. No así en la versión 98 que pone el listón realmente alto. Que llega a los 320×224 también ha 15FPS, pero ahora en PCM, aun estéreo a 22050hz, una gran calidad para el sistema.

El uso de la máquina es notable como venimos diciendo. Usa 1xSH2 para los FMV, mientras para el resto del juego los 2xSH2. Se ven señales del SCU-DSP típicas del 20% de memoria y 17,4% de Registros. Posiblemente para transferencia de stream de audio o datos. El uso de la RAM está en el 95% para la LRAM y en el 90% para la HRAM. El uso de la VRAM  del VDP1 llega a un 80%. Mientras la VRAM del VDP2 llega a un 90 y el de la CRAM a un 95%.

  • Sonic R

    Lanzado en el 1997-11-21. Siendo un juego de la 4ª ola de desarrollos Europeos desde una Second partys.

Estamos ante un auténtico milagro. Pues la mascota de SEGA estuvo dando bandazos desde antes del lanzamiento de SS. Se conocen hasta 3 diferentes títulos de Sonic 3D que quedaron por el camino: Uno en 32x y dos en SS. Pero podemos dar gracias a SEGA Europa que pudo sacar adelante este Sonic 3D, y además con un compañía y líder de programación de altura: Traveller’s Tales. Estamos posiblemente a uno de los mejores títulos del sistema. Y además es un Sonic, y podríamos decir que incluso “original” al ser un juego de carreras. Construido en tan solo un año, y reconvertido desde un juego de Formula 1 originalmente para competir contra el F1 96 de PS1 de Bizarre Creations. John Burton y su equipo realizaron una auténtica obra maestra.

Si es cierto que la propia TT sé encargo del también único Sonic 2D isométrico que salio en máquinas SEGA. Y que para la versión de SS se incluyo un bonus totalmente 3D. Y que también está el modo mapa 3D del Sonic Jam de la mismísima Sonic Team. Pero como juego como tal pensado totalmente en 3D, este es el único Sonic que podemos considerar.

Corriendo a 30FPS como una auténtica roca a 352×224 puntos de resolución en modo de color de 16BPP en el VDP1 e igual resolución de salida y profundidad de color máxima para el VDP2. Con una cantidad de geometría en pantalla increíble. Es el juego con más quads pintados y calculados en pantalla y a FPS estables del sistema. Llegando a picos de cerca de 1500 quads en pantalla. Todo los dicho tanto para uno y dos jugadores a pantalla partida.

El uso de ambos VDPs es magistral. El VDP1 es usado completamente: Polígonos planos, sprites normales, sprites escalados, sprites distorsionados. En distintos tipos de profundidad de color. Sombreado Gouraud a color estático y animado. Diferentes modos de cálculo de color. Semi-Transparencia usada con mucha inteligencia: Estela de velocidad(con un mínimo de error de redibujado), escudos… Modo mesh usado solo en caso extremos: Sombras, humo… En el caso del VDP2 el uso está a la misma altura. Algo realmente raro de ver en SS. La mayoría de juegos centran su uso en el VDP1, y tampoco de manera excelente como es el caso, y olvidan casi por completo el magnífico VDP2. No es el caso como hablamos. John Burton pone hasta dos planos infinitos en pantalla a una resolución máxima posible. Usa fondos con partes animadas. Y por supuesto todas las posibilidades de transparencias que da. Tanto la propia por pantalla para elementos de la UI, como las especiales como el Color Line Insertion incluso animado para el oleaje del agua. Los cálculos de color y ratio con el VDP1 para conseguir un efecto de Depth Cueing con desvanecimiento magnífico, con hasta 12 niveles. Y para el efecto de onda en el agua cuando el personaje está bajo el agua. Sumando el uso del modo Extendido de color para la función de cálculo de color, pero en este caso totalmente funcional y bien usado, llegando a mezclar hasta 3 capas del VDP2.

Además de todo lo expuesto. John aún nos tiene más sorpresas. Iluminación con una 1 luz paralela dinámica con fuente y color Gouraud en todos los personajes. Por supuesto los escenarios están iluminados con color y Gouraud, pero en este caso son luces bakeadas.

Pero aún hay más. El equipo de John Burton fue más allá. Ante la falta de coordenadas UV en el VDP1. John Burton encargo a un compañero de equipo implementar vía ensamblador SH2 un rasterizador de triángulos con proyección afín y coordenadas UV similar a la GPU de la PS1 para usarlo en Sonic R para efectos de Mapa de ambiente. Y lo hizo. Finalmente no lo uso extensivamente, solo en: la R 3D del logo en la pantalla inicial, la cabeza 3D de Sonic rotando durante las cargas y en el número 3D de posición de final de carrera. Pero la idea era usarlo también para el Sonic Metal. Ahí quedo.

Cabe destacar también que Sonic R hace uso de las capacidades de sonido 3D del chip SCSP-DSP de la SS. En este caso de la implementación Qsound. Posiblemente para el eco o reverberación en las zonas de túneles o cerradas. No he podido comprobarlo al 100%.

Finalizamos con el uso del Hardware. Como no podía ser de otra forma es excelente. Se está usando la dupla SH2 más el SCU-DSP para toda la pipeline 3D. En este juego llegando a una de las cifras más altas: 80% de Memoria y 57% de Registros usados. Presumiblemente Sonic R esta cerca de usar el 100% del proceso en el SH2 Esclavo cuando está usando su renderizador 3D por software. Como hemos dicho usa el procesador SCSP-DSP en este caso vemos hasta un 90% de la memoria usada. Por parte de las memorias principales. Está en 85% de uso combinado del RAM principal. En 85% del VDP1 y de un 85% de la VRAM del VDP2 y de un 60% de la CRAM.

5.4 Lo complicadísimo – Bola EXTRA II: Reflejos en suelos/Superficies planas.

Es un tema que me ha ido llamando la atención progresivamente. Cuando he ido descubriendo cómo dibuja la SS, y como usaron esta en los juegos del momento, me ido haciendo preguntas. Una que iba en in crescendo fue ¿Porque no hay reflejos en los juegos de baloncesto u hockey sobre hielo?

Ya que si los había visto en juegos como Panzer Dragoon antes que fijarme en los juegos de Baloncesto u Hockey. Pero es que tan solo dos juegos de Baloncesto tienen dicho efecto. Es decir, el reflejo más las sombras.

En los de Hockey ninguno. Tienen sombras transparentes, pero no reflejos. El que tiene reflejos es el NHL 97 pero son Mesh. Algunos juegos de Baloncesto tenían al menos las sombras también transparentes como el NBA Live 97.

Como todo lo referente a las «transparencias» en SS, el problema radicaba en que no estaba simplificado, «claro» y accesible para los desarrolladores. Si hubiese estado realmente simplificado y accesible mediante las librerías y SDK, lo hubiesen usado más.

¿Al final se consiguió arreglar esta situación de desventaja?

Tristemente NO. Como digo solo un juego de baloncesto lo hizo. Cuando de hecho, bajo mi punto de vista, todos habrían podido. Igual con los de Hockey.

He llegado a verlo en solo un 3.4% del total de juegos analizados. Cuando como vemos para el VDP2 y en muchos juegos es un efecto totalmente posible y gratuito a nivel de rendimiento.

Bueno vamos con una lista cronologica de los que he podido encontrar:

Juegos con efecto reflejo en 3D usando VDP1+VDP2:

  • Panzer Dragoon Zwei (1996) → Reflejo Agua y bajo agua
  • Linkle Liver Story (1996-03-15) → Reflejo Agua
  • Shining Force III (1997) → Iglesia Escenario 3 o Premium. Visto en videos e imágenes, no he podido comprobarlo.
  • Ten Pin Alley (1997) → Reflejo parque
  • Mass destruction (1997) → Reflejo Agua
  • Panzer Dragoon Saga (1998)→ Reflejo Agua y bajo agua

Juegos con efecto reflejo en 2D/3D usando VDP1+VDP2:

  • From TV Animation Slam Dunk: I Love Basketball (1995)
  • Slam ‘n Jam ’96 Featuring Magic & Kareem (1996)

Juegos sin el efecto reflejo, peor posible, pero con sombras en 2D/3D usando VDP1+VDP2:

  • NHL Powerplay 96 (1996)
  • NHL All-Star Hockey ’98 (1997)
  • NHL 98 (1998)

De nuevo pasamos a analizar tres juegos que son representativos de este punto:

  • Panzer Dragoon Zwei y Saga

    Lanzados en el 1996-03-22 y 1998-01-29 respectivamente. Panzer Dragoon Zwei y Saga son la segunda y tercera parte de la saga en SS. Juegos de 3a y 5a ola respectivamente de un desarrollador First party Japones. Podemos ver un uso de la máquina ya importante en el 96 y extraordinario en el 98.

Destacar que ambos juegos comparten tecnología. Es curioso porque la diferencia entre ambos es de dos años aproximadamente. Pero analizando ambos en detalle los datos están hay. La iluminación dinámica a color esta presente en ambos juegos. Los efectos de transparencia creativos con el VDP2 o el sonido 3D usando el DSP del SCSP. Incluso la versión del driver de sonido es la misma con una fecha de compilación ligeramente diferente pero del 1996. Usan los procesadores y las memorias disponibles en % iguales o muy parecidos. El uso del codec Cinepak también es igual. Cuando ya en esta época había juegos de SEGA usando ADX y Cinepak con ADK para más calidad. Incluso el uso de VDP2 para el FMV es igual.

Pasemos a detalle. Como decíamos ambos juegos tienen iluminación dinámica con fuente más Gouraud a color. También iluminación dinámica plana en algunas entidades. Y por supuesta iluminación bakeada en escenarios con Gouraud y plana. Ambos tienen Depth cueing con el VDP1 y con cambios de paleta de color con la CRAM del VDP2.

Ambos juegos corren a 30FPS bastante estables. En las cinemáticas 3D en Zwei incluso alcanza los 60FPS. En ambos juegos la carga de quads es similar alrededor de 500 quads, puede que más en batallas con muchos enemigos, balas o enemigos muy grandes. En las cinemáticas de Zwei sobre 300 quads. En saga en algunos mapas 3D muy grandes se pueden notar bajones a 15/20FPS. Por lo demás es bastante estable. En términos de resolución ambos juegos corren a 352×256 en las partes 3D y en los menús HD a 704×256, con una nitidez que aún hoy día sorprende. Aunque el juego está en modo 15BPP el contenido de texturas y patrones suele estar entre 4BPP y 8BPP tanto para el VDP1 como para el VDP2. Por supuesto ambos juegos siguen la estela del primero en el uso de los planos infinitos de VDP2 para recrear espacios enormes como solo podía verse en SS: Desiertos, nubes, mares…

Zwei ya en el 1996 dejó bien claro que cuando se quería con la SS se podían poner transparencias sin rubor en pantalla. Especialmente efecto bajo aguay y de reflejo del enemigo de las cuevas en el segundo episodio, si no recuerdo mal. Por supuesto ambos usan las transparencias de Calculo de color y ratio con los elementos de VDP1 y mezclados finalmente por el VDP2. En varios efectos desde: sombras en el nivel del bosque de Zwei, elementos bajo agua en ambos juegos y muchos otros. Como dato curioso para la iluminación de la hoguera en la tienda de campaña. Por supuesto se hace uso el efecto de transparencia a toda pantalla del VDP2 para efectos climáticos diferentes, capa de nubes en mapa o de magias. También en muchos elementos de la UI del juego.

Por otra parte la Semi-Transparencia del VDP1 también se usa. Pero en este caso no lo he visto en el Zwei, si en el Saga. Está la usa para muchas partículas y billboards de forma muy inteligente desde: Humo, disparos, explosiones, partículas mágicas… Tanto en el mapa 3D como en las batallas.

Cuando las transparencias habladas no pueden ser aplicadas el equipo Andromeda tiene que recurrir al modo mesh como usualmente vemos en muchos otros juegos, así podemos verlo en: Sombras de personajes, efectos de partículas varios o en el radar…

Como he dicho antes ambos juegos usan Cinepak+PCM para los FMV. La calidad de sonido es igual: 32000 Hz, 16bit, Mono. Para mi gusto un desperdicio por la calidad de la Banda sonora y el sonido en general no poder tenerlo en Estéreo. Se diferencian en la resolución y FPS del stream de la imagen. Zwei tiene menos resolución pero más FPS y Saga al revés. Pero bajo mi punto de vista un desperdicio de calidad CGI. Esta saga debería haber usado Duck o al menos Cinepak+ADX para tener una calidad cercana a Wachenröder o Lunar 2. Finalmente destacar como detalle que estos son de los pocos títulos que usan el escalado del VDP2 en los FMV para poder aprovechar mejor el área total de la pantalla.

Señalar que uno de los documentos extra que los desarrolladores dejaron en Panzer Dragon 1. El programador de sonido dijo que se quedo con las ganas de usar el sonido 3D. Pero que para la siguiente ocasión lo usaría.

 

◆エンド前にカゼひいたりトラブったりと大変だったけど無事できあがりました。

今回はできなかったけど次は3Dサウンドとか使ってみたいですね。サターンの

サウンドはもっとすごいことができるはず、と反省しつつ次回に乞うご期待。

サウンド担当：澤田　朋伯

◆ Me costó mucho, cogí un resfriado antes del final, pero pude terminarlo con seguridad.

No pude hacerlo esta vez, pero me gustaría usar el sonido 3D la próxima vez.

Estoy seguro de que podemos hacer cosas aún más sorprendentes con el sonido de Saturn, así que por favor espera con interés la próxima vez.

      　　　　　　　　　　　　　　　　　Responsable de Sonido: Tomoharu Sawada

 

Y así fue. Tanto en Zwei como en Saga vemos un uso del SCSP-DSP genial. Tanto en efectos de reverberación como en el sonido y música MIDI en general. Así podemos ver un uso de hasta un 90% de la memoria DSP del sonido. Además de signos de archivos .exb por pista. Archivos del código compilado del DSP de sonido. La calidad de los sonidos que podido ver es de PCM a 11025 Hz mono.

El uso del hardware es excelente. Usando los 2xSH2 tanto para FMV como para 3D. Con signos de uso típicos del SCU-DSP del 30% y el 26% en la memoria y registros respectivamente. Por otra parte podemos ver un uso de la memoria principal al 70-80%. De la VRAM del VDP1 del 80-90%. En el VDP2 he visto ligeras diferencias. En el PD:Zwei el 55% de la VRAM del VDP2 y el 90% de CRAM. En el PD:Saga del 80% de la VRAM del VDP2 y del 70% de la CRAM.

  • From TV Animation Slam Dunk: I Love Basketball

    Lanzado en el 1995-08-11. Slam Dunk es un juego de la 2ª ola de desarrollos Third party Japoneses. Y he decir que un desarrollo de una calidad soberbia para ser tan temprano en el sistema.

BEC Co. Ltd que es la compañía que viene acreditada como desarrolladores de este título. No dejan de ser una división de Bandai. Fueron los encargados de más IP conocidas de Mangas. Otro gran títulos de ellos es el Dragon Ball: La Leyenda.

No es un juego con una carga de quads grande, sobre unos 400 quads, pero extrañamente va a 15FPS como las FMV. A una resolución de 320×224 15BPP. Me da la sensación de que han querido este sea el objetivo de FPS final. Porque la sensación, por varios detalles, de que técnicamente van bien.

Lo que realmente llama la atención de este título es la implementación del efecto de reflejo que tiene sobre la cancha. Que no se ve en el resto de títulos de baloncesto o similares. Y este juego lo muestra como totalmente posible. Además haciendo un uso muy inteligente del cálculo de color por ratios para los elementos del VDP1 sobre el VDP2 junto a la mezcla de brillo especular en otra capa del VDP2. Todo ello contra la cancha usando el RGB0. Y sin llegar a usar el modo de cálculo de color extendido, da la sensación de que todo se está mezclando. Realmente funciona muy bien. Para acabar con el tema de transparencias, también señalar que usan la Semi-Transparencia del VDP1 de forma muy correcta para el tablero de cristal, el cual siempre está sobre elementos del VDP1.

Podemos destacar que puede que sea uno de los primeros títulos que usan la librería de SEGA InVision, para los MIDIS. La música del juego la verdad es que suena muy bien. Con respecto al uso del SCSP-DSP hay señales claras hasta un 60% de memoria, y tengo la sensación de que los sonidos en los estadios se escuchan con eco o reverberación.

He de decir que los FMVs de este título me parecen soberbios. En serio, la calidad, la cantidad es muy buena. A 288×216 escalados en el VDP1 a pantalla completa, 30FPS y PCM 22256 Hz 8 bits Estéreo. Me sorprende sobre todo por lo tempranos que son en calidad. Y en el tiempo títulos similares en SS sacaron video bastante peores, incluso desde la misma Bandai el primer Dragon Ball Z o Rayman de Ubisoft.

El uso del hardware, en mi humilde opinión, es magnífico más meritorio siendo una Third partys y en una etapa aún tan temprana del desarrollo del sistema. El uso de los procesadores es total. Los 2xSH2 tanto para 3D como para FMV. Y además en el 3D se está usando el SCU-DSP en unas cifras importantes, Memoria un 95% y registros en un 44%. Cara al uso de memorias estamos en un 95% de la LRAM y un 65% de la HRAM. La VRAM del VDP1 llega a unos 90% de uso. La VRAM del VDP2 a un 80% y la CRAM en un 70%.

  • Mass Destruction

    Lanzado en el 1997-11-20 siendo un juego de la 3ª ola de desarrollos Europeos. Para mí es especialmente destacable este titulo porque esta notablemente bien resuelto para la SS y además el resto de versiones. No se ha priorizado en unas más que en otras. Y se ha hecho un trabajo para que luzcan lo más parecidas y correctamente en cada soporte. Lo que debiera ser. Solo destacar que salio con dos meses de diferencia con respecto a la versión PS1, y que tan solo aparece acreditado un programador para la versión de SS. Con todo, como digo para mi la mejor versión.

Parece que el equipo de NMS no tuvo mucha vida, pero al menos con calidad. Se ve que eran profesionales con largo recorrido, incluso desde 8bits. Habilidosos tocando código a bajo nivel y creando gráficos en diferentes circunstancias. SS se vio beneficiada positivamente por esto. Y además en este Mass Destruction se nota todo su saber. Un juego de acción directo con pequeños detalles, pero que hacen a los juegos aparentemente pequeños grandes y duraderos en el tiempo.

Corriendo a una resolución de 320×224 a 15BPP aunque los gráficos en su mayoría están en 8BPP, igual que la versión PS1. Pero a 60FPS constantes y si ralentizaciones, en contra la versión de PS1 no es tan suave, quizás este en los 30FPS. Que tampoco está nada mal. La calidad del suelo también en SS es claramente superior, dado que el RGB0 del VDP2 es capaz de dibujar planos 3D con corrección de perspectiva por pixel con un detalle por tile muy alto. PS1 no podía igualar esto, sin un sacrificio extremo. Tampoco es un juego que dibuje muchos quads en el VDP1, en este caso alrededor de los 300 quads.

Este juego no posee iluminación dinámica, solo se puede apreciar una iluminación precalculada en algunos elementos como palmeras u objetos con polígonos planos.

Este juego hace un uso de las posibilidades de transparencia de SS excelente.  Solo se le puede poner una pega, no haber implementado la transparencia en los edificios como en PS1 totalmente posible, tan solo con mandar el edificio completo y al tanque bajo el RGB0 con CC+ratio como los reflejos que hacen en el agua, hubiese sido suficiente. Pero bueno, por contra, tenemos esos reflejos en el agua que no están en PS1 ni en PC y que son muy espectaculares. NMS también hace uso del modo MSB On para algunas transparencias de sombras. Y por supuesto de las transparencias del VDP2 de capa normales para la UI, incluso animadas, de forma magistral.

Mass destruction presenta un uso del DSP de sonido bajo pero existente. De un 20% de uso de la memoria. La música es principalmente de CD-DA aunque también hay alguna en MIDI.

NMS parece que implementó su propio código para los FMV, que parece ser el mismo para todas las versiones. Dando una calidad notable a 8BPP a una cantidad de FPS desconocida, pero estimo que entre 15/25FPS.

El uso del hardware como hemos visto en notable. A nivel de procesadores se están usando los 2xSH2 para 3D y FMV. Por la parte de memorias, la principal llega a un uso del 70% en LRAM y de un 80% de la HRAM. Un 80% de la VRAM del VDP1. Y finalmente un 90% de la VRAM y CRAM del VDP2.

6. Lo complicadísimo II: Render-to-texture

Este punto, ha sido otro de los últimos añadidos que he hecho. En el curso de esta profundización máxima en la máquina. He visto en unos cuantos títulos contados, algo que a priori no podía creer. Pues a mis ojos, era un efecto de Render-to-texture. Algo que nació prácticamente con PSX y su buffer unificado. Que más adelante se vio y utilizo en GPUs en PCs y consolas posteriores.

¿Pero cómo podía ser esto? Teóricamente es «imposible». Porque la SS tiene “dos áreas de buffer” completamente separadas. Y leerlos durante el pipeline, si se puede debe ser muy costoso en ciclos.

Pero hay juegos donde podemos ver claramente cómo se captura la imagen en pantalla de ese momento y después se hacen gráficos 3D, que efectivamente está dibujando el VDP1. Es decir son quads y texturas.

Finalmente podemos diferenciar en este caso varias posibles formas de hacerlo:

A) Render Buffer (Caso tipo PSX): Coger algo del FrameBuffer del VDP1 o Pantalla del VDP2, dentro o fuera del área de dibujo, para reutilizarlo en un patrón/textura para el VDP1 o VDP2. Y crear un efecto concreto a toda pantalla o en una parte vía hardware o software. Hacer la parte del efecto con el hardware es caso menos caro para el sistema. Hacer un proceso extra por software aumenta mucho el costo(más tiempo) para el sistema.

B) Render CPU y/o SCU-DSP: Donde la CPU/SCU-DSP dibuja algo internamente(Proceso y RAM) y lo traslada directamente a una/s textura/s, al Frame Buffer del VDP1 o a una Pantalla del VDP2. Ejemplo: Sonic R

C) Render CPU y/o SCU-DSP con Lectura+Escritura en el FrameBuffer del VDP1: Este el método más agresivo y complicado de todos. Implica leer el FrameBuffer, dentro o fuera del área de dibujo, en tiempo de ejecución, procesar internamente(proceso CPU y RAM) lo que se quiere y dibujar sobre el mismo. Necesita que la operación o función que se quiera realizar sea extremadamente rápida, pues el tiempo para hacerla es muy pequeño. Hablamos de unos pocos ms. Si este sube mucho parara el juego demasiado ocasionando fuertes ralentizaciones. Ejemplo: Scorcher.

D) Lectura del FrameBuffer del VDP1 + Proceso CPU/SCU-DSP+RAM + Lectura del Frame-buffer del VDP1 + Escritura final en el Frame-buffer del VDP1: Este el método más complejo y caro que he podido documentar. Solo lo he visto en Die Hard Trilogy en el tercer juego, el de coches. El equipo lo usa para hacer Semi-transparencia aditivas en destellos y explosiones/fuego. Que se ven preciosas. El elemento a “procesar” se dibuja al final de la lista de comandos fuera del área de dibujo. Mi intuición me dice, que inspirados en el código original de PS1. Hacen un “especie” de Render-to-texture como lo hicieron para el radar del primer juego, que es leer el frame-buffer para usarlo como textura y hacer un proceso de hardware. Pero en el caso de SS ellos realmente pasan tres veces por el Frame-buffer del VDP1, lo cual es una salvajada. Lo cual para la PS1 ya es un proceso caro, a pesar de tener un frame-buffer unificado, con acceso a palabras de 32bits y algo más de ancho de banda por ir a más Mhz. En SS la memoria es más rápida, bastante. Pero acceder 2 veces más y sumar un proceso extra en las CPUs para el efecto via software, es ya una acción hiper arriesgada a nivel de rendimiento. Tanto es así, que cuando tienes 20 o 30 partículas en pantalla ocupando una gran área, el rendimiento cae a un dígito. Me gustaría terminar alabando el trabajo del equipo, porque a pesar de las carencias del ports. No deja de verse buenas intenciones de ir más allá con la máquina, en muchos aspectos. Quizás la falta de budget + timing necesario para la complejidad del sistema, de nuevo jugaron en contra de la versión de SS.

¿Al final se consiguió arreglar esta situación de desventaja?

SI y NO. Si porque como hablamos hay juegos que lo hacen. Pero NO porque al no estar documentado por SEGA y ni tan siquiera haya una librería para ello. Al menos que yo haya encontrado. Como tal, podemos encontrar dicha «feature» aplicada de diferente forma, con objetivos y resultados diferentes.

Lo que no he encontrado es literalmente un caso del tipo: Pantalla gigante de TV.

La duda que queda, es si sería posible a poca resolución, sin penalizar mucho en FPS conseguir dicho efecto. Ya que en PSX no tenía penalización, hasta cierto punto. Según @XL2 que le pregunte en los foros de Segaxtreme, sería totalmente posible a baja resolución. De hecho en Burning Rangers o el mismo en su motor 3D lo hace para la capa de transparencia similar a como lo hicieron también en Burning Rangers.

Los casos de Render Buffer encontrados en los juegos publicados en su momento son claramente «Estáticos» en su mayoría. Con pausas evidentes previas al efecto(incluso en PS1 según como). Estaríamos hablando que para realizarlos la CPU debería parar por completo el pipeline gráfico.

Exceptuando como decimos el caso del Burning Rangers. También en Grandia en las batallas, pero no lo tengo totalmente claro. Donde no hay paradas.

También he visto algo muy parecido en muchos juegos, para renderizar los FMV o en algunas pantallas de carga, aunque lo he dejado fuera de la lista siguiente.

He llegado a ver el uso de esta técnica o muy similar en un 11,4% del total de juegos analizados. Realmente me ha sorprendido. Ya que pensaba que era imposible para la SS por el diseño de su pipeline gráfica. Pero me ha alegrado ver que es posible, a la vez, me ha apenado que de nuevo SEGA no lo facilitara. Quizás podíamos haberlo visto más ya que permite efectos muy espectaculares.

Vamos a ver una lista cronologica y por tipo de tecnica usada con lo que podido encontrar:

A) Render Frame-Buffer a:

Todo el frame completo del VDP1 + VDP2 → A elementos del VDP1

  • Rayman (1995) → Pantalla de carga final nivel con un fundido más animación con elementos en 3D. Resolución 320×224 la misma que la original en todas la capas y VDPs.

Todo el frame o parcial del VDP1 → A elementos del VDP1

  • Loaded (1996) → Fondo juego en Pausa/Inventario menú. Misma resolución 352×224 que la original en varios elementos.
  • Welcome House → Fondo juego en Pausa/Inventario menú, con píxeles de máscara para mostrar correctamente el fondo VDP2. 320X120, Mitad de resolución “Y” Render.
  • Akumajo Dracula X: Gekka no Yasokyoku (aka. Castlevania: Symphony of the Night) (1998) → Efecto para la foto en la intro del juego a una resolución de 320×216, lo hace bastante rápido.
  • Genso Suikoden (1998) → Efecto en Batallas a toda pantalla. Como PS1 pero mal implementado, con problemas tontos. A 320×240 posiblemente, no lo he podido comprobar, parece que es relativamente lento.

Todo el frame o parcial del VDP1 → A una capa del VDP2

  • Tomb Raider (1996) → Fondo juego 3D en Pausa/Inventario menú 352×256. Lo hace muy rapido.
  • NBA Live 97 (1997) → Fondo juego 3D en Pausa/Opciones menú 320×240.
  • Burning Rangers (1998) → Capa de elementos transparentes y máscara(negros) a 160×122.
  • Arcana Strikes (1997) → VDP1>VDP2 Parece que envía los datos de sprites con la misma resolución que VDP1 original → NBG1
  • Grandia (1997)→ En las batallas, los caracteres de sprites que se dibujan en VDP1 se transfieren a VDP2 NBG1 y, por lo tanto, se usa el efecto de transparencia en VDP1> VDP2. Parece que solo transfiere los datos VDP1 que no están actualizados en este momento o están en pausa. Los únicos datos animados se dibujan en VDP1 en este momento.

B) CPU/SCU-DSP Render a:

A Capa (Bitmap o pattern/patrón/s) del VDP2:

  • Menú de la BIOS (1994-11-22) → Fondo estrellas espacio.
  • Cyberia (1996-01-01) → All 2D y FMV son renderizados por las CPUs y enviados a NBG0 del VDP2.
  • Shellshock (1996-04)→ 3D Mode 7 Suelo como Firestorm: Thunderhawk 2.
    • PassThrough de primitivas VDP1 para assets, enemigos y partículas.
    • CPU+VDP1>VDP2 de Elementos.
  • Hexen (1997) → Map-Scenery BSP Engine Software raster render
  • Tempest 2000 (1997) → Blur effect, very slow FPS
  • Amok (1997) → 3D Voxel Engine
  • Shining Force III (1997) → SCU-DSP Render to Texture VDP1 y VDP2 Textura Gradiente Procedural a VDP1 y/o pattern/patrón/s a VDP2 screen

A Textura/Patrón del VDP1:

  • Firestorm Thunderhawk II (1995-11) → 3D Mode 7 Suelo más degradado horizonte
  • Sonic R (1997) → Environmental Map effect
  • Shining Force III (1997) → SCU-DSP Render to Texture VDP1 y VDP2 Textura Gradiente Procedural a VDP1 y/o pattern/patrón/s a VDP2 screen

C) Lectura/Escritura en/al FrameBuffer del VDP1.

  • Rayman (1995) → Explosión de Partículas cuando coges items.
  • Scorcher (1997) →Halos rojo fijo y blancos parpadeantes.

D) Lectura del FrameBuffer del VDP1 + Proceso CPU/SCU-DSP+RAM + Lectura del Frame-buffer del VDP1 + Escritura final en el Frame-buffer del VDP1.

  • Die Hard Trilogy (1997) →Billboard: Destellos, destellos color con Gouraud y explosiones

Finalmente de nuevo me quedo con otros tres de los mejores juegos en este apartado. Que serían:

  • Firestorm: Thunderhawk 2

    Siendo lanzado en el 1995-11-08. Es un título de la 2ª ola de desarrollos para el sistema. Prácticamente 1 año después del lanzamiento. Core Design ya había demostrado desde los 8bits tener una solera más que garantizada en todo lo que hacia. Y sus miembros con toda esa amplia experiencia ya en el 95 así lo atestiguan con cada lanzamiento. Fue un juego desarrollado en paralelo para PS1 y PC también en tan solo 3 meses, así lo cuenta su desarrolladora en una corta conversación de twitter que mantuve con ella, gracias Sarah:

“Las versiones de Saturn y PS1 tardaron 3 meses en crearse, y la versión para PC tardó un mes más. El juego estaba codificado en C, con subrutinas de código de máquina donde era necesario para la velocidad.

Debo agregar que tuve que codificar un nuevo motor 3D desde cero, utilizando hardware de polígonos 3D para objetos y la mayor parte del piso, con el piso distante representado por una rutina de software que había desarrollado basado en MegaCD ASIC.”

Sarah Jane Avory

El juego corre a la típica resolución para SS de 320×224 a 15BPP aunque el contenido gráfico está entre 4 y 8BPP. A 20FPS totalmente estables. Es un juego que me llamo la atención porque no muestra los típicos comandos de dibujo en el debugger del VDP1 de Yabause. Muestra muchísimos Normal Sprites a 8BPP pequeños. Y por otra parte se puede apreciar como el suelo plano rotado Modo 7 no lo está dibujando el VDP2 con una capa RGB0. Todo esto sumado me hizo pensar que todo estaba dibujado por software. Pero cuando pones el emulador en OpenGL puedes ver como los gráficos suben de resolución e incluso puedes apreciar el uso de Gouraud y Mesh típico del VDP1. Exactamente no sé como Sarah programó el VDP1, pero lo está usando. Lo que si es renderizado por software como ella confirma es el suelo Modo 7 con un efecto de Depth Cueing además. Que en su siguiente proyecto, Fighting Force, si uso la VDP2 para ello. Si usa el RGB0 para el fondo rotado según la inclinación de la cámara. También podría estar haciendo un render-to-texture en el radar que vemos dentro de la cabina o la cámara de 3ª persona.

F:T 2 no tiene iluminación dinámica de ningún tipo. Si tiene iluminación bakeada en los terrenos y entidades, mediante suavizado Gouraud o Plano.

La música del juego está en pista CD-DA. Aunque podemos ver un uso del DSP de sonido del 35%, no sé exactamente para que.

F:T 2 tiene una FMV francamente muy buenas. Ya se nota que Core estaba bastante acostumbrada en este momento por su paso previo por Mega-CD. La intro tiene una calidad muy buena a 320×200 a 15FPS, la calidad del sonido es buena pero en mono.

Finalmente el uso del hardware es muy bueno. Usando ya los 2xSH2 tanto para los FMV como el 3D. Se ven signos de uso típicos del SCU-DSP. Por parte del uso de memorias podemos ver hasta un 85% en la LRAM y un 45% de la HRAM. Un 95% de la VRAM del VDP1. Y un 22% de la VRAM del VDP2 y un 90% de la CRAM.

  • Amok/Scorcher

    Siendo ambos lanzamientos de la 3a ola de desarrollos Third party en el 1997-01-17 y 1997-03-01 muy próximos. Ambos de una compañía de USA pero con equipos de otros lugares. Nos encontramos con estos dos títulos que se desarrollaron internamente en dos diferentes equipos de Scavenger: Lemon y Zyrinx ambos con componentes de Dinamarca de la demo-escena de Amiga. En el caso de Amok todo apunta a ser una de las demos técnicas que se mostraron previamente para y sobre el 32X. También se puede deducir por el tamaño de los juegos finales y por una serie de detalles técnicos en ambos juegos.

Empecemos cronológicamente con Amok. Realmente bajo mi opinión es un juego para el momento impactante. Lo voxeles, que siempre han sido el hermano pobre del 3D, a mí siempre me han gustado y sorprendido. Además es un tipo de 3D que tampoco es barato de procesar, y que en los RISCs de la SS vaya tan bien me parece un gran logro. Bueno siendo justos Amok hace proceso de voxeles y de 3D clásico, pues las entidades 3D están procesadas como raster de triángulos texturizados. También podemos observar Depth cueing hacia el fondo por software en todos los elementos.

Sobre las transparencias en este juego no se ha usado la solución vía software, se ha optado por una implementación también del tipo mesh o tramado. Si podemos ver puntualmente el uso de la transferencia del VDP1 para el radar en la UI. Y en los menos las transferencias del VDP2 con CC.

Amok corre a 320×224 a 16BPP en los elementos del VDP1 y en render por software que está en el VDP2 y el fondo del VDP2 en 8BPP. Este juego va 30FPS, en ocasiones contadas baja a 25 o 20FPS. No es posible saber la cantidad de geometría que hay en pantalla.

La versión hermana de PC es prácticamente idéntica. Al menos en las características principales y distancia de dibujo. Aunque pide un mínimo de un Intel i486DX2 el recomendado era el Intel Pentium a 100MHz. Posiblemente en un modo 320×200 a 8BPP con scanline el DX2 iría bien. Pero subir a 640×480 de 8BPP a 16BPP ya necesitaría un buen Pentium y quizás no con eso iría igual de suave que en SS. En PC las transparencias son alpha reales todo por software en vez de mesh como en SS.

A nivel de sonido usa CD-DA para la música, de ahí quizás el posible uso del SCU-DSP para algo además SCSP-DSP en un 35% de la memoria.

Aunque no hay FMV como tales, si hay alguna animación a pantalla completa para el Logo. Posiblemente imagen RAW cargada al vuelo.

El uso del hardware de Amok es notable. Usando los 2xSH2 para el 3D. Con señales de uso del SCU-DSP como hablamos típicas 25/26% para Memoria y registros respectivamente. Y usando incluso del DSP de sonido como también hemos comentado. A nivel de memoria podemos observar un uso del 85% de la RAM principal disponible. Un uso muy bajo de la VRAM del VDP1 sobre un 45% y un uso irregular de la VRAM del VDP2. En este caso de un 95% de la VRAM y de un 55% de la CRAM. No sé exactamente cómo puede ocupar tanto VRAM, cuando solo está usando dos layers y una de ella a 8BPP.

En este caso Scorcher es un juego de carreras post-apocalípticas. Donde se puede ver fácilmente que comparte código con su versión hermana de PC.

Podemos ver sobre todo como detalle clave sobre la versión SS, el uso de transparencias alpha reales vía software en algunos elementos en pantalla. En este caso en destellos parpadeantes blancos o fijos rojos en algunas pistas. Estos son dibujados sobre el propio framebuffer el VDP1 por la CPU. Podemos comprobarlo al ver que este no aparece como comando de dibujo en el debugger del VDP1 en Yabause. Y además con como el efecto se ve, al ser un blend multiplicativo muy suave contra los datos dibujados del VDP1. Finalmente dejando la típica mancha negra contra las áreas del Framebuffer que no has sido dibujadas y reservadas para el VDP2 en etapas siguientes. Finalmente podemos corroborar la naturaleza por software al observar en la consola real que cuando estamos muy cerca de estos destellos ocupando gran parte de la pantalla, la consola tarda mucho en procesarlo y baja la tasa de frames muy bruscamente con este efecto está en pantalla.

También se usan las “transparencias” nativas de SS, tanto las del VDP1 como las del VDP2. Para las de VDP1 podemos verlas muy bien usadas en los efectos de partículas de humo: verde o gris. Con bastantes partículas en pantalla superpuestas y con texturas de un tamaño considerable. Para el uso de transparencias del VDP2, podemos ver el uso típico en un layer con Cálculos de Color con Ratio. En este caso en el primer circuito en una capa RGB1 para representar las nubes en el cielo en movimiento.

Gráficamente estamos ante un juego que se está renderizando a 16BPP en todos sus elementos en pantalla del VDP1 y los fondos del VDP2 a 8BPP. A 320×224 a 30FPS la mayor parte del tiempo con 600 quads en pantalla normalmente. Solo con caídas como comentaba cuando la cámara pasa cerca de los destellos hechos por software. La versión de PC es prácticamente idéntica. Solo que esta posee un modo a 640×480, teniendo los menús y el juego el doble de resolución. Y dando opción de renderizar a 8BPP o 16BPP. Claramente esta segunda más prohibitiva para la época en los PC del momento el cual requería un mínimo de un Intel Pentium. Finalmente con las mismas transparencias pero más precisas y sin los problemas de SS.

El juego usa Gouraud en todos los elementos del escenario. Además tiene luz bakeada a color en ellos. Y hace uso de Depth Cueing hacia negro.

El nivel de uso de los procesadores es notable. Usando los 2xSH2 para el 3D y con signos de uso en el SCU-DSP de hasta un 25% de Memoria y 26% de registros. Hace uso de música CD-DA y de música MIDI, usándose la memoria del SCSP-DSP hasta un 60%.

El uso de memorias es de Scorcher es notable. El uso de la RAM principal está en 80%. El de la VRAM del VDP1 en un 95%. Y del VDP2 del 55% tanto para la VRAM como la CRAM.

Por último me gustaría poder señalar, que @Zyrobs vía comentarios comento que Scorcher podría estar haciendo carga y descarga al vuelo de datos gráficos de la VRAM del VDP1. No he podido contrastar este dato, de tal forma si así fuera. Seria otro gran hito técnico para este juego junto al proceso de transparencias reales vía CPU y escritura/lectura del Frame-buffer en tiempo de dibujo y ejecución.

  • Hexen

    Hexen fue lanzado por primera vez en el 1997-03-31. Extrañamente 3 meses antes que en PS1. Y podríamos decir que mejor port, por poco la verdad. De este port, también del motor Doom, sé encargo para GT otro equipo totalmente diferente al de Doom. Rage, el equipo de UK, cede el testigo a ATOD, un equipo de Suecia. Estos optan por un camino totalmente diferente, con sus pros y sus contras.

El juego está renderizado a 320×224, más que en PS1 a 256×224. Ambos a 15BPP, pero en realidad con datos gráficos entre 4 y 8BPP. En SS corre en las estancias medias entre 25 y 30FPS. En las más grandes a 20FPS, pudiendo caer a 14FPS en estancias muy grandes y profundadas.En PS1 incluso va peor, extrañamente. Como curiosidad en estancias muy pequeñas puede llegar a 60FPS. Parece que tiene los FPS desbloqueados como el Duke Nukem 3D de PS1.

A nivel de elementos en pantalla no es alto, sobre los 100 quads quizá más. Hay que tener en cuenta como renderiza Hexen de SS el motor de Doom en esta ocasión. Los desarrolladores optaron por escribir toda la parte de dibujado de paredes, suelos y techos por software y procesado por los 2xSH2, para después mandarlo al NBG1 del VDP2 como un fondo a 8BPP. Con un coste en la resolución de las texturas, que están a la mitad prácticamente. Por otra parte los elementos de sprites típicos son dibujados por el VDP1 y su vez el VDP1 dibuja quads negros para hacer máscara y las veces de paredes para ocultar los sprites. También se aprovecha el VDP1 para iluminar los sprites mediante Gouraud color para la iluminación y desvanecimiento de fondo o Depth Cueing. También usa el CC de Semi-Transparencia+Gouraud para efectos de partículas como el humo, sopena que solo mezclan con los pocos elementos que dibuja el VDP1 y no contra el VDP2 la mayoría. Además de usar un CC del VDP1 realmente caro como es este Semi-Transparencia+Gouraud. En fin, con todo se valora que al menos usaran las transparencias en este “Doom”.

Ni que decir tiene que el problema de rendimiento de este Hexen, como en el Doom, pero bastante menos. Es del lado de la CPU. El VDP1 no está sufriendo nada en este port.

Este juego tiene la típica iluminación de Doom, aunque sin estar perfectamente implementada como debería. Las manos/armas no parecen recibir la iluminación, en Doom al menos si. En los sprites es algo errático, parece que si en los relámpagos del inicio, pero después en zonas oscuras de las mazmorras no. Sin embargo en PS1 como en Doom, si se ve perfectamente la correlación.

El sonido en este juego tiene al curioso. Podemos ver una librería de sonido escrito por Virtually Unreal Ltd. para Probe, para el uso de ADPCM en SFX, que ya vi en Alien Trilogy y Die Hard Trilogy. ¿es posible que se estén usando sonido FX ADPCM? No lo sé. Por otra parte vemos el driver típico de SEGA. Si podemos ver un uso del DSP de sonido tipico del 35% de memoria.

La calidad de los FMV en esta versión es notable. Usando Cinepak+PCM. Pero con una calidad alta. 320×200 a 30FPS, Y el flujo de audio es bastante justo a 22254 Hz 8 bits Mono. Además renderizado en el VDP1.

El uso del hardware es bastante bueno. La memoria principal está en 70% de uso. La VRAM del VDP1 en un 80%. Y la VRAM del VDP2 en un 40% y la CRAM también en un 40%.

7. Lo difícil de «ver»: Efectos de sonido con Reverberación y/o Echo

Estamos acabado. Cuando pongo difícil de «ver», en realidad es de «oír». Pero me refiero a que es/era difícil encontrar juegos en SS donde podamos percibir, «ver», un cambio de sonido al cambiar de lugar. Sin embargo en PSX lo recuerdo perfectamente. Aún más me dolía más en ports, donde lo echaba aún más de menos. Y como con los gráficos, no entendía porque no estaba.

Antes de avanzar, me gustaría dejar claro que en muchas melodías MIDI de SS se puede percibir el uso del Echo o Reverb, en sus notas y composiciones. Incluso en algunos efectos de sonido o jingles. Para mí un ejemplo claro de ello son las melodías principales de Shining Force III. Pero digamos, sonido ambiente o con ejemplos de salas o túneles, no he sido capaz de encontrar.

En esta investigación donde he podido llegar a comprender la máquina hasta sus límites, incluso a la PSX. He visto que este aspecto quería tratarlo. No deja de ser curioso, más cuando en las especificaciones de sonido de SS desde el inicio se deja claro que puede hacer este efecto.

Cuando indagas en la documentación oficial y SDK, entiendes que ha pasado. Cuando en PSX se accedía al efecto de marras con una simple función en su librería de desarrollo, sin más. En SS, a parte de usar una función que en este caso usa las capacidades DSP digitales del chip de sonido Yamaha personalizado para SS. El equipo de desarrollo tenia que tener el «Linker» y el “eLinker (3D Sound)” que era un software de desarrollo extra para cargar estos efectos en sus proyectos.

Otra vez nos encontramos como Sony simplifico lo mismo magistralmente. Donde SEGA daba un chip de sonido con un DSP para efectos totalmente programables, es decir una bestia. Que además mezclaba sonido hasta 32 canales FM y/o PCM. Además de combinarlos en forma de MIDIs, los cuales se crearon con las «SEGA Sound Library» primero y más adelante con el «SDK CyberSound». Todo esto gobernado por una CPU M68000 de 16bit dedicada para todo ello.

El asunto estaba que para aprovechar al máximo el chip de sonido había que pasar por caja de SEGA y comprar el hardware extra al básico de desarrollo. Estamos hablando que la SS podía tener sonido 3D. Mediante el DSP de su chip de sonido. Un locura para la época. En serio. Pero SEGA y/o Yamaha no lo sé, prefirieron intentar monetizar esta parte de la consola un poco más, cargándoselo a los devs. Estos que ya iban pasados con el resto de «extras» de la consola, no me extraña que pasarán de sacar más provecho de esta bestia de chip de sonido.

Pero como decimos, al lado de esto, algo tan sencillo como meter eco o reverberación en un túnel o en una sala. En SS era muy caro en todos los sentidos. Y en PSX extremadamente barato y sencillo. Con el mismo SDK y con un función donde ya tenias el efecto a la mano.

Y hete aquí el quid de la cuestión. Esto se pudo traducir, en que solo grandes compañías se podían permitir tal desembolso. Mientras todas, pequeñas y grandes en PSX lo usaban, dando valor añadido frente a la SS, cuando esta podía hacerlo de sobras o mejor.

Puede que al final de la vida, mediante trucos o software se pudiese cargar módulos de efectos sin hardware. O que incluso yo lo haya interpretado mal. Y se pudiese desde el inicio. O que incluso SEGA llego a facilitarlo con últimos Kits de desarrollo.

Estamos hablando, posiblemente, del chip que antes se empezó a desarrollar para SS. De la documentación disponible es de los que tiene fecha más antigua, desde el 1993. No deja de ser curioso, que no estuviera 100% listo para el lanzamiento, con una de sus características más potentes el sonido 3D.

He estado mirando las Sound Tool. ¡Y aún estoy en shock! Pensaba que solo se podía usar el «Linker» y «eLinker» con una Sound Board o Sound Box. Pero parece(porque no lo he probado) por lo que he visto en el uso básico de las herramientas y repasando manuales oficiales, se podría usar sin hardware extra.

Lo que realmente me ha dejado en shock es el tema de Qsound y Yamaha3D. El «eLinker» es el que los tiene disponibles, a parte de otros módulos presentes en el «Linker» pero con más opciones. El que nos interesa el módulo Reverb. En ambos «Linker» tiene lo básico a parte de los preset según tipo de «sala».

Hoy sé un poco más sobre el magnífico sonido de la SS. Confirmo problemas importantes, como pasar por caja cara a los desarrolladores. Era una sangría por parte de SEGA y Yamaha. Entiendo que el Hardware no era esencial, pero para acceder a estas características tenias que tener el software y el Apple MAC, como mínimo. Ya era una inversión. Y si además querías el módulo avanzado, pagar algo más. E incluso royalties, 30 yenes pone por título. O eso he entendido al traducir los textos legales.

En la documentación se habla que a fecha 28/02/1995 no estaba aún disponible. Y la fecha más antigua de la documentación al respecto es 08/03/1995 del eLinker. Estas fechas quieren decir que no se pudo aprovechar para el lanzamiento, y que estuvo aún en desarrollo durante el prelanzamiento y primera ola de juegos. Y que llego ya para la segunda ola con el driver de SEGA 1.31, retrasando su uso, conocimiento y percepción de los clientes en los juegos.

Mientras en PSX las características finales de sonido estaban de salida.

Por último añadir. Que todas estas herramientas para el DSP de sonido son programas optimizados por Yamaha. Parece también que había la posibilidad de programar directamente sobre el, con un lenguaje de ensamblador que SEGA documento más hacia adelante.

¿Al final se consiguió arreglar esta situación de desventaja?

SI y NO. Si porque el hardware de la SS era plenamente capaz. De hecho más capaz que el de PSX. No, porque yo al menos no he visto(escuchado) claramente el uso de ello en muchos, claramente solo en SEGA Rally en el túnel del segundo nivel. Y para este análisis alguno más que listare más adelante como posibles.

Puedo listar juegos donde se sabe que se usa al menos QSound o Dolby Surround, que son dos tecnologías de sonido donde existen valores de Reverb o Echo. En que niveles o partes no lo sé, la verdad.

He llegado a detectar, en algunos casos más claro y en otros menos, hasta un 9.6% de total de juegos analizados. 

Estoy seguro que deben a ver más. Pero con los actuales emuladores es lo máximo que podido determinar.

Es cierto que he detectado actividad del DSP de sonido en la inmensa mayoría de títulos, en muchos sobre un 35%. En los que sé que se usa el efecto cerca de un 90%.

Ahí va la lista de lo que encontrado:

Juegos donde parece que hay:

  • Stellar Assault SS →Intro inicio
  • Touge King – The Spirits (1995-11-10) → En túneles
  • Sega WorldWide Soccer 97 / 98 → Solo en menús. Música + voces en música todo con eco y reverberación
  • Robotica: Cybernation Revolt
  • From TV Animation Slam Dunk: I Love Basketball
  • Touge King – The Spirits / High Velocity: Mountain Racing Challenge
  • Linkle Liver Story
  • Panzaer Dragoon Zwei→ zonas con túneles o cuevas
  • Dragon Force
  • Mortal Kombat II
  • The Story of Thor 2 / The Legend of Oasis / Thor: Seireioukiden
  • Fatal Fury 3
  • NiGHTS into Dreams
  • NBA Action 96
  • PriCla (Princess Clara) Daisakusen
  • Sega WorldWide Soccer 97 / Victory Goal ’96
  • NBA Jam Extreme
  • Shining the Holy Ark
  • Drift King Syutokoh Battle 97 / Shutokou Battle ’97: Tsuchiya Keiichi & Bandou Masaaki (1997-02-28) → En túneles
  • Manx TT → En túneles
  • Touge King the Spirits 2 (1997-04-18) → En túneles
  • Sky Target
  • Salamander Deluxe Plus Pack
  • Söldnerschild / Soldnerschild
  • Super Robot Wars F
  • Super Robot Taisen F Kanketsuhen
  • Devil Summoner: Soul Hackers
  • NBA Live 98
  • Devil Summoner Soul Hackers: Akuma Zensho Dainishuu
  • Panzer Dragoon Saga → Seguro, archivos .exb y en la primera sala los pasos y fx resuenan junto a la música.
  • Burning Rangers → En juego 3D.Música y voces todo con eco y reverberación
  • Techno Motor
  • Dragon Force II
  • Code R (1998-07-09)
  • Radiant Silvergun

QSound – 2D Games

  • X-Men: Children of the Atom (1995)
  • Street Fighter: The Movie (1995)
  • Arthur to Astaroth no Nazomakaimura: Incredible Toons (1996)
  • Ide Yousuke Meijin no Shin Jissen Mahjong (1996)
  • Street Fighter II Movie (1996)
  • Super Puzzle Fighter II Turbo (1996)
  • Tenchi wo Kurau II: Sekiheki no Tatakai (1996)
  • Mega Man X3 (1996)
  • Night Warriors: Darkstalkers’ Revenge (1996)
  • Street Fighter Alpha (1996)
  • Street Fighter Collection (1997)
  • Marvel Super Heroes (1997)
  • Cyberbots: FullMetal Madness (1997)
  • X-Men vs. Street Fighter (1997)
  • Pocket Fighter (1998)
  • Marvel Super Heroes vs. Street Fighter (1998)
  • Vampire Savior: The Lord of Vampire (1998)
  • Street Fighter Zero 3 (1999)
  • Dungeons & Dragons Collection (1999)

QSound – 3D Games

  • Madden NFL 97 (1996) → Anunciado pero no comprobado.
  • NiGHTS into Dreams (1996) → Anunciado pero no comprobado.
  • SEGA Rally Championship (1995-12) → En Túnel 2ª Nivel.
  • Sonic R (1997) Túneles → Anunciado pero no comprobado.

Dolby Surround

  • FIFA Soccer 96 (1995) → Anunciado pero no comprobado.
  • Road Rash (1996) Túneles → Anunciado pero no comprobado.
  • Shockwave Assault (1996)→ Anunciado pero no comprobado.
  • Madden NFL 98 (1997) → Anunciado pero no comprobado.
  • Croc: Legend of the Gobbos (1997) → Anunciado comprobado.
  • FIFA Road to World Cup 98 (1997) → Anunciado pero parece que al final no incluido
  • World League Soccer ’98 (1998) → Anunciado comprobado.

Como de constumbre nos quedamos con una seleccion que representa bien este punto:

  • SEGA Rally Championship

    Lanzado en el 1995-12-29. Recuerdo nítidamente ver este juego en su lanzamiento en Europa por la misma fecha. Llego a la tienda de videojuegos de mi pueblo “Legend”. En aquel momento la PS1 ya había conquistado a mucha gente con Tekken y Ridge Racer. Contra el VF1 y Daytona USA 1, que se veían peores en comparación. ¡Incluso recuerdo que salió Shinobi X y Bug! Que levantaron un poco el ánimo con la Saturn en aquella temprana guerra. Contra batallas perdidas de la intro de Rayman y el primer Dragon Ball Z, claramente inferior en SS con respecto a PS1. Pero Sega Rally cuando se puso y se veía como la recreativa, suave y con los mismos gráficos(muy parecidos realmente seamos honestos en su momento). Todas las bocas se cerraron. Y de repente la Saturn tubo la delantera momentánea con respecto a PS1.

Sega Rally fue una recreativa que se convirtió en clásica, al nivel de Outrun, nada más salir. SEGA estaba en aquella época tocada por la mano de dios. Y esta recreativa fue uno más de sus increíbles aciertos. La placa Model 2A ya estaba pegando fuerte en aquel momento. Y bueno no tardo mucho en coger el camino a nuestras casas. Se desarrollo en menos de un año. Teniendo en cuenta que el arcade salio en 02-1995. Con la suerte de que ha estas alturas los SDK ya estaban algo más maduros, no como en el caso de Daytona USA.

AM3 liderado por Tetsuya Mizuguchi consiguió una conversión perfecta. Con licencias por supuesto. La resolución original estaba en 496 x 384 y para SS sé llevo al máximo en su modo 15BPP 352×256. Posiblemente se podría haber ido a 640×480 a 8BPP pues este juego no tiene iluminación con Gouraud. Si tiene algún tipo de iluminación, que creo tampoco, es plano, el cual es posible reproducirlo en 8BPP con paletas. Y que además toda su información gráfica esta 4BPP o 8BPP de color. De cualquier modo. Sega Rally en SS corre a 30FPS totalmente estables. Dando una sensación igual al original en todo, movimiento y físicas. Llegando a poner en pantallas 900 quads sin problema. Por otra parte se está usando el VDP2 para la UI y para el fondo del horizonte rotado con el RGB0.

Estamos ante uno de los pocos juegos que sabemos con certeza que está usando Qsound disponible vía hardware en el SCSP-DSP. Es fácil percibir el sonido posicionado y la reverberación en los túneles en el juego. Y seguramente es gracias a este. Vemos un uso del DSP de sonido alto hasta un 70% de la memoria. Como curiosidad hay tres drivers de sonido diferentes en este juego:

– sddrvs.dat: @Driver Ver-1.31 95/06/20 SATURN(S) sampleNao Kas V0.00c

– esddrvs.dat: @Rally 10/18 Nao SATURN(S) CHECK Nao V0.07 Kas V0.00c

– p2sddrvs.dat: @Driver Ver-1.40 SATURN(S) CHECK Nao V0.07+ 10/18 Kas V0.00c

El uso del hardware como no podía ser menos es sobresaliente. Se están usando los 2xSH2, y se ven señales de uso típicas del SCU-DSP. Por otra parte el uso de la memoria principal este en un 80% la LRAM y un 70% de la HRAM. La VRAM del VDP1 se usa en un 85% mientras el VDP2 están en un 60% de la VRAM y un 60% de la CRAM.

  • NiGHTS into Dreams

    Lanzado en el 1996-07-05. También tengo el recuerdo de ver este juego recién llegado a la tienda de videojuegos de mi pueblo, con el mando 3D, si no recuerdo mal. Bueno lo que sí recuerdo eran las peleas para jugarlo de la propietaria(Mari Paz) con su pareja del momento(Fernando). Mira que, si no recuerdo mal, en aquel tiempo estaba el Ristar pegando fuerte también por allí y así Maripaz lo pasaba mejor.

En fin hablar de NiGHTS es hablar del segundo intento de Yuji Naka de que le tocase la lotería como con Sonic. Estuvo cerca, hay que reconocérselo, pero no llegó a Sonic. NiGHTS tiene personalidad y carisma. Pero como juego no termina de definirse tan claramente como Sonic en su momento. Técnicamente es intachable para Saturn y el momento. Y a nivel de arte, es brutal. Captura la esencia infantil de los sueños. Pero como juego 3D y para el momento, quizás el público esperábamos un plataformas de algún modo. Y claro un Sonic. Quizás todo ello sumado hizo que NiGHTS quedase como algo pasajero. Y no memorable. Incluso tengo mejor recuerdo de Ristar en aquel tiempo como mascota que de NiGHTS. No se, es mi impresión.

NiGHTS es el único juego en el que he podido percibir que hace una carga mientras está ejecutando gráficos o procesos 3D. Una especie de carga transparente, como hace Crash Bandicoot antes de entrar en los niveles o la carga del C:SoN entre partes del castillo. No se si hay más ejemplos en SS, en PS1 conocemos alguno más como el mismo Soul Reaver.

NiGHTS está casi al máximo de resolución posible del VDP1 en modo 15BPP: 352×240. La máxima es la variante pal 352 x 256. Con todo esta muy bien. El juego corre a 30FPS totalmente estables en todo momento. Y la cantidad de geometría en pantalla máxima está alrededor de los 700 quads de los cuales un 90% tienen Gouraud para iluminación bakeada o depth cueing o iluminación dinámica. Todos los elementos 3D tienen función de Depth cueing pero los elementos 3D mediante Gouraud y los billboard mediante cambio de paleta de color.

NiGHTS tiene iluminación dinámica múltiple y por fuente a color y con Gouraud. Tan solo en los personajes protagonistas, pero no deja de ser sumamente espectacular para el momento y la máquina. Puede que una de las razones del buen rendimiento incluso con iluminación es que el motor de NiGHTS está usando las librerías SGL, posiblemente las 2.x que ya tenían iluminación dinámica,

El Sonic Team no se iba a quedar corto intentando poner a la Sega Saturn al límite. Y como no fueron a por todas con las transparencias. Este hace uso de todas las posibilidades que da la máquina. Así podemos encontrar Semi-Transparencia del VDP1 en algunos elementos billboard.

También se usa extensivamente las posibilidades de transparencia del VDP2, desde transparencia por capa en el NGB1 sobre el fondo. O aún mejor con la función de cálculo de color y ratios con elementos del VDP1 sobre el VDP2. Aquí se usa por ejemplo para el efecto de desvanecimiento del plano VDP2 RGB0 en las fases de los enemigos. O efectos chulos como un enemigo final que se hace invisible contra el fondo total del VDP2 dando un aspecto de portal o de desparecer a otra dimensión. Este último efecto se logra usando la función de cálculo de color extendido, que permite hacer mezclas de color entre más de 2 capas. Es posible que incluso usaran el efecto de Color de línea insertado en el menú de inicio. Pero este es más difícil de detectar ya que ningún emulador lo señala en sus debuggers.

Por supuesto se usa extensivamente el modo mesh del VDP1 en elementos 3D e incluso de forma simulada en el VDP2 en la capa NBG3 para el efecto de torbellino de Nights.

El sonido en NiGHTS no fue descuidado. Podemos ver en driver que el programador principal(A.Miyazawa) se ocupa del mismo. No los autores típicos del driver de sonido de SEGA. Usa música CD-DA, pero también MIDI usando todos los canales del chip de sonido además de efectos DSP. Por otra parte este juego esta listado como uno de los pocos que usa Qsound, la verdad es que es difícil de percibir durante el juego. Por último la posibilidad de que use algún sonido con ADPCM. Ya que en el CD podemos ver archivos .adp que son archivos ADPCM de la librería SBL de SS.

Donde estoy seguro sé que se usa ADPCM es para el stream de audio de los FMV. NiGHTS es el primero, suena realmente bien y además esta Estéreo. Por la parte de la imagen la compresión del stream de imagen es media, notándose los artefactos de compresión más de lo que se merece el gran CGI de la intro. La resolución es muy buena 320×200 aproximadamente. Posiblemente a 15FPS. Ya que no es un contenedor estándar de CPK de SEGA. Si se puede ver la versión en la cabecera en este caso Film 1.08. Se renderiza en una capa de VDP2 a 24bits de color lo cual hace que no se pierdan colores. Como curiosidad final, añadir que NiGHTS es de los pocos juegos que está en formato CD-XA, con la segunda pista en MODO2/2352. Y las pistas de .adp y de .cpk no se pueden leer de forma normal al tener este formato de CD. Lo cual además ya indica que es ADPCM XA seguro.

El uso del hardware es soberbio. Usa los 2xSH2 tanto para los FMV como el 3D. Según un usuario de Segaxtreme usando el 100% del SH2 esclavo en momentos puntuales. Hay señales débiles de uso del SCU-DSP, posiblemente para transferencia desde el Bus-A. Estamos hablando de que la LRAM esta al 95% y la HRAM al 90%. La VRAM del VDP1 al 95% y la del VDP2 al 70%. Finalmente la CRAM del VDP2 esta al 75%.

  • Shockwave Assault

    Lanzado en el 1996-07-05 siendo un desarrollo a la 3ª ola de un desarrollador de USA. Shockwave Assault no deja de ser un port medio de un título original de 3DO, posiblemente la mejor versión. Después de un año fue portado simultáneamente para PC/PS1 y finalmente para SS con medio año de diferencia con respecto a las anteriores y casi dos años con respecto al original. Al menos la ventaja fue que salio con las misiones del original más la expansión. Que en el resto de versiones se vendieron por separado.

A una resolución de 320×240 a 15BPP igual que el resto de versiones. Aunque esa profundidad de color solo se alcanza en las capas del VDP2, en el VDP1 los elementos están en su mayoría en 4BPP LUT. El motor usa Gouraud para el Depth cueing no así para la iluminación. La cual si está presente bakeada en el resto de versiones. También como curiosidad añadir que el motor tiene 3 niveles de subdivisión o LOD en el terreno con mip-maps(16×16 / 32×64 / 128×32). Está presente en todas la versiones. El juego corre a 30FPS totalmente estables con 400 quads aproximadamente en pantalla.

La única transparencia que hay en este juego es la mirilla.

Por otra parte es posible que podamos tener un render-to-texture en el mini FMV y en el radar con mapa que se ve en la cabina en una capa del VDP2.

Una de las cosas más interesantes de título es que unos de los poco donde el símbolo de Dolby Surround sale en el propio juego. Realmente no sabemos si este está en los streams de audio de los diálogos o de las cinemáticas. O si realmente está integrado en el DSP de procesador de sonido. Lo que si vemos es uso de la memoria del DSP a un 35%. La música es CD-DA principalmente. Usando una versión del driver de SEGA de sonido bastante antigua la 1.31 de 20-06-95.

Los FMV de este juego son magníficos están a 320×224 15FPS con un bitrate generoso de 1700 kbps, muy cerca de la resolución de PS1 320×240, pero claro el codec de PS1 se muestra superior en los colores y artefactos como suele ser habitual. Ya el material original tiene una muy buena calidad. Y el trabajo hecho con el codec Cinepak es de los mejores de catálogo de SS, parece que la versión PC comparte los mismo videos. El stream de sonido además en este Cinepak es excelente, estamos hablando 22050 Hz a 16bits y en Estéreo. La única pega es que estos son renderizados en el VDP1 perdiendo la calidad de color final de codec. El codec que se usa para los pequeños clips de inicio de misión es desconocido, aunque tiene una calidad de color y compresión muy buena.

El uso del hardware es correcto. Usando los 2xSH2 para los FMV y 3D. Con signos típicos de uso del SCU-DSP(25% memoria y 26% registros). Por parte de las memorias el uso de las principales se situa en el 75% de LRAM y del 90% de HRAM. Del 90% de la VRAM de VDP1. Y del 20% de la VRAM del VDP2 y del 65% de la CRAM.

7.1 Lo difícil de «ver» – Bola EXTRA I: ADPCM y CD-ROM XA

Estaba acabando, pero casi finalizando mi investigación, me he topado con una última «feature» interesante en esta guerra particular: PSX vs SS. La compresión de audio para sonidos FX o Música durante el juego. Como ya sabemos la principal diferencia entre el hardware de sonido de PSX y SS, es que la primera descomprime y reproduce ADPCM por hardware. Mientras que SS PCM.

Este tema es aún más curioso porque el resto de la competencia, CDi y 3DO, podían descomprimir ADPCM por hardware. En el caso de la 3DO mediante el DSP he visto en su SDK que estaba plenamente soportado. En la CD-i igual que PSX o SNES, completamente nativo. La Jaguar tenía también un DSP completamente programable, pero no parece que llegue al de la 3DO, ni he visto rastros de implementación en su SDK.

Como curiosidad he podido ver como desde años atrás en Arcades múltiples sistemas ya usaban ADPCM en algún tipo de calidad, no cercana al CD pero aceptable. La más temprana de la propia SEGA en el System16 en 1985. Taito siguió a SEGA en el 1988 con su placa Taito B. La siguiente que he visto más temprana fue Microprose en 1990. Destacar el caso de SNK en sus famosas MVS también en 1990. Y más adelante Konami o Data East en 1991. No deja de ser curioso que SEGA no tuviera un sistema de ADPCM por hardware, aunque fuese parcialmente como sus hermana System16.

Las ventajas de usar ADPCM son varias. Menos espacio, hasta 4 veces menos, calidad prácticamente idéntica a un PCM. Pocos recursos para descomprimir. Podía ser accedida al vuelo y hacer stream desde el CD. Hacer loops más rápidos y limpios que el CDDA, este último no deja de ser un PCM crudo o AIFF. Poder almacenar más sonido en el CD-ROM o en la RAM. Poder tener músicas o sonidos largos con bajo espacio y alta calidad. Desventajas tenia. No dejaba de ser una tecnología propietaria, parece que no muy cara. Pero pocas más.

Como podemos observar, de nuevo Sony lo hizo mejor en este aspecto. Pero SEGA no tardo en (medio) arreglar esta situación. Ofreciendo a partir de casi el lanzamiento (a finales del prelanzamiento) de la consola en sus SBL(a partir del 1994-10-14 antes un desarrollo de CSK/CRI desde 1991) primero y poco más adelante también en las SGL, el poder descomprimir un stream ADPCM o CD-XA mediante la descompresión por CPU y unas librerías sencillas para los programadores. Todo esto quiere decir, que de nuevo, no se pudo aprovechar para el lanzamiento durante el desarrollo en el prelanzamiento, y primera ola de juegos. Este ya se fue para la segunda ola, retrasando su uso, conocimiento y percepción de los clientes en los juegos. Mientras en PSX estaba también desde salida y prelanzemiento.

¿Con cual CPU o cuantas descomprimía ADPCM con la librería SBL? Lo más seguro que con alguno de los dos SH2. En la documentación no queda claro. Si habla de un coste de entre 4% a un 33% de proceso para calidades entre de entre 11 kHz mono a 44 kHz Estéreo.

Comparando la capacidad de lectura la vuelo en el CD-ROM con PS1. PS1 puede con hasta 8 ADPCM streams(Estéreo = 16 streams mono) a 2x CD-ROM por hardware. SS por el contrario solo 1 ADPCM steam(Estéreo = 2 streams mono) a 2x CD-ROM. Por hardware puede hasta con 2 PCM streams(Estéreo = 4 streams mono) a 2x CD-ROM. En este último tiene sentido contra PS1 porque ADPCM contra PCM es 4 veces menos. Por lo tanto con igual ancho de banda de CD-ROM la SS tiene un limite 4 veces superior al leer PCM.

Alguien podría decir porque si al leer ADPCM que es 4 veces menos datos, solo puede reproducir 1 stream. Y la explicación está en que SS tiene que leer el ADPCM, guardarlo en memoria, para después descomprimirlo vía CPU, el PCM resultado almacenarlo en memoria de sonido y reproducirlo. Duplicando o triplicando, si no más, el proceso con respecto a PS1. Supongo que la implementación de la librería SBL, logro este resultado con la suficiente robustez y garantía de funcionamiento para el momento. Aunque teóricamente, bajo mi punto de vista, la SS podría descomprimir y reproducir, al menos 3 streams mono en ADPCM. Más, leyendo del CD-ROM al vuelo lo veo complicado. En memoria quizás podría con alguno más, si son archivos pequeños, máximo 4 o 5.

Todo lo expuesto y teorizado numéricamente depende tanto para PS1 como SS, de la calidad de los streams. No es lo mismo un stream a 8000hz que uno a 44100hz. Lo normal estaba entre 11025 Hz y 22050 Hz. También los estándares a 18900 Hz CD-XA Mode C y 37800 Hz CD-XA Mode B. Con una profundidad de bits estándar es de 4bit, la cual es equivalente a 16 bit real.

Por otra parte la implementación ADPCM de Duck tenia dos calidades. El estándar de 4-bits y una de 3-bits que bajaba aún más los kbps para las calidades equivalentes. Realmente desconocemos que cantidad de proceso ocupaba la descompresión para la SS. Debería ser muy poco, ya que encontramos FMV con ADPCM de Duck usando solo un SH2 para el video y el audio.

Ya en el 1997-98 mediante la ayuda de CSK/CRI, la cual ya se encargo del ADPCM en la librería SBL y SGL. Desarrollo ADX, que es un ADPCM, pero muy optimizado y con mejores características. El soporte ADPCM por software en SS llego al máximo. No sabemos si daba la posibilidad de descomprimir varios archivos de sonidos a la vez desde la RAM, lo cual pondría la balanza aún más en equilibrio con la PSX. Lo que si parecía que hacía es descomprimir hasta 3 stream al vuelo(uno de ellos de datos inclusive, es decir cargar un nivel mientras lee otro de música estéreo por ejemplo) leyendo desde el CD, pudiendo leer dentro de un mismo archivo varias pistas y hacer bucles sin ruidos, típicos del CD-Audio. Minimizando el uso de la CPU(sobre un 1%) y la memoria para su reproducción. Más que suficiente la verdad. Usando, estoy casi seguro, el SCU-DSP para la descompresión como he podido percibir en juegos que usan ADX para stream o FMV como: Burning Rangers o Lunar 2. O al menos para la transferencia de datos entre buses.

Por último señalar, que las third partys también desarrollaron sus propios formatos de archivos y descompresores ADPCM “like”, para sonidos o músicas para SS. Casos como EA, Probe, SNK… quizás alguno más, pero son los únicos que he podido ver con datos claros. Lo curioso del caso, es que posiblemente fueron los primeros títulos de SS en usar ADPCM, ambos(Alien Trilogy y Road Rash) a mediados del 1996, algo más de año y medio después del lanzamiento de SS. El primer juego First party con ADPCM fue NiGHTS por la misma fecha 07-1997. Puede que haya alguno anterior, pero no lo he podido ver.

¿Al final se consiguió arreglar esta situación de desventaja?

SI y NO. Como decimos, SI porque SEGA en sus SDK básicos(SBL) brindó una librería para poder descomprimir ADPCM y CD-XA, hasta un stream. Más adelante mediante CRI SDK incluso mejor, pero es posible que seria otro caso de pagar más para poder tener esta característica. Esto último no lo sé a ciencia cierta.

También como hemos dicho, se ve en muchos juegos de 3rd partys como hay uso de ADPCM o XA. Supongo para facilitar los ports o desarrollos entre PSX y SS.

Y NO, porque no tenemos constancia de CRI ADX diese la posibilidad de reproducir varios sonidos en la SoundRAM a la vez, y porque la descompresión no está soportada por hardware. O al menos no tengo constancia o no sé llego a usar de alguna manera eficaz en paralelo el SCU-DSP o el mismo M68x para ello.

Idealmente, bajo mi punto de vista, el SH1 en el bloque del CD-Rom en el bus A seria el candidato idóneo para descomprimir el ADPCM y mandarlo al SCSP. Por su potencia, memoria dedicada y el acceso a la lectura del CD-Rom en primera instancia. Pero la dificultad para usarlo era enorme porque primero habría que sobrescribir la ROM que lo controlaba y solo hacer esto era titanio, imposible no pero extremadamente complicado.

Lo que si me ha quedado claro y prácticamente seguro es el uso del SCU-DSP por parte del descompresor de CRI ADX, pero esto siguen siendo suposiciones mías al ver el uso del mismo en muchos juegos con ADX como Burning Rangers.

Otra duda que queda en este camino para mí es. Si en algún audio con ADPCM en SS sé llego a aplicar el Filtro “Low Pass/High or Pass/Band Pas”, que también poseía el SCSP-DSP mediante sus módulos como el de Eco o Reverberación. Como la PSX. Este filtro, de “Paso bajo o Alto” era muy útil con las ondas ADPCM para limpiarlas y sacarles el máximo de su calidad. Si no podían oír bastante metálico el sonido. Aunque estoy casi seguro, porque he detectado en muchos videos o juegos que usan ADPCM código en el SCSP-DSP. Y para terminar con SCSP-DSP, me queda la duda si cabría la posibilidad de usarlo para descomprimir ADPCM+Low Filter dentro de esta unidad, de manera similar al DSP de la 3DO. Aunque fuese una parte del ADPCM.

Para terminar comentar que tanto Probe(Alien Trilogy) como SNK(Metal Slug) hacen uso de ADPCM en sonidos FX.

Lo que en estos dos casos podemos apreciar es que, la sincronización no es del todo perfecta con retrasos al iniciar o acabar un sonido. Es posible que sea un bug con arreglo, o no sea la mejor opción usar ADPCM para FX. Y sé mejor opción reservarlo para Speech largos, voces cortas o música/sonido ambiente.

No podría pasar sin hablar, aunque fuese someramente, de los drivers de sonido para el SCSP. Podemos observar que en su inmensa mayoría todos los desarrolladores usaban los drivers de SEGA. Muchos curiosamente versiones tempranas o muy desactualizadas, incluso de los primeros kits de desarrollo. Sin embargo, las first party por supuesto iban casi con la más actual. Y las second party también con drivers más nuevos. Más hacia el final y las grandes compañías usan las mejores versiones e incluso alguna compañía tienen un driver propio, o quizás customizado. Como es el caso de Game Arts, Capcom o algunos estudios de SEGA internos como Red y AM2. Expongo una pequeña lista con las versiones del driver de SEGA oficial y años que he visto, puede que falten:

Year D/M Ver New
1994 13/10 1.14 *ADPCM SBL
1.24
1.25
1.27
1.28
1.29
1.30
1995 20/06 1.31 3D Sound
1.33
2.00
1996 25/01 2.04
2.08
2.09
2.08
2.09
02/07 2.10
1997 08/07 2.20 *ADX

He llegado a detectar el uso de ADPCM durante el juego, no FMV, en un 11,2% del total de juegos analizados. Quizá pocos, pero muchos más de los que esperaba la verdad.

Ahí va la lista de lo que encontrado:

Posibles juegos ADPCM:

  • Gex (1995-12-18)
  • Gundam Side Story 3  Kidou Senshi Gundam Gaiden III: Sabakareshi Mono (1997-03)
  • Rockman X4 (Mega Man X4) (1997-08)

Juegos ADPCM casi confirmados:

IMA ADPCM de SBL:

  • Magic Knight Rayearth (.ADP) (1995-08-25) → Confirmado Diálogos
  • Neon Genesis Evangelion: 1st Impression (1996-03-01) ← Confirmado CD-XA MODE2/2336
  • Kuusou Kagaku Sekai Gulliver Boy (adpcm.dat) (1996-03-22) ← Diálogos
  • NiGHTS into Dreams (.ADP) (1996-07-05) → CD-XA MODE2/2352
  • Sega WorldWide Soccer 97 / Victory Goal ’96 (1996-11) ← Confirmado CD-XA MODE2/2336
  • Samurai Shodown RPG (1997-06-27) ← Confirmado XA Multistream
  • Sonic Jam (.ADP) (1997-06-20)← Confirmado
  • Shinsetsu Samurai Spirits Bushidou Retsuden (1997-06-27)← Confirmado ADPCM XA Multi-stream voces
  • Ten Pin Alley (.ADP) (1997-11-15) → Confirmado
  • Kidou Senkan Nadesico – Yappari Saigo wa Ai ga Katsu (.ADP) (1997) ← Confirmado
  • Super Robot Taisen F (.XA) (1997-09-25) ← Confirmado CD-XA MODE2/2352
  • Neon Genesis Evangelion 2nd Impression (.ADP) (1997) ← Confirmado CD-XA MODE2/2336
  • SEGAta Sanshirou Shinkenyugi (.XA) (1998) ← Confirmado
  • Sega Ages – Phantasy Star Collection (.ADP) (1998) ← Confirmado. Música. Fx posible.
  • Sega Ages – I Love Mickey Mouse – Fushigi no Oshiro Daibouken & I Love Donald Duck – Georgia Ou no Hihou (.ADP) (1998)← Confirmado. Música. Fx posible.
  • Marvel Super Heroes vs. Street Fighter (1998-10-22) (.ADP) ←Confirmado

ADPCM de EA:

  • Road Rash (1996-07-26) ← Confirmado. Música.
  • Andretti Racing (.ADP) (1996-12-20)  ← Confirmado. Speechs.
  • Soviet Strike (eng_xa.res) (1997-02-17)
  • Crusader: No Remorse
  • FIFA 97 / 98 (1997) ← Confirmado. .STR
    • 22Khz Mono Electronic Arts EA-XA 4-bit ADPCM v1 (mono/interleave) 94 kbps
  • NBA 97 / 98 (1997)
  • Madden 97 / 98 (1996 / 97)
  • Nascar 98 (1997)

OKI ADPCM

  • Akumajo Dracula X: Gekka no Yasokyoku (aka: Castlevania: Symphony of the Night) (1998-06)
  • Genso Suikoden (1998-09)

ADPCM Desconocido:

  • Metal Slug (ADPCM.BIN) (1997-04-04) ← FXs casi seguro. Música CD-DA?
  • Croc: Legend of the Gobbos (.XA) (1997-09-17) ← ADPCM Argonaut ?

Juegos ADPCM confirmados:

ADPCM para Sonidos FX de Virtually Unreal para Probe.

  • Alien Trilogy (1996-07-04) ← FX casi seguro.
  • Die Hard Trilogy (1997-02-28) ← FX casi seguro.
  • Hexen (1997-03-31) ← No confirmado

ADPCM ADX de CRI:

  • Deep Fear (1997)
  • Grandia (1997) → uso de SCU-DSP
  • Burning Rangers (1998) ← Diálogos y música.  → uso de SCU-DSP
  • Baroque (1998)
  • Wachenröder (1998)
  • Code R (1998-07-09)
  • Lunar 2 – Eternal Blue (1998) ← Diálogos y música → uso de SCU-DSP
  • Device Reign (1999)

IMA ADPCM Estandar:

  • Street Fighter Zero 3 (1999) ← Música. FX ?

Duck Audio ADPCM:

  • La mayoría de juegos con codec Duck para FMV en su stream de audio.

Finalmente como hemos venido haciendo en todo este viaje, quedémonos con un último trio de elegidos para ejemplificar este punto con unos cuantos buenos juegos que lo usaron en SS:

  • FIFA 98

    Desarrollo de finales de la 4ª ola. Publicado en el 1997-12-17. Podemos ver como las third partys ya tenían un control de la máquina notable, en este caso Climax la encargada de este port.

En este FIFA, el problema como en otros ports no es como se aprovecha la máquina, porque se está haciendo muy bien. Si no el nivel de acabado y pulido final del juego. Al ser un port de las versiones PC y PSX, que además fue subcontratado a otro equipo externo, ocasionó que como en el FIFA 97, este FIFA 98 no hiciera justicia ni a la máquina, ni a la gran suma de trabajo en cada uno de sus apartados que hizo el equipo externo. Menos tiempo para el desarrollo total. Sin tiempo para rehacer las partes para correr correctamente en otro sistema diferente como SS. Empezando quizás más tarde y con los datos del proyecto atrasados. Pero con una fecha de lanzamiento similar o muy cercana. Todo esto se puede apreciar en pequeños detalles o pérdida total de grandes características que sí estaban en PC/PSX, y que SS podría haber tenido sin problema alguno técnico, tales como: La meteorología (implementada a nivel de selección, pero no visualmente), ajustes finales en animaciones y menús, proporciones de assets 3D, posiciones de las cámaras y visibilidad, sonido Dolby (anunciado pero no el juego final), suelo con degradado de horizonte (totalmente posible con el VDP2 y visto en WWS por ejemplo) y teniendo unos FMV magníficos (de los mejores del sistema) haber escalado a toda pantalla los mismos (totalmente posible mediante el zoom de VDP2).

Sin embargo como decimos Climax demuestra que conocía la máquina y en FIFA podemos encontrar como ellos aprovechan todos los procesadores disponibles según la situación. Para los FMV como sigue siendo habitual con los codecs de EA, en este FIFA con un vídeo a algo menos de aparente resolución, pero igual calidad. Aparente porque sigue estando en el tope del codec en SS 304×144, pero al ser reproducido en modo 352×256 de SS parece aún más pequeño. Usando el combo 2xSH2 + SCU-DSP, este último usando un 70% de la memoria y un 39% de registro del SCU-DSP. Posiblemente sé este usando el DSP del SCSP para algún tipo de filtro del sonido. El cual en el vídeo lo más probable sea PCM.

Ya en la parte de motor 3D, en este FIFA, no encontramos uso de SCU-DSP claro, hay un programa en memoria pero SSF no indica que sé este usando. Se usan lo 2xSH2 para el 3D. Puede que el SCU-DSP sé este usando para la descompresión de los comentarios o sonido ambiente, que casi seguro están en formato ADPCM propietario de EA. Pero esto es una suposición mía a día de hoy. Seguimos encontrando signos de uso de SCSP-DSP en el motor 3D, posiblemente para los mismos filtros de sonido. Porque echo o reverberación no lo he podido percibir claramente. Además curiosamente este juego estaba anunciado en su carátula como Dolby Surround, pero después dentro del juego no hay rastro de él.

Detallar que se usan modelos LOD para los jugadores y sombras, ayudando a que el juego corra entre 20/25FPS en los campos abiertos. No he podido cuantificar la cantidad de polígonos en este FIFA, pero podríamos decir que estará entre los 1000 y 1200 quads mínimos(puede que más), si contamos los equivalentes del RGB0, serian unos 768 más. Este juego podría estar sobre los 2000 quads. En PSX he visto cifras máximas de 6000 triángulos, unos 3000 quads equivalentes.

En los campos cubiertos durante el juego normal también se mantiene en los 20/25FPS, sin embargo en las repeticiones los FPS bajan a unos 12FPS cuando los Cristales están en primer plano con las Semi-Transparencias de VDP1 ocupando toda la pantalla o incluso con otros elementos que se están superponiendo por detrás.

Como nota curiosa los Cristales lejanos solo tienen Gouraud. Cuanto más cerca están, estos pasan a Gouraud Shading/Gouraud Shading+Half-transparent. Climax busco una forma de minimizar la carga de este efecto.

Si, FIFA 98 usa las transparencias VDP1 mucho, y bastante bien. Tenemos un uso de transparencia VDP1 en la UI de pausa y letreros de TV sin artefactos al ser rectángulos ortogonales pero sin funcionar contra los elementos que estan en VDP2. Como el campo en el RBG0, las sombras de los jugadores y algunas partes de las líneas del campo. Estas dos últimas features usando la transparencia de VDP1 a VDP2.

Como dato curioso en este juego los desarrolladores usan la transparencia de VDP1 a VDP2 con las sombras de forma muy original. Las sombras son Quads con Gouraud, y los valores del degradado resultante del propio Gouraud son usados después con los valores de cálculo de color y ratios del VDP2.

El uso de las memorias en este juego es notable. Llegando a un 70% de la RAM principal, a un 95% del VDP1 y de un 60% del VDP2.

Los menús están en alta resolución HD 704×256, aunque los fondos de VDP2 están ha 512×256. No ha aprovechado todo lo bien que podía el VDP2 para los menús. Incluso tengo mis dudas, de si podrían haber usado transparencias de VDP2 en vez del mesh.

Como curiosidad final señalar el uso de VDP2 bitmap a 1024×256 en las licencias del inicio. Pocas veces he visto ese modo utilizado. Aunque parece que la imagen no esta a esa resolución realmente, o no se ha ajustado bien al menos.

  • Deep Fear

    Lanzado el 1998-07-16 este ya es un juego de la 5ª ola. Último año ya prácticamente en Europa y USA. En Japón aún hubo hasta tres años más de vida, de desarrollo técnico quizás menos 1 o 2 máximo.

Deep Fear es el Resident Evil 2 que no llego a SS. O así lo vi yo en su momento. Técnicamente esta muy lejos de la saga de Capcom. Pero SEGA produjo un producto exclusivo de una notable calidad de producción(el doblaje no entraría en esta categoría XD), no quizás también en calidad técnica, pero bueno algo es algo.

Corriendo a una resolución de 320×256 15BPP aunque los datos gráficos están a 4BPP en el VDP1 y 8BPP en el VDP2. a 30FPS estables. Con unos modelos notablemente modelados y texturizados. Con animaciones un poco robóticas. He llegado a ver cerca de 700 quads en pantalla, puede que más. El VDP2 se utiliza para los fondos, UI y el inventario.

El juego tiene iluminación con fuente con Gouraud con color en todos los personajes y entidades 3D. Dinámica cuando hay disparos. Y tampoco hay muchos juegos de luces durante el juego.

Es extraño que este juego no use absolutamente ni una sola posibilidad de transparencia de la máquina. Más raro aun cuando por ejemplo en la sombra de los personajes hubiese sido totalmente posible como en Resident Evil, además de muy fácil con la función de cálculo de color más ratios con elementos del VDP1 sobre el VDP2, los fondos principalmente. El único efecto de “transparencia” que podemos ver es el cambio de offset a color para la alarma, efecto bajo agua o gas. Por lo demás una pena, un tipo de juego que da para lucir estas

El sonido, salvando el doblaje esta muy bien. Usando ADX para la música y los diálogos a una calidad excelente. Creo que también algunos sonidos más grandes como las puertas. Mostrando signos de uso de DSP muy altos sobre un 90%. Con casi total seguridad para hacer el eco y la reverberación de los escenarios. El driver de sonido usado es la versión 2.01 de abril del 1997.

Los FMVs en este titulo son muy numerosos. La calidad de los mismos es notable. Y la elección del codec Duck perfecta. Se usa en su modo 16BPP, pero francamente está comprimido perfectamente, el dithering es casi inapreciable y los artefactos prácticamente inexistentes. La calidad de imagen y sonido usada es un acuerdo perfecto para poder meter toda la inmensa cantidad de video en un solo CD. A 320×176 a 15FPS con un framerate de 1200Kbps más el stream de audio con el codec Duck ADPCM 4bit a 22050 Hz Estéreo. Renderizado en el VDP1 todo el trabajo de CGI luce al máximo en la SS.

El uso hardware ha estas alturas de vida de la máquina es muy alto. Los dos 2xSH2 se están usando tanto para los FMVs como el 3D. Hay signos fuertes de uso del SCU-DSP, en este caso hasta el 60% de la memoria y el 18% de registros, posiblemente para el audio ADX. Por parte de la memoria se usa un 55% del LRAM y un 75% del HRAM. Hasta un 65% de la VRAM del VDP1. Y un 45% de la VRAM y un 45% de la CRAM del VDP2.

  • Street Fighter Zero 3

    Lanzado en el 1999-08-06. Es ya uno de los últimos títulos desarrollados para el sistema. Podrías contarlo como juego de la 6ª ola de desarrollos de un equipo Japonés y en este caso de una gran Third party… de una gran saga. Y de un juego que no puede correr en mejor sistema que la SS.

SFZ3 ya fue portado antes en PS1, casi un año antes. Pero la versión de SS usaba el cartucho de expansión de 4MB, que ya de por si tiene más RAM, y conseguía una versión prácticamente idéntica al arcade y superior a la PS1. Tanto en cantidad de gráficos como en tiempos de carga.

La resolución es de 352×224 a 15BPP aunque el contenido original es a 4BPP sobre la CRAM de 24bits del VDP2, el original esta a 384×224 esta resolución no esta soportada por SS. Así que eligieron la máxima y más aproximada a la original. PS1 sin embargo esta a 368×224 entre media de las dos. PS1 de todas formas soporta la resolución del arcade original, posiblemente para ahorrar memoria decidieron bajar algo la misma. El juego corre a 60FPS perfectamente. No se ven más de 400 quads en pantalla.

Este juego no tiene transparencias en su versión original. Si así en su versión PS1. En SS hay alguna transparencia en los menús iniciales, pero el resto del juego se usa el modo mesh para las transparencias como en el arcade.

El sonido como en cualquier título de Capcom y más aún en un SF es magnifico. Además encontramos que están usando IMA ADPCM Estándar. Realmente desconozco si es la implementación de SBL o algún tipo licencia que adquirió Capcom. Lo que puedo decir es que la calidad sonora es brutal. Tampoco se si además sé uso para FX, posiblemente para las voces casi seguro. El driver si parece ser el oficial de SEGA. Una de las últimas versiones que he visto la 2.2.0 de julio del 1997. También podemos ver uso de música MIDI increíble en los menús. Por último podemos ver un uso de la memoria DSP de hasta un 35%. También podemos percibir efecto de reverberación o eco durante el juego, puede que se este usando el DSP para ello.

El único FMV en este juego es del logo de Capcom al inicio. Una animación mítica. La calidad del Cinepak+PCM es perfecta: 320×224 30FPS más PCM 44100 Hz 8bits Estéreo en el VDP2.

El uso del hardware es brutal. Por supuesto se usan los 2xSH2 tanto para el FMV como el juego 2D. La RAM principal está en un 60% la LRAM y a un 75% la HIRAM. La VRAM del VDP1 a un 95% y la VRAM del VDP2 a un 95% y la CRAM a un 95%. Por supuesto ocupando el cartucho de expansión.

9. Lo difícil de “cargar”: Carga sin parar el juego

En el tramo final de esta investigación. Y con la sombra del siempre Castlevania SotN, me dio por mirar esta feature. Más adelante al ver una entrevista al programador principal de Crash Bandicoot para PS1 y un video de Digital Foundry sobre Soul Reaver, volví a pensar sobre el tema e intentar indagar. Más adelante también por el comentario de @zyrobs en una de las entradas.

También recuerdo que @XL2 estuvo lidiando con la librería de carga/CD oficial de SEGA para SS. Y aunque al principio no obtenía buenos resultado. Consiguió al final cargar a la máxima velocidad del sistema. Las cargas de nivel en su juego son muy rápidas. Y él llena mucha RAM en varios pozos.

Como conclusión podríamos decir que la librería de SEGA era rápida, pero quizás falta mejor documentación, ejemplos y por supuesto acceso al código fuente.

¿Al final se consiguió arreglar esta situación de desventaja?

En este caso como en otro en SS. Tristemente no. A pesar de tener una librería para carga de CD bastante competente, pero cerrada. Los desarrolladores más atrevidos no lo tuvieron fácil, para poder usarla junto a la descompresión ADPCM o carga o descarga de datos gráficos.

Quizás por esto nos encontramos el caso infame de Castlevania de los pasillos de carga que no lo son. XD

Pero como en todo en SS de nuevo, era posible. Aún más aquí. SS tenia un bloque de CD-Rom super potente. Sin tener capacidad de ADPCM por hardware. Disponía de un procesador potente y de memoria donde ningún otro sistema tenia. De hecho en muchos juegos donde las cargas son “normales” la SS lo hace mucho más rápido. Incluso cargando aún más datos que en otros sistemas.

Ahí queda otra área por explorar por el homebrew y la escena.

Realmente no conozco juegos que tenga carga dinámica en SS de forma totalmente segura, ahí va una posible lista:

  • NiGHTS into Dreams.
  • Grandia, posiblemente.
  • Según @zyrobs Scorcher carga al vuelo durante la carrera. Yo no lo tengo tan claro la verdad.

Sin embargo se conocen en PSX con total certeza al menos los siguientes:

  • Soul reaver
  • Crash Bandicoot
  • Castlevania: Symphony of the Nights
  • Muy probablemente más.

 

Conclusiones:

La más clara. SS y PSX eran(o son, según se mire) dos máquinas extremadamente parecidas a final de cuentas. Tanto en las cifras finales y/o reales. Como en la manera de hacer las cosas. También otras consolas de ese momento compartían maneras de hacer las cosas como hemos visto.

En este camino, he podido romper muchos mitos en ambos lados. Y ahora más que nunca, aprecio todo el trabajo de las personas detrás de las compañías que propiciaron este momento histórico.

Me gustaría señalar que no se trata de lamentarse de nada, si no de resolver dudas, o intentar hallar como allí donde no llegó la SS, pudo o pudiera llegar.

Como vemos después de toda esta investigación. SS era una gran máquina. Los ingenieros de SEGA doméstico hicieron literalmente todo lo que pudieron y sabían. SEGA fue SEGA de nuevo y lo dio todo. En ambición no había nadie como ellos, quizás aún hoy día pero mucho menos.

Lo que tengo claro es que el producto de lo que hicieron, incluso a hoy día. Tiene un aspecto tanto en la imagen y sonido unicos. No hay ninguna consola que se vea y se oiga como la SS. Con sus pros y contras. Unido a la absurda complejidad que hay dentro de ella. Creo que es la máquina perfecta para mentes traviesas y curiosas. Y para un homebrew casi infinito.

Por lo demás, es una consola que recomiendo, por supuesto, a cualquiera. Con títulos únicos, mucha originalidad y diversión para ofrecer. Con juegos 2D y conversiones muy buenas. Además de exclusivos y por supuesto grandes juegos en 3D.

También desde aquí agradecer a la comunidad por su apoyo, hay muchos más, aquí una lista:

Y recomendar participar y apoyar proyectos de emulación como:

Dar las gracias a los desarrolladores históricos y actuales. Me gustaría señalar, que gracias a este commit, he podido ver los “polígonos” en pantalla de los juegos.

Gracias a Yaba Sanshiro he podido determinar los FPS de muchos juegos.

En sus últimas versiones es fácil ver el uso del modo de color de CRAM configurado, el uso de la función de gradación y de LCS Insertion. Y también con el modo wireframe la teselación o subdivisión o LOD.

O de SDKs de código abierto, puede que haya más, aquí una lista:

Epílogo: 

  • Voy a hacer una pausa en este proyecto personal. Hare alguna actualización y correcciones que ya tengo preparadas. Sobre todo en la primera parte y segunda parte. Pero no sé cuándo exactamente.
  • Me dedicare a partir de ahora hacer arte 3D y 2D para la comunidad homebrew de la SS. Y otro gran proyecto 😉 que tengo bastante desarrollado.
  • He pensado en la posibilidad de hacer un libro de todo esto. Varias personas me lo habéis pedido directamente. Si hay más personas interesadas dejarme algún comentario en el post o mandadme algún mensaje por el formulario. Ahora mismo tengo casi 230 páginas en el documento maestro. Y cientos de imágenes en mi archivo. Maquetando y añadiendo alguna tabla de las que están online, podría quedar un libro bonito de un mínimo 400 páginas, cerca de las 500 cálculo. Por supuesto la idea seria editarlo en Español e Inglés. Buscaría un traductor profesional para ello. Pero por ahora veamos el interés que tenéis e iré viendo.
  • Han quedado juegos por analizar más profundamente o juegos pendientes en su totalidad o gran parte: Sobre unos 90 de los 324 totales. Es algo que realmente no me preocupa. Si alguien quiere ayudar solo tiene que solicitar acceso a la tabla online y editarla. Si veo algo muy interesante puede que la actualice. En principio a corto plazo no creo.
  • Aún quedan cosas por descubrir.  Gracias a la emulación con sus debuggers esta posibilidad de llegar donde no sé llegó en su día es una realidad. Y ahora con la retro escena de SS tan viva es aún más probable.
  • Me quedan preguntas a desarrolladores notables en SS. Tengo una lista de programadores, técnicos y artistas. Con dudas concretas. Quien sabe…
  • Bajo mi punto de vista aún hay margen para alcanzar y romper hitos técnicos. Además yo los veo como metas que homebrew puede marcarse y romper, porque SS tiene capacidad esta capacidad. Dada a su complejidad y potencia en muchas de sus partes. Hare una lista bajo mi humilde visión:
    • Mejor BR trick: resolución y clipping.
      • Es cierto que XL2 ya lo ha superado. Pero como más retos veo:
        • Subir la resolución, no al máximo pero algo más.
        • Mejorar el clipping y solape de partes opacas y transparentes.
      • Por supuesto:
        • Documentarlo
        • Crear una librería robusta: Que permita el máximo de transparencias en el sistema combinándolo todo.
        • Crear ejemplos para juegos 2D y 3D.
    • Max. Polígonos e iluminación
      • De nuevo XL2 ha puesto el listón aquí ya muy alto. Pero el mismo dice que se puede hacer algo más.
      • Sinceramente, lo que creo necesario es tener unas librerías abiertas que estandarice el uso de esta parte en SS. A nivel de homebrew. Y poder combinar todos los procesadores de la mejor manera posible dentro de una pipeline estándar. Por ejemplo como el GTE de PS1 que tenía unas macros bien diseñadas y concretas. Tener algo similar para el uso del SCU-DSP o de los SH2 como DSP.
    • Max. Resolución BPP FPS
      • Soy un poco cabezón lo sé. Algunos cuando lo leáis, diréis: NO se puede!. Pero poder tener 512×256 en modo 16bits en el VDP1. ¿Algún truco de hardware o registro secreto? Alguna como las que descubrió el gran Charles MacDonald.
    • Animaciones Esqueleto dinámicas
      • Este tipo de animaciones son caras para estos sistemas. Se llegaron a ver en muchos juegos AAA. Como los de deportes de EA. Los juegos de lucha lo usaban. Pero una librería abierta que sea rápida no he visto. Creo que seria útil para la comunidad homebrew. En los últimos títulos de PS1 se veía en muchos 3ª persona o incluso 1ª usar este tipo de animación tan espectacular.
    • Render-to-texture
      • Un reto de los grandes:
        • Hacer una libreria abierta para poder usarlo tanto con el VDP1 como con los dos VDP2.
        • Conseguir hacer efectos de:
          • Pantalla gigante.
          • «Efectos a pantalla completa»: Fundidos, distorsiones, pseudo-motionblur…
          • «Efecto de refraccion» como el ninja de Metal Gear Solid 1 en PS1.
          • «Mapa de ambiente» como cristal en Tomb Raider 1 u otros assets en TR2 en PS1.
          • «Sombras mapeadas» como Crash 3 y Tony Hawk’s Pro Skater en PS1.
    • FMV DCT
      • Bueno, aquí hay tres retos:
        • Conseguir hacer Cinepak+ADK y tener un reproductor de código abierto. Para poder sustituir en traducciones de juegos o nuevos juegos.
        • Conseguir hacer un codec y reproductor para Duck Truemotion 1 para SS. Ya que los codecs que hay públicos son limitados sin modo 24BPP, por ejemplo. Para poder sustituir en traducciones de juegos o nuevos juegos.
        • Conseguir hacer un codec con base DCT como los de EA o Softdec óptimo para la SS. E intentar alcanzar la calidad de MDEC de PS1.
    • Sonido
      • ADPCM + FX en SoundRAM
        • ADPCM en general: Conseguir hacer un codec y reproductor de código abierto óptimo parecido a ADX, máximo 3 streams y carga de datos. Que use los procesadores disponibles para descomprimir. Para poder usarlo en nuevos juegos.
        • Poder tener FX en ADPCM en la SoundRAM como la PS1 para poder tener más sonido y más calidad en la SoundRAM. Parece que en el tiempo algún desarrollador hizo algo.
      • Chorus / Reverb easy
        • Poder usar los efectos DSP de chorus/reverb fácilmente para los desarrolladores de la escena.
    • Carga CD Dinámica de datos durante juego
      • Tener un código abierto y optimizado para el uso del CD en el sistema aprovechando sus enormes capacidades.
    • Seguro que me dejo más cosas. Pero hay queda mi visión actual a día de hoy.

Referencias:

(No esta todo, intentare completarlo)

 

Blogs:

https://news.ycombinator.com/item?id=10963796

Base datos juegos:

http://SEGAretro.org/

http://psxdatacenter.com/

Documentacion online:

SEGAxtreme

antime.kapsi.fi

SEGAretro

Exodus emulator hopseda la documentación japonesa online

Foros:

Anandtech:

Exophase en Foros de Anandtech

SEGA-16:

http://www.SEGA-16.com/forum/showthread.php?26920-Games-with-3D-graphics-running-at-60-fps-5th-Generation-Consoles

Youtube:

SEGA Saturn Graphic In-depth Investigations (English/French subtitled)

https://www.youtube.com/watch?v=f_OchOV_WDg

SEGA Saturn Video Formats (English/French subtitled)

https://www.youtube.com/watch?v=ev7x8MwLq2A[

Glosario:

(por acabar, no importante ahora)

*LOD: Level Of Detail. Crear varios modelos de diferente detalle, cantidad de polys, para un modelo específico. Para sustituir según la distancia a la cámara. En el FIFA 98 se ve perfectamente este efecto.

 

Fin, por fin XD

15 comentarios

  1. Pingback: Sega Saturn to the limit (IV) | David Gámiz Jiménez | Portfolio and Personal Site
  2. Pingback: Sega Saturn to the limit (I) | David Gámiz Jiménez | Portfolio and Personal Site
  3. Pingback: Sega Saturn to the limit (II) | David Gámiz Jiménez | Portfolio and Personal Site
  4. Pingback: Sega Saturn to the limit (III) | David Gámiz Jiménez | Portfolio and Personal Site

  7. Pero que pedazo de artículo, jamás creí encontrar algo así en español, llegue accidentalmente buscando info de los codecs de video de la SS, al recordar el opening del juego Burning Rangers, que se ve increíble para la media de intros en la SS y tenia la impresión de que era SoftDec + ADX (era Cinepak + ADX) quedé sorprendido de que ya se implementara en la SS, siendo mas familiar en la Dreamcast.

    Recuerdo que hay unos juegos tipo Anime/Eroge en la SS, que tienen los videos mas limpios y prefectos en el sistema, ojala su hubiesen utilizado en los demás juegos que usaban Anime en sus intro o videos in-game.

    Quiero un Libro!!!
    me encantan los libros de temas técnicos de consolas/pc retro y con imágenes!.

    Saludos desde un rincón lejano llamado Chile

    Responder

  8. So you’re actually going to write a thesis about Saturn, wow !

    «GunGriffon (1996-03) → Flat polygons with transparency in VDP2?» : yes, they seem to use that for the depth fog effect on the VDP2 background.

    «Sonic R (1997-11) → in the last circuit, which is transparent integer. Does it have fewer levels of gradient in the fade or does it not?» : the last circuit doesn’t use the progressive fading of sprites in the sky background (NBG0), because NBG0 is blended with 2 different ratios with RBG0 (the emerald shine) which is behind it :
    – 31:1 by standard color calculation when NBG0 is the top layer, when it isn’t behind sprites, which make RBG0 almost invisible (you can see it very faintly if you look carefully in dark areas of NBG0).
    – Half transparency by extended color calculation when NBG0 is the 2nd layer, when it’s behind sprites.
    If the programmer had enabled the progressive fading of sprites, the half transparency blend of NBG0 and RBG0 would have become progressively more visible as the sprites faded, making RBG0 very visible in an area where the sprites are almost not visible. This wouldn’t be coherent since the emerald shine should fade with the emerald track drawn with the sprites.

    Doom doesn’t use the line color screen for depth queing, it blends VDP1 graphics with a black NBG.

    On the contrary, Steep Slope Sliders is doing it’s depth queing effect by blending polygons with the Line Color Screen.

    Some more games that do (basic) render-to-texture :
    – Bug too ! : VDP1 frame buffer used as VDP1 texture in pause screen.
    – Virtual Hydlide : VDP1 frame buffer transferred to VDP2 layer in menu and map screens.

    The sprite framebuffer itself can generally be considered a type of render-to-texture since VDP2 post-processes it to add graphics and effects. The framebuffer can even be transformed when it’s a rotation type. In that case, VDP1 applies an affine transformation using part of VDP2 rotation parameter A, when it streams the framebuffer pixels to VDP2. Some examples :
    – Capcom Generation Vol.4 : 90° rotation and downscale in all the games with screen mode 1 or 2.
    – Hang-on GP : horizontal stretch, and rotation when turning.
    – Power drift : rotation when turning.
    – Shienryu in Sega Saturn mode : 90° rotation and downscale.

    About Sega rally, «VDP2 is being used for the UI and for the background of the horizon rotated with RGB0.» : the background is indeed displayed on RBG0 layer, but strangely it rotates only in the US version of the game, when using the cockpit view. In the later PAL and japanese versions, it only scrolls. Special stuff : the background moves at 60 fps, whil the rest of the graphics runs at 30 fps.

    About Nights :
    – «Transparencies / ECC / LCS-Ins» : I haven’t seen any situation where ECC can actually work in that game, either there’s only one layer with color calculation, or the background layer is in palette format and the color ram is in mode 1.
    – «Or cool effects like a final enemy that becomes invisible against the total background of the VDP2 giving a portal or disappearing aspect to another dimension. This last effect is achieved using the extended color calculation function» It’s standard color calculation of the final boss polygons with background NBG0. There’s certainly some palette swap occuring on NBG0 which make it look like it’s animated.
    – «El primer juego First party con ADPCM fue NiGHTS por la misma fecha 07-1997» : Ah, some spanish for a change ! Nights was released in 1996.

    Some games that load during gameplay (having a Saturn with CD led helps to check that) :
    – Crimewave : loads graphics, makes the game stutter a bit especially when using the larger view.
    – Galactic attack : loads only between levels, but manages to do it with smooth animation that transitions from one level to another.
    – House of the dead : loads music and ennemies textures, which get corrupted if the CD drive is in bad shape.
    – Mystaria : loads characters animation before each fight.
    – Panzer dragoon zwei : loads at some point during level, or before boss fight.

    Responder

    1. ¡Gracias Germán! ¡Disculpa acabo de ver el mensaje! 🙂 Sobre el libro. Bueno, lo sigo teniendo en mente. Pero entre el curro y la vida, está parado. Cuando tenga un hueco me pondré a terminar de corregir y añadir lo que quiero. Y a buscar formas para publicarlo. 😉

      Responder

  11. Tengo curiosidad por una conversión de recreativa de Taito (un simulador de trenes): Densha de Go! en PSX y Densha de Go! EX para Sega Saturn, las dos versiones normal y EX también existen en recreativa aunque no tengo claro las diferencias.

    En cualquier caso la placa arcade Taito JC parece estar basada en los bastante extendidos Texas Instruments TMS para hacer arcades en 3D en la época, los he probado en MAME pero no en emuladores de consolas.

    Pero hay un par de cosas que me han parecido interesantes:

    1-Mirando videos, la versión PSX me dá una sensación de como se mueve todo en pantalla extraña, la versión Saturn me pareció ese «como se mueve todo en pantalla» mas cercano a la recreativa original, quizas porque se basan los dos sistemas en quads aunque uno sea en vectores y otro en sprites deformados?.

    2-Creo que es el único juego de recreativa 3D no basado en las placas arcade de Saturn o PSX que a veces tuvieron alguna conversion entre ellas, ej «NBA JAM Extreme» o «Ray Storm» de sistema arcade basado en psx pero portados a Saturn. Digo esto porque hubiese sido interesante que más juegos de este tipo con TMS 3xxxx (Taito y Mydway) o las primeras placas arcade 3D de Konami, por decirlo de alguna manera «sistemas imparciales».

    Responder

  12. Enorme contribución para los amantes de Saturn, muchas gracias. La verdad es que me cuesta entender algunos conceptos de todo lo que has expuesto, pero quiero felicitarte por publicar este trabajo de investigación. Me encanta esta consola y me ha encantado también leer (parte de) tu artículo.
    Apoyo la idea de que saques un libro, ¿Sega lo respaldaría…?
    ¡Un saludo!

    Responder

    1. ¡Hola Gorka! ¡¡Muchas gracias!! sobre todo por leerte, incluso lo que has podido, el tocho que me marque. Es una consola y compañía apasionante. ¡Y qué tiempos! Sobre el libro, ya me gustaría, pero la verdad es que a día de hoy lo veo complicado, no por SEGA no se suele meter en nada de aporte de fans, sino por la vida! jejejej, pero no lo descarto. ¿Cuál parte es la que más te ha gustado? ¡Un saludo! 🙂

      Responder

  13. Perdona el retraso en responderte. Y no hay de qué.
    Aquella época fue especial, recuerdo probar la demo de Daytona USA que me venía con la Saturn y quedarme embelesado mirándola… En un período de transición de las 2D a las 3D había mucha experimentación y el salto generacional se notaba.
    ¿Que qué parte me ha gustado más…? La que he entendido, ¡ja, ja, ja!
    Me ha parecido muy instructiva tu indagación en los polígonos por segundo que podía mover Saturn, con sección dedicada a Sonic R y todo; me encantaba este juego, me lo compraron por Navidad y no paraba de jugarlo. Aunque reconozco que tardé en dominar el control, esas transparencias en los fondos y el resto de efectos gráficos me dejaron boquiabierto.
    También he leído la parte de las transparencias en Burning Rangers. Ese juego me pareció muy entretenido (y corto), con gráficos que iban un paso más allá y es bueno encontrar información sobre cómo consiguieron que Saturn pusiese todo aquello en pantalla. Leí en alguna parte que el Sonic Team utilizó uno de los procesadores de sonido para tareas de cálculo y así liberar las CPU principales para que la consola pudiera con más carga.

    Nada más de momento, seguiré leyendo tu artículo. ¡Un saludo!

    Responder

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.