SATURN - JUEGOS
VIRTUA FIGHTER’s
Virtua Fighter fue el título de lanzamiento de Saturn. Un título que quizá fue lanzado prematuramente, ya que ni siquiera AM2 dominaba completamente el HW.Esta es una captura de VF1 en un emulador de Saturn:
En pantalla tenemos dos personajes compuestos por polígonos planos.
El suelo también son polígonos, nótese que gastar ciclos de la cpu para el suelo deja menos ciclos para los luchadores, pero así está hecho este VF1. Incluso parte del marcador está dibujado por el VDP1. Si quitamos lo dibujado por el VDP1, solo queda el fondo.
Ahora nos vamos a VF2
Tenemos un montón de texturas que disimulan muy bien los “poligonazos” de la primera versión. Los luchadores siguen siendo creados por el VDP1, pero ahora el VDP2 tiene más tareas a su cargo, una capa es el edificio en ruinas, otra el fondo, otra el marcador y finalmente la capa de rotación es la que dibuja el suelo (que ya no son polígonos como sucedía en VF1).
Por tanto los personajes 3D están compuestos por polígonos texturados y el suelo es un plano abatido texturado. La evolución es más que evidente. Poner texturas nos ahorra poner polígonos en ciertas partes y meter más polígonos en otra. Por ejemplo, el pelo en VF1 son varios polígonos. En VF2 también pero al meter una textura de pelo, nos basta con poner un par (es una forma de hablar), y la textura hace el resto.
¿Cómo se aplican las texturas a los polígonos?
Esta es una captura de un emulador, aquí vemos como los luchadores son una suma de polígonos y en cada uno un sprite. Hay cientos de ellos.
Estas texturas están ubicadas en la memoria del VDP1.
DAYTONA USA
Daytona USA es el ejemplo perfecto que un juego que no “casa” con el HW de Saturn. Tanto los coches como el escenario son polígonos 3D, por tanto no podemos usar el VDP2 para liberar de trabajo al VDP1, no podemos hacerlo porque el suelo no es plano, no hay paredes planas ni techos. Sólo podemos usarlo para pintar el cielo y los marcadores.
Así que el recurso básico para ahorrarnos unos ciclos de computación no los tenemos.
Esta es la pantalla que vemos por la tele:
Esto es lo que pinta el VDP1. Suelo, coches, gradas, la noria... vamos, casi todo:
Ahora sólo el VDP2:
En una capa el fondo, en otra el marcador.
Como en VF, los sprites distorsionados están en memoria del VDP1, por ejemplo, la noria:
Esta sólo aparece en un lugar y por tanto está solo una vez en la VRAM, pero en cambio el público no está compuesto solo de un polígono, si no de varios. Como la textura del público ha de adaptarse a cada polígono, en memoria tenemos varios sprites distorsionados repetidos:
Esta son algunas de las texturas de nuestro coche, el VDP1 rotará y distorsionará:
En cuanto al reflejo en el cristal, obviamente no es calculado si no simulado con la textura.
GRANDIA
En este juego podemos andar por una ciudad con nuestro personaje. Los edificios proyectan sombras y los personajes, al entrar en la sombra, aparecen más oscuros. No parece haber problema alguno.
Este juego es un ejemplo de uso del VDP2 para ayudar en el 3D.Veamos:
- Los personajes son sprites (VDP1).
- El suelo es un plano abatido y texturado (VDP2).
- La sombra de los edificios está incluida en el suelo, es el mismo gráfico (VDP2).
- Los edificios están en 3D (VDP1).
Si el juego ve que las coordenadas de los personajes están dentro de una “zona de sombra”, cambia su sprite a un sprite oscuro y si salen de la sombra pone el sprite normal. Realmente parece haber una pequeña transición así que es posible que utilicen los cambios de color (brillo) del VDP1 para ello. Como no hay ningún sprite debajo, no hay problema en usar estos efectos.
No hay proyección de sombras en 3D ni cálculos exóticos, es simplemente habilidad del programador. Irónicamente la versión de Playstation no tenía este efecto
BURNING RANGERS
Un must-have si queremos ver de primera mano el uso de transparencias en Saturn.
Programado por el Sonic Team.
Veamos esta pantalla:
Ponemos unos recuadros para señalar las transparencias:
(1),(2) son parte del marcador del jugador, intuitivamente es una capa transparente del VDP2 situada por encima de todo. Hasta aquí nada extraordinario.
(3) es la sombra del jugador, vemos una trama. Esto es cosa del VPD1, parece lógico pues coincide en parte con los polígonos del jugador. Hasta aquí todo normal.
Luego tenemos (4) un fuego transparente en el fondo, aparentemente un sprite, está animado, intuimos que por tanto es creado por el VPD1. Pero el escenario está hecho en 3D no? Creado por tanto también por el VPD1. Por tanto aplicar transparencias podría resultar en problemas.
¿Y (5)? En la captura no se aprecia pero es una ventana transparente que deja ver lo que hay detrás, que son edificios.
De nuevo, la habilidad del programador supera las restricciones del HW.
Así funciona el juego en esta escena:
Las explosiones y la ventana son sprites, creadas por VDP1, y no son transparentes en este momento. Los sprites (llamas y ventana) son dibujadas a la mitad de la resolución original (se nota mucho pixelado). Esto se hace para acabar este paso lo más rápido posible.
Nótese que el perfil del personaje aparece “en negro”, es decir, el programador respeta ese “hueco” tanto si hay llamas como si movemos la cámara para que el personaje “tape” la ventana.
A continuación el VDP2 copia el framebuffer en una de sus capas por DMA. Por tanto tenemos los sprites en una capa del VDP2. No son transparentes.
El VDP1 borra el framebuffer y crea la escena 3D. Todo lo que no va a ser transparente, personaje y escenario.
Ahora el VDP2 puede mezclarlo todo:
- La capa de fondo.. al fondo (lo que se ve por la ventana).
- La capa del framebuffer con todo lo 3D no transparente encima (personaje, escenario). Se reescala a la resolución normal.
- La capa de sprites (llamas, ventanas) la ponemos encima y activamos la transparencia de esta capa sobre las que están debajo (las antes comentadas).
Realmente las llamas están en la capa situada “por encima” del personaje, pero como el programador ha sido hábil y se ha dejado el hueco del personaje, no aparecen por encima.
Esto se ve perfectamente en otra escena del juego:
En esa escena las llamas de la izquierda “se salen” de la habitación, aparecen por encima de la puerta. Se tiene en cuenta el personaje pero no el marco de la puerta para dibujarlas.
Otro truco de este juego es que los objetos “a pasar” del VDP1 al VDP2 son dibujados en un tamaño más pequeño del que vemos en pantalla. Es decir, VDP1 dibuja una versión reducida y luego VDP2 escala estos sprites (escala la capa claro), de forma que VDP1 acaba antes (con las llamas del ejemplo anterior) y puede dedicarse al 3D. El VDP2 es muy rápido escalando y haciendo transparencias.
Claro está, esto no evita pixelaciones pero es otro ejemplo de habilidad del programador. Además dependiendo de cuantos objetos transparentes tengamos en pantalla, este procesado hace que el framerate el juego se resienta.
En concreto este juego tiene ese defecto, al haber tanto procesado no puede llegar a mantener un framerate estable.
Es por eso que sigue usando tramas en ciertos casos, por ejemplo el personaje muestra una sombra todo el tiempo, esta es una trama.
TOMB RAIDER
Lara Croft debutó en Saturn, Sega se reservó la exclusividad 1 mes en su consola. Fue una exclusividad un tanto ridícula.Por tanto se puede decir que la versión de Play fue lanzada “al mismo tiempo” de cara al desarrollo.Ambas versiones fueron realizadas por separado para sacar lo mejor del HW en ambos casos, por tanto es una buena muestra de lo que daba de sí cada HW al principio de su carrera comercial. La versión de Saturn está muy conseguida, aunque la de Playstation es ligeramente mejor. En el apartado BONUS hablaremos sobre ambas versiones.
DOOM
Esta versión no aprovecha el HW de Saturn. ¿Por qué?Lo leemos en estas declaraciones del desarrollador del port para Saturn, Jim Bagley:
“Cuando empecé el proyecto tuve que hacer una demo para que Id Software lo aprobase. Comencé extrayendo los niveles, el audio y las texturas de los archivos WAD de la versión PC, e hice mi versión de Saturn, que renderizaba aprovechando el hardware 3D (se refiere a los VDPs). Envié la demo y un par de días después recibí una llamada de John Carmack, que me dijo que bajo ninguna circunstancia podía usar el hardware 3D para dibujar la pantalla. Tenía que usar los procesadores como en el PC. Por suerte me gustan los desafíos. Así que usé los SH-2 para dibujar la pantalla, cada uno dibujaba la mitad de la pantalla. Para reducir la complejidad decidí usar los niveles de Playstation. Estoy bastante contento con el resultado.”
El motivo de no usar los VDPs era que el aspecto del juego difería del de PC. Es decir, si suelos y techos son hechos por el VDP2, con planos abatidos no va a verse igual que con polígonos. La demo también usaba el VDP1 para tratar las texturas de las paredes, ya hemos visto como trata el VDP1 los sprites estirados, rotados y deformados, a veces se ven bien, a veces no. Curiosamente esta demo iba muy rápida pero Carmack no dió su conformidad.
La versión final, que corre entera desde los SH-2, no va precisamente fina. Curiosamente mientras más lenta va, peor responden los controles, porque el juego da preferencia al renderizado del 3D sobre el procesado de los controles. Quizá por ello “tunearon” la cadencia de disparo de esta versión, que es superior al resto de versiones.
¿Hasta qué punto aprovechan los SH-2? No puedo dar una respuesta lamentablemente, no sé si podían haberles sacado más jugo. Lo que sé es que, como la versión de 32X, fue hecha a toda prisa para sacar el juego en la fecha que SEGA estableció.
PANZER DRAGOON
Esto es lo que vemos en el juego:
Esto es lo que renderiza el VDP1:
Tenemos al protagonista, a los enemigos, los objetos 3D del escenario y los marcadores.
Realmente no hay “tanto” 3D, la carga es mucho menor que en el Daytona USA por poner un ejemplo, pero la imagen final queda perfecta, muy bonita.
Como curiosidad los reflejos sobre el mar están hechos por el propio VDP1, pero no es una distorsión real, son sprites ya hechos con esa forma:
Esto es lo que hace el VDP2:
El mar está animado, es un plano abatido que además tiene un efecto sobre el propio fondo que simula el oleaje. Desde luego queda bonito y da el pego. En movimiento:
SONIC R
Sonic R es un juego de carreras con algunas cosas interesantes a comentar.
Aquí dos vídeos del creador donde podemos verlos:
https://www.youtube.com/watch?v=WDJgeuoaSvQ
https://www.youtube.com/watch?v=RvRG_v8XpC0
Para empezar tenemos un par de pantallas donde tenemos objetos 3D con reflejos “metálicos” (environment mapping), con la cabeza de Sonic o la R del logo del juego.
Este efecto no puede hacerse por HW en Saturn (pero sí en PlayStation), así que se realiza por soft.
Lo he señalado con las flechas:
Para conseguir este efecto, el equipo de desarrolladores hicieron un motor de renderizado por triángulos similar al que tiene la Playstation, que corre en el SH-2 esclavo. El SH-2 maestro, mientras tanto, puede correr otro código en paralelo.
El motivo de hacer un motor propio es la forma que tiene la Saturn de trabajar con polígonos texturados. El VDP1 coge un polígono y le aplica la textura al polígono, completa, pero no puedes coger un trozo determinado de la textura, solo podría cortarla y en forma rectangular. En el caso de la pantalla de carga (donde vemos a Sonic, Tails y Knuckles), la R tiene un reflejo. El reflejo es de esta textura:
Lo que hace el motor software es coger un trozo determinado de esa textura (en el frame que he capturado parte de la cara de Sonic), aplicarle un efecto y luego encajar ese trozo en la “R”. A medida que se mueve la “R”, el trozo que se refleja cambia. El VDP1 te obliga a coger toda la textura entera.
En el caso de la cabeza metálica, a lo Terminator T-1000, sucede lo mismo. Curiosamente el creador comenta en el vídeo que no usaron este efecto en el juego, sólo en las pantallas de carga. Imagino porque con ese procesado ya saturan el SH-2 esclavo.
Como prueba, aquí podemos ver que no hay polígonos, es el SH-2 esclavo el que crea, al vuelo, el sprite:
En cuanto al juego en sí, utiliza muy bien todos los recursos de Saturn.
Veamos esta pantalla:
Tenemos personajes 3D (como Sonic), hecho por el VDP1.
El camino también 3D, también VDP1. De forma inteligente este juego aplica a la parte final del camino (y de todo escenario 3D), transparencia sobre el fondo (no se ve mucho en la captura). De esta forma no aparece “de golpe” como en Daytona USA.
El agua y sus reflejos son cosa del VDP2, como en Panzer Dragoon. Veamos una captura sin el VDP1 (solo VDP2):
En una capa los marcadores, en otra el fondo, en otra el agua… muy bien repartido.
Hay un nivel secreto lleno de transparencias y efectos de colores.
Leave a Comment