Sega Saturn al límite (II)

david.gamiz.jimenez29 diciembre 201813 julio 2020

Aviso entrada 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 surga.

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:

Lo imposible de solventar: Triángulo vs Cuadrángulo.
1.1 Triángulo vs Cuadrángulo – Bola EXTRA: Mapeado UV
Lo menos complicado: Sombreado Gouraud e iluminación dinámica a color.
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
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”
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
Lo complicadísimo II: Render-to-texture
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
Lo difícil de “cargar”: Carga sin parar el juego
Conclusiones
Epilogo
Referencias
Glosario

3. Lo complicado I: Suavidad en juegos 3D = 500 / 1.000 / 1.500 / ~2.000 quads/frame = 25/30/60 FPS estables.

En resumen, la clave para la estabilidad en ambas máquinas se encuentra en estos 3 puntos:

1) Optimizar al máximo la pipeline de transformación e iluminación y el código para los procesadores disponibles.

2) Optimizar las llamadas entre la CPU/CPUs y la GPU/VDP1-2 para que ninguna esté esperando la otra. Y que haya un diálogo continuo y constante, sin paradas entre todos los elementos.

3) No exceder los límites de ciclos totales para dibujar un frame, de acuerdo con las primitivas más efectos dentro de la pipeline.

4) Optimizar el flujo de datos en el BUS/BUSES y optimizar el uso de los DMA sobre ellos. Sin exceder el máximo trafico posible, distribuyendo los procesos de la mejor manera posible.

Cuello de botella 1: La complejidad 2x o 3x

Conseguir una tasa alta o estable de frames, resolución(pantalla y texturas) y la calidad de color(pantalla y texturas) con respecto a PSX en versiones similares… No era una tarea sencilla. Y tener el doble(o triple) de variables a controlar en todo, no ayudaba a los programadores de la época. Empezando por no poder tener el triángulo como geometría primitiva y acabando por tener el doble(o triple) de pozos de memoria que gestionar.

Decidir qué variables usar para los juegos tal y como: la carga poligonal, los efectos en pantalla, el sombreado Gouraud, la iluminación dinámica, que resolución/profundidad color de pantalla y que resolución/profundidad de color en texturas. Ya de por si hacen la tarea de diseñar un motor complicada.

Si a eso le sumamos variables de naturaleza del hardware. Donde el equivalente de SS a PSX, estaba duplicado, si no más. Para verlo más claramente voy a hacer una comparativa sencilla pero precisa:

Empezando por la primitiva. El triángulo con 3 vértices en PSX, mientras en SS el cuadrángulo con 4 vértices.
CPU principal en PSX x1, en SS x2(SH2), sin contar el SH1, exclusiva para el acceso al CD-ROM y a la reproducción de MPEG-1 con una tarjeta de expansión, que no se podía programar(al día de hoy).
- Velocidades, ancho de bits y Potencia de cálculo/MIPS(teóricos):
  - PSX:
    - MIPS R3000A 32bits 33MHz 30MIPS
      - Co-procesador de vídeo MDEC 80MIPS
  - SS:
    - SH2 32bits 28MHz 28MIPS cada uno. 50MIPS total.
      - SCU-DSP 32bits 14Mhz 84MIPS.

El co-procesador geométrico(DSP): En PSX x1(GTE), en SS x3(2xSH2 y/o SCU-DSP).
- Velocidades y ancho de bits(teóricos):
  - PSX dentro del MIPS junto al MDEC:
    - GTE 32bits 33MHz 16.5 MOPS* (2 ciclos por MAC**) 41.25MOPS (0.8 ciclos DIV equivalente, con poca precisión)
      - 0,94MOPS (25 ciclos DIV real si se usa MIPS)
  - SS:
    - SH2 32bits 28MHz 28MOPS (2 ciclos por MAC) 28MOPS (2 ciclos por division DIV1 -> necesita DIV0S o DIV0U antes.)
    - SCU-DSP 32bits 14Mhz 14MOPS (1 ciclo por MAC, 2 ciclos de sistema)
      - Funcionan en paralelo con todo el sistema.
      - Excepto que no puede acceder al SH2 Esclavo o viceversa.
        
        EL SCU para el resto de funciones principales: 32bits 28Mhz.
    - Total MOPS para 2xSH2+SCU-DSP = 48 MOPS
    - Especial no-programable DSP fijo en VDP2: 28MOPS (Hace varios tipos de operaciones(Equivalentes MAC, DIV…) en 1 ciclo, solo para los planos rotados 3D)
      * MOPS: Millones de instrucciones por segundo
      ** MAC: Suma y producto en un solo ciclo.
GPU o Procesador de gráficos, en PSX x1 en SS x2(VDP1 y 2). El VDP1 en muchos aspectos era similar al “plot” de la PSX, sin embargo, en esencia el de la SS era 2D, mientras que el de la PSX era 3D. Y la diferencia estaba, en la capacidad de proceso de triángulos y de proyección de texturas en UV.
- Velocidades, ancho de bits y Color<>Relleno de pixeles/Mpixels(teóricos):
  - PSX:
    - GPU 33/53Mhz* V1:16/16bit V2:32bit 15bit<>33-66** Mpixels/s
      *No tengo clara la velocidad final de la GPU, al tener que componer la imagen final para la salida de TV, a 50/60hz. Y posible explicación de poder hasta 2 píxeles por ciclo máximo. En la documentación en línea de NO$PSX dice lo siguiente:
      - Video Clock
        The PSone/PAL video clock is the cpu clock multiplied by 11/7.
        CPU Clock = 33,868800MHz (44100Hz x 300h)
        Video Clock = 53,222400MHz (44100Hz x 300h x 11/7)
        **66Mpixels para Sprites sin escalado o rotación, solo trasladados y Polígonos Planos(sin textura).
  - SS:
    - VDP1: 28Mhz 16bit, 15bit color<>28Mpixels/s. // 8bit<>35* Mpixels/s
      *Borrado de Framebuffer a 2 pixeles por ciclo.
    - VDP2: 28/57Mhz* 16bit, 24-4bit color<>28** Mpixels/s.
      - Plano 3D rotado y/o 24bit<>28** Mpixels/s
        *No tengo clara la velocidad final del VDP2, al tener que componer la imagen final para la salida de TV, a 50/60hz.
        **No tiene ninguna penalización, porque tiene un margen interno de hasta 8 accesos(lectura/escritura) dentro de su pipeline. Y con estos puede realizar todas sus tareas especificadas.

Sonido, en PSX x1 en SS x2(M68000 y SCSP=Yamaha PCM/FM+DSP).
- PSX: SPU 33MHz ? 16bit
  - 24 voces, ADPCM(compresión 4:1 hardware) más efectos preestablecidos de Chorus y Reverberación.
- SS: SCSP 22Mhz 16bit. DSP 24bit.
  - 32 voces, PCM más efectos vía DSP programable para sonido era un extra en el chip de Sonido de SS para hacer efectos, incluso sonido 3D. Y de una alta complejidad, como no.
  - CPU Sound M68000: 16bit 11MHz 2MIPS
  - 1x DMA Interno entre M68000, SCSP y la Sound RAM

Memoria Gráfica o VRAM: En PSX 1x pozo, en SS 5x pozos(3x VDP1 y 2x VDP2). Facilitando el uso de semi-transparencias y efectos framebuffer como render-to-texture en el caso de PSX.
- Velocidades y ancho de bits(teóricos):
  - PSX *Versiones 1 y 2:
    - V1: VRAM (Puerto-Dual) 16bit 33MHz, 60ns cycles
    - V2: SGRAM 32bit 33MHz 30ns
  - SS: VRAM (SDRAM) 1,5MB Total VRAMs
    - VDP1:
      - VRAM*: 16bit 28MHz 34 ns
        *Lista Comandos, Patrones(Texturas), Tablas Gouraud y CLUT.
      - FrameBuffer:
        
        Back Buffer: 16-bit 28MHz 34ns
        
        Front Buffer: 16-bit 28MHz 34ns
    - VDP2:
      - VRAM*: 2x 16-bit 28Mhz 34ns
        *Accede a la vez a los dos bancos, divididos a su vez dos partes. Pudiendo hacer hasta 8 lecturas en un ciclo, sobre: Patrones, Tiles, Celulas, Planos, Mapas, Tablas de Coeficiente para Planos Rotados…
      - Color RAM: 4KB(dentro del VDP2) Bus Internal 32-bit 28Mhz
        *Bancos Paleta Color o Tablas de Coeficiente para Planos Rotados

La memoria principal o RAM: PSX 1x pozo y SS 2x pozos, igual cantidad: 2MB.
- Velocidades y ancho de bits(teóricos):
  - PSX:
    - EDO DRAM 32-bit 33Mhz 60ns
  - SS:
    - High RAM: SDRAM 32bit 28Mhz 34ns
    - Low RAM: FPM DRAM 32bit 22Mhz 45ns cycles / 70ns access
Y la memoria de sonido, que si eran iguales. Con 1x pozo por parte e igual cantidad: 512KB.
- Pero PSX podía usar compresión ADPCM por hardware, teniendo en realidad “más” memoria, hasta 4x veces.
- Tipos y velocidades:
  - PSX RAM ns?
  - SS FPM DRAM, 16bit, 20MHz, 50ns cycles, 70ns access
CD-ROM, igual velocidad y tecnologías anexas. SS tiene un controlador exclusivo mucho más potente y 512KB de memoria para Buffer, además de la cache. Esto significa que SS cargara más cantidad y en menos tiempo información de los discos.
- Cache, controlador y Buffer memoria:
  - PSX
    - 128KB cache
    - Motorola MC68HC05 (8bit single-chip CPU)
    - CD-Rom Buffer: ?
  - SS
    - 64KB cache
    - SH1 32bit, 20MHz 20MIPS
    - CD-Rom Buffer: 512KB FPM DRAM, 16bit, 20MHz, 50ns cycles, 80ns access
Y para remate. Los Buses:
- PSX 1x Bus para:
  - CPU + RAM + (GPU + VRAM)+ (SPU + SoundRAM) + Bloque CD-Rom + Etc…
    - 7x(6x reales) canales DMA, 1x activo: CPU, MDEC, GPU, SPU, PIO y memorias.
  - Velocidades y ancho de bits(teóricos):
    - 32bits 33Mhz 136MB/s
- SS 3x Buses para:
  - SCU en medio de los 3 buses.
    - 5x Canales DMA:
      - En SCU hasta 2x activos a la vez:
        
        2x Sobre elementos(procesadores y memorias) del BUS-A, BUS-B, BUS-C
        
        1x propio interno de la SCU para el DSP y la HighRAM.
      - 2x SH2 DMA interno sobre BUS-C con WorkRAM(H+L)
  - Bus-A: Cartucho + Bloque del CD-Rom(Lector CD-Rom + SH1 + CD-rom Cache + ROM)
  - Bus-B: (VDP1 + VRAM VDP1 + 2x FRAME-BUFFER) + (VDP2 + VRAM VDP2 + CRAM VDP2) + Bloque de sonido(M68000 + (SCSP+DSP) + SoundRAM)
  - Bus-C(CPU): CPUs + RAM(Hi/Lo) + ROM + SMPC(gestor de mandos o entradas)
  - Velocidades y ancho de bits(teóricos):
    - SCU: 32bit 28Mhz 114MB/s
      - DSP: 32bit 14Mhz 57MB/s
    - Bus A: 16/32bits 28MHz 57-114MB/s
    - Bus B: 16/32bits 28MHz 57-114MB/s
    - Bus C(CPU): 16/32bits 28MHz 57-114MB/s

En resumen, como podemos ver la empresa se ponía aún más cuesta arriba.

Cuello de botella 2: Uso parcial de la potencia total disponible

En los ports, en este momento llegaba el momento duro. Valorar los recursos necesarios(y de los que se disponían) y ante tal diferencia decidir que se quedaba y que no. La reducción de color o resolución en pantalla o texturas, era una medida para poder conseguir meter la cantidad de texturas similares en versiones de PSX y alcanzar la suavidad o tasa de frames de la misma.

La manera de distribuir la memoria y la potencia de cálculo de la SS, no ayudaban a igualar las características a la PSX. Y los programadores tendían a recargar el cálculo, los procesos y el flujo sobre sus Procesadores y los buses de la SS. Digamos que para no rehacerlo todo y para conseguir lo mismo en SS al mínimo coste de tiempo, se tendía ha esta mala praxis. Usando al final menos capacidad de proceso o memoria que la disponible realmente. En algunos caso la mitad, o menos, de total disponible en SS.

El tema estaba en saber o querer utilizar al máximo la potencia de cálculo que ofrecía SS. Porque en números brutos SS era más potente. Aunque el problema o reto era poner todo en sintonía para conseguirlo. Una mayoría de juegos usaban los 2x SH2 (de 258 juegos analizados, 142 hacen un uso claro del SH2 esclavo para proceso 3D o descompresión de FMV. Que es un 56,4% de total analizado, que podríamos extrapolarlo al total de catálogo.), “pocos” de manera eficiente.

Pocas compañías usaron el SCU-DSP de la SS, el cual era muy rápido, y él solo podía igualar al GTE de PSX en cálculo de MAC, esenciales en esta etapa de la pipeline. Si a este le sumamos los 2x SH2 en cálculo de MAC y DIV para el cálculo de proyección final. Estaríamos incluso por encima del GTE teóricamente.

Y finalmente, si en teoría se llegase, de alguna manera, a usar para calcular 3D el M68000 y el SH1 incluso mucho más. De estas últimas posibilidades no se conoce ningún juego o caso, pero en teoría sería posible al menos con el M68000 que está en el mismo bus que los SH2 y SCU. Usar el SH-1 puede que no fuese posible al estar en un bus diferente, aunque era bastante potente.

Cuello de botella 3: VDP1 Redibujado

También tenemos que tener en cuenta la diferencia al rellenar los pixeles que había entre PSX y SS. Y lo cual también había de tenerse en cuenta para optimizar los juegos. Los problemas derivados de esta diferencia estaban en que la SS, «desperdiciaba» relleno de pixeles.

Pues si en un quad con textura o plano(polígono llamado en la SS), que en esencia ambos son Sprites distorsionados. Cuando más deformados este el quad en vertical, es cuando la SS empezara a desperdiciar ciclos de pintado. Además de generar errores de repintado en efectos de semi-transparencia o incluso en las mismas texturas, ocasionándose un flikering, ya de por si normal(PSX o PC época) sin mip-mapping, pero con un poco más de ruido en las zonas más deformadas. En este vídeo de John Burton se explica perfectamente.

Con todo había “ventajas” derivadas para SS, que para PSX era una “desventaja”. Esta forma de dibujar hacia que la deformación por perspectiva fuera bastante inferior a PSX. De todas formas, existían soluciones via hardware o software para mitigar este gran problema del VDP1:

Hacer un clipping lo más eficiente posible. Problema y técnicas comunes con PSX, implementados en el hardware en ambas:
- Clipping 2D opciones usadas en SS: Aprovecha la capacidad de no escribir en zonas para ahorrar tiempo de dibujo, implementado tanto para el VDP1 y VDP2. Clipping System, Clipping user y/o Clipping windows. Por hardware en el caso de la SS. En PSX imagino que también.
- Clipping 3D opciones usadas en SS: Programados en ambas maquinas. Culling frustrum, Near/Far clipping, PVS… etc….
Técnicas del hardware especificas de SS, para compensar el desperdicio de dibujo por su forma de dibujar elementos 3D(distorsionados):
- High Speed Shrink: Ahorro de cálculo, estimando saltos sobre pixeles pares o impares dentro de una línea que ha sido reducida. Solo para elementos distorsionados como: Sprites escalados y Sprites distorsionados. He encontrado muchos juegos que no lo usan. El que más me sorprendió el mismísimo Tomb Raider* también: Loaded!*, Blast Chamber*…
  *Quizás en los casos que no se usa es porque desalineaba los texels de las texturas. Y según el desarrollador prefería optimizar el overdraw de VDP1 de otras formas. A perder calidad de rasterizado.
- Pre-Clipping: Ayuda al VDP1 a saber donde está la primitiva para dibujarla más rápido.
- End codes: Ahorro de dibujo de puntos en un línea o líneas completas de un patrón o textura.

Hacer Mip-mapping via software. Es decir usar una textura con menos resolución para cuando este más lejos. Implementado en ambas maquinas por software. Visto más en PSX(también por software pero integrado en sus SDK) que en SS. La pega era que ocupa más VRAM o CPU. Pero reduce el cuello de botella en el dibujado en ambas maquinas.

Pero la mayor de las desventajas es que la SS cuando ponía en pantalla, sin optimizar, la misma cantidad de información(geometría, texturas…) que PSX. La SS no podía mantener la tasa de relleno necesaria. Sin entrar en cálculos muy complicados de números.

Normalmente y actualmente se habla de Texelrate para gráficos 3D, lo cual en estas maquinas y tipo de tecnología no es aplicable bajo mi punto de vista. Podríamos hablar de “ciclos”, pero es un callejón sin salida también en estas máquinas. Sus VDP1/GPU dibujaban 3D por fuerza bruta. Dibujando píxeles lo más rápido posible, para dibujar sprites/patrones. Superponiendo estos sprites/patrones y al fin y al cabo aplicando efectos en los sprites/patrones o sobre estas mismas superposiciones: sombreado Gouraud o Semi-Transparencia. Una con sprites/patrones con forma cuadrada y otra triangular.

Eso sí, en el caso de la SS forzando el dibujado tradicional de patrones/sprites y en el caso de la PSX dibujando con un criterio óptimo. Y he aquí una de las claves, de la diferencia de rendimiento final efectivo y variante entre la SS y la PSX.

Pero en el resto, como en el coste final de dibujar las primitivas y sus efectos, es muy similar como veremos.

Finalmente, no pudiendo concretar los “ciclos” exactos, la aproximación que yo he hecho es el “costo” que tiene en cada consola el dibujado de cada patrón/sprite según el tipo de primitiva o efecto. Para así extrapolar la cantidad final de relleno de píxeles teóricos en cada caso y comparar entre ambas para sacar algún tipo de conclusión relacionada mínimamente. Haciendo la equivalencia en el costo final dibujando un QUAD completo a 16bit de color en ambas maquinas:

SS vs PSX – Equivalent Numbers QUADs & TRIs 16bit BPP_20181014_1.ods

Mis números están basados en los datos máximos de relleno de píxeles de cada máquina, y en los datos más precisos que he encontrado en los SDK, documentación o tutoriales oficiales de cada máquina sobre el “coste” en cada tipo de primitiva o proceso. He sido muy conservador con los datos y he evitado interpretaciones ventajistas. He optado por valores extremos para sacar las conclusiones con el máximo rigor posible. Y son los siguientes:

SS VDP1: 28 Mpixels/s max. Teórico. Polígono primitiva = Quad

Según una fórmula que podemos encontrar en tutorial realizado por varios ingenieros para SoA/SoE:

Ciclos = k + (x * y * l) + (y * n)

x/y = 8×8 en tutorial. Altura/Anchura en pixels del patrón/textura

k = 70; Se usa este valor el tutorial para Texturizado, que puede ser por los 16 ciclos para buscar una tabla de comando en la VRAM del VDP1 y otros 16 para procesarla. Aún sobran 38 ciclos, que podrían ser los necesarios para ejecutar la tabla de comandos en si en el VDP1.

k =70(anteriores) + 232 = 302; Se usa estos valores en el tutorial para Texturizado + Gouraud. Los 232 ciclos podrían ser los ciclos necesarios para aplicar la tabla de Gouraud, sobre el pattern o polígono plano. Y los 302 los ciclos totales de procesar el texturizado y aplicar la tabla de Gouraud.

l = 3 ; Se usa este valor en el tutorial para Texturizado y sombreado Gouraud. ¿Por penalización por redibujado?¿Accesos a leer color VDP2 u otra memoria? ¿Leer datos VDP1(color, pattern o Gouraud)? ¿Valor Fijo o Variable?

n = 5; Se usa este valor en tutorial para Texturizado y sombreado Gouraud. ¿Por Penalización por redibujado y cambio de línea? ¿Valor Fijo o Variable?

¿Porque se usan estos valores “k”, ”l” y “n” exactamente? No, lo sé.

El compañero Urian plantea una sólida interpretación y otro compañero en el foro de B eyond3d plantea otra diferentes pero con otra aproximación. Resultando una con más penalización que otra. Como digo, al día de hoy un misterio.

Con esta fórmula, he establecido el coste (unitario) que tiene para el VDP1 procesar cada tipo de primitiva básica:

Coste Sprite = 1 / 0,75*

*Esta penalización no está reflejada en ningún lado. Pero entiendo que si tanto para el VDP2 como para la GPU escalar con reducción tiene un coste, para el VDP1 también, aunque tenga una primitiva exclusiva para ello.

Coste polígono plano. Patrón 8×1 de un color = 1

Coste polígono texturizado = 0,77

Coste polígono con Gouraud = 0,43

Coste polígono con Semi-transparencia = 0,34-0,17*

*Entre 3 y 6 veces más. Mi teoría es que podría ser 3 veces como máximo si no hay distorsión en el quad. Es decir que no haya “redibujado”. Que es lo que haría repetir el proceso varias veces en los mismo píxeles sumado al propio del H-T. Sin el “redibujado”, solo cuento con leer el píxel de fondo, sumarlo con el procesado encima y el resultado dividirlo por dos. Si hubiese “redibujado” pasaría como dice el manual del VDP1 oficial de Sega que podría llegar a costar 6 veces más.

¿Pero en cuanto y porque he cuantificado el coste para el redibujado?

Bien he optado por presentar un caso donde una quad con perspectiva tiene una fuga de más de 45º con respecto a cada eje. Si no tiene fugas, significa que es ortogonal al plano de la cámara. Por lo tanto tendrá redibujado = 0. Pero en elementos 3D, este caso será mínimo. He buscado el peor caso posible, para buscar un escenario duro para el VDP1. Por eso he estimado que un quad con una perspectiva de más de 45º en cada uno de los ejes, podrá provocar hasta ⅔ de redibujado de pixeles/texels para ese quad, con/sin textura o con cualquier “cálculo de color del VDP1”. Lo que sería hasta tres veces más para “un solo pixel”. Una gran penalización, y quizás demasiado conservadora.

Redibujado penalización hasta = 0,3

Finalmente tenemos trucos del hardware que ayudan a hacer más rápido solo la etapa de texturizado. En el caso de la SS como hemos dicho anteriormente el HSS. No es la panacea, y tiene un leve coste de calidad de rasterizado.

HSS ON = 1,4

Aplicando estos valores unitarios sobre la tasa de relleno total obtenemos unos mín/max.

Donde el mín son los valores cuando la SS está en el peor escenario posible, que es con penalización por Sobredibujado y Semi-transparencia hasta 6 veces.

Y donde el máx. es sin penalización por Sobredibujado y con penalización por Semi-transparencia hasta 3 veces.

Sprite = 28 / 21

Polígono Plano No-Text = 28 / 28

Polígono Plano + Textura = 21 / 30,18

Polígono Plano No-Text + Transparencia = 1,43 / 4,76

Polígono Plano + Textura + Transparencia = 1,10 / 5,13

Polígono + Gouraud = 3,61 / 12,04

Polígono + Gouraud + Textura = 2,78 / 12,98

Polígono Plano No-Text + Gouraud + Transparencia = 0,61 / 2,05

Polígono + Gouraud + Textura + Transparencia = 0,47 / 2,21

Ahora vamos con Playstation:

PSX GPU: 33 MPixels/s max. Teórico. Polígono primitiva = Triangulo = 2x Triángulos = Quad

En una presentación de la Conferencia de SCEA en marzo del 96 nombrada “Advanced GPU” podemos ver:

Números brutos Ideales – Escritura de píxeles
33.8688 MegaPixels / Segundo
67.7376 MegaPixels / Segundo Sprite y Polígonos Planos cuando no están escalados o girados.

Velocidad de dibujo teórica cuando no está escalado o girado:
F3 , F4 , Sprites NO escalados y/o girados = 2 píxeles / ciclo = 66 megapíxeles / segundo

G3, GT3 en la memoria caché* = 1 píxel / ciclo = 33 megapíxeles / segundo

G3abr / GT3abr* = 0.5 pixel / ciclo = 16 megapíxeles / segundo

Leyenda: 3 = Triángulo ; 4 = Quad ; F = Sombreado plano ; G = Sombreado Gouraud ; abr = Alpha Blending Ratio

* Estos datos son confusos:

Se entiende que hacer Transparencia es el doble de tiempo. Por eso la mitad. Pero no deja claro si el GT3 es usando la cache de texturas o no. Por lo tanto nos se puede igualar el rendimiento de un polígono Gouraud sin textura a uno con textura. Hacer Gouraud tiene un coste, y texturizar también.

Se iguala el rendimiento de dibujar triangulo y quad, cuando se deja claro en Documentación y Tutoriales que la PSX hace dos triángulos para un quad. ¿Y lo hace en el mismo tiempo?

Lo que está claro es que la cache ayuda, pero si no esta penaliza.

Por eso yo añado y estimo estos datos siguientes mediante el resto de indicios que encontrado en el tutorial y documentación, que veremos después:

F3 , F4 , Sprites Escalado y/o girado = 1 píxel / ciclo

FT3 sin cache = 0,8 píxel / ciclo

G3 / GT3 sin cache = 0,5 – 0,3 píxel / ciclo

G3abr / GT3abr sin cache = 0.25 – 0,15pixel / ciclo

En la documentación del “Profiler Analizer” se habla que:

Se tarda 256 ciclos max por frame o por polígono, lo cual no me queda claro. Aunque más adelante habla de entre 200 y 300 ciclos para un polígono, la frase concreta:
- Cuando se mostrarán 100.000 polígonos por segundo, por ejemplo, la longitud de un bucle para procesar un polígono será de aproximadamente 200 a 300 ciclos.
- Lo cual coincide, en parte, con los ciclos de la SS. Me parece un buen dato.

Hacer un pixel transparente cuesta hasta 3 veces más.**
**Para la transparencia tendríamos dos valores, este (3 veces) y el anterior(2 veces) en el tutorial. Ambos me parecen dos escenarios reales y posibles. Quizás casos extremos. Según el área, tipo de primitiva o tipo de color.

En la documentación “Run-Time Library Overview 4.4” en la seccion “Primitive Rendering Speed ” se puede ver:

Después de esta tabla podemos encontrar unos cálculos sencillos sobre la premisa de número de lecturas y/o escrituras para dibujar un patrón de 100×100 pixeles.

Pero todos estos datos me parecen confusos e inexactos. Porque no establece una relación entre el coste de texturizar y añadir Sombreado Gouraud. Igualando el coste real, de hacer solo la tarea de texturizado y después sumar Gouraud. A texturizar solo, o hacer sombreado Gouraud solo. Cuando en el tutorial deja claro que es otro proceso dentro de la pipeline. Es como si asumiese que fuese “instantáneo” hacer el Gouraud cuando antes has texturizado. Lo cual no tiene sentido.

Yo he asumido que hay un coste, y lo he intentado cuantificar de forma racional. Dejando el coste entre medias de un polígono plano y un polígono con Gouraud.

Por último hay otra cosa curiosa, y que para mí es inadmisible. Cuando pone * en la tabla anterior. Asume que la GPU de la PSX le da igual rellenar un triangulo que un quad. Cuando en el tutorial y documentación, dejan claro que cuando la GPU hace un quad, está rellenando dos triángulos. Es decir asume que hacer un triangulo es igual a hacer dos. Esto es un disparate. Yo con lógica racional he asumido que es el doble de trabajo.

Y los números finales me dan la razón lógica, estableciendo una diferencia o equivalencia con la realidad entre el VDP1 y GPU, en los juegos que eran iguales y estaban bien programados para cada maquina.

Con estos datos, he establecido el coste(unitario) que tiene para la GPU procesar cada tipo de primitiva básica:

Coste Sprite = 2 / 0,75

Coste polígono4 plano = 0,5

Coste polígono4 texturizado = 0,4

Coste polígono4 con Gouraud = 0,25

Coste polígono4 con Semi-transparencia = 0,25 / 0,17

Finalmente tenemos trucos del hardware que ayudan a hacer más rápido solo la etapa de texturizado. En el caso de la PSX es el Cache de texturas para texturas de 16×16 a 16bit de color.

Cache de Textura ON = 2

Aplicando estos valores unitarios sobre la tasa de relleno total obtenemos unos min/max.

Donde el min son los valores cuando la PS está en el peor escenario posible, que es con penalización por Escalado/Rotado y Semi-transparencia hasta 3 veces.

Y donde el max con penalización por Escalado/Rotado, uso de la Cache de Texturas en elementos con Pattern/Textura y con penalización por Semi-transparencia hasta 2 veces.

Sprite = 66 / 24,75

Polígono4 Plano No-Text = 66 / 66

Polígono4 Plano + Textura = 13,20 / 26,40

Polígono4 Plano No-Text + Transparencia = 5,61 / 8,25

Polígono4 Plano + Textura + Transparencia = 2,24 / 6,60

Polígono4 + Gouraud = 8,25 / 8,25

Polígono4 + Gouraud + Textura = 3,30 / 6,60

Polígono4 Plano No-Text + Gouraud + Transparencia = 1,40 / 2,06

Polígono4 + Gouraud + Textura + Transparencia = 0,58 / 1,65

Las conclusiones que extraigo de estos números son los siguientes datos promedio:

La diferencia entre solo el SS-VDP1 contra la PSX-GPU dibujando quads da como resultado que la PSX era un 37% más rápida que SS. No el doble como se decía en la época, y yo me creí. Y además teniendo en cuenta una penalización global por redibujado que he introducido para el VDP1, la cual es conservadora con respecto a un caso real.
Si sumamos al SS-VDP2 al cálculo. En este caso se invierten los papeles, SS es un 34% más rápida que PSX en global. El VDP2 aquí marca mucho la diferencia en el aporte 2D(fondos y UI) y “3D” para planos infinitos rotados. Siendo clave el proceso bruto del VDP2 en todos sus procesos sin ninguna penalización, si se programa todo correctamente. Y aún afecta la penalización introducida por redibujado en la parte del VDP1.
Si usamos la combinación VDP1+VDP2 para hacer transparencias a los elementos del VDP1 tenemos una mejora clara, bajando la diferencia al 20% incluso con la penalización introducida por redibujado.
- Al usar las transparencias del VDP2 para elementos del VDP1, el rendimiento total que sacamos de sumar el VDP1+VDP2 baja al 32%. Al usar el H-T del VDP1 con penalización de redibujado combinado con la transparencia del VDP2.
- Con todo el rendimiento final haciendo transparencia total en casos de no redibujado, totalmente posible, es claramente superior a PSX.
Si comparamos la equivalencia en dibujado 3D de triángulos, los números son claros. PSX entre un 87% y un 77% más rápida que SS, casi el cuádruple. Teniendo en cuenta la conservadora penalización global por redibujado que he introducido.
Si planteamos un escenario donde la SS no tiene el problema de redibujado, como por ejemplo un juego totalmente 2D aprovechando bien la SS. La SS es más rápida dibujando quads. Resultando la SS un 20% más rápida que la PSX. Sumando al VDP2, analógicamente a la hipótesis real anterior, aún crecerían más los números. Resultando un 57% más rápida la SS frente a la PSX en global, un poco más del doble de rápida.

Otros cuellos de botella: DMAs y SCSP

Estamos hablando de estabilidad en los gráficos, pero aquí la gestión de los BUSes y del bloque de sonido también juegan su papel, y esencial.

Una mala gestión del BUS-B puede ser desastrosa para el framerate. Ocasionando caídas cuando el VDP1 o la CPU no tienen ningún problema de proceso real. O incluso influyendo en la respuesta al mando o finalmente a la reproducción de sonido. Cada uno de los accesos a los diferentes destinos deben estar sincronizados y optimizados, más cuando las velocidades de reloj son diferentes o los accesos limite de tamaño de palabra también lo son.

En la documentación se detallan posibles cuellos de botella entre ellos la limitación de uso DMA sobre el SCSP y su DMA interno. Ya que ambos trabajan a velocidades distintas con respecto al sistema global. Por ello hay que tener mucho cuidado al acceder al bloque de sonido.

En este sentido se conocieron problemas con los primeros driver del SCSP, que no ayudaban a controlar estos posibles problemas.

También una mala optimización del código sobre el uso del bloque sonido como abuso de archivos grandes PCM por tendencia a usarlo como en el SPU de PSX, totalmente diferente. Pueden dar como resultado demasiado trafico en el BUS-B y el bloque de sonido.

Combinación de todos los cuellos de botella:

Hasta hace poco daba por hecho que el causante principal de la mayoría de casos que conocía era el VDP1. Pero después de algunas conversaciones con XL2 mediante privados sobre su desarrollo Homebrew Sonic Z-treme. Y después de haber re-analizado de nuevo juegos críticos como Tomb Raider. He podido elaborar más mis conclusiones.

Finalmente tenemos las causas concretas de los posibles cuellos de botella a controlar:

Ralentizaciones por VDP1 Overdraw.
Por baja optimización del código de matrices de transformación y/o iluminación 3D.
Por mala gestión del flujo CPU<>VDP1

En definitiva juegos, sobre todo durante el 1995 y 1997, con versión PSX y SS idénticos(o casi) en geometría, iluminación, sombreado, color y texturas. Podemos encontrarnos con:

Caídas a la mitad en SS, en picos de alta geometría en pantalla donde la PSX presenta alguna caída clara.
- Tomb Raider → 30/24 PSX vs 30/15 SS ← Por posible baja optimización del código de matrices de transformación y/o iluminación 3D y/o por posible incorrecta gestión del flujo CPU<>VDP1
- Hardcore 4×4 → 30/20 PSX vs 30/15 SS
- Akumajo Dracula X: Gekka no Yasokyoku (aka. Castlevania: Symphony of the Night) → 60 PSX vs 60/30 SS
O casos donde la PSX se mantiene suave con alguna caída leve, la SS puede tener caídas de un ⅓ = 5 a 10FPS.
- Wipeout 1 → 30 PSX vs 20 SS <- FPS bloqueado a 20FPS, posiblemente por no lograr 25/30 estables.
- Wipeout 2 → 30 PSX vs 20 SS <- FPS bloqueado a 20FPS, posiblemente por no lograr 25/30 estables.
- Loaded! → 30/25 PSX vs 30/20 SS
Excepciones donde la SS es ligeramente superior o superior a PSX:
- Need for Speed → 28 PSX vs 30 SS
- Soukyugurentai → 60/10 PSX vs 60 SS – https://youtu.be/R7KwgqEozds?t=264

Finalmente un ejemplo que en general, para mí, es curioso. Es el caso de Hardcore 4×4. Ya que mueve una cantidad muy alta de polígonos con iluminación y sombreado Gouraud, llegando a picos de 1500 quads, unos 3.000 triángulos equivalentes a PSX, e iguales texturas. Moviéndose a 30FPS en el juego de tope. Pero con caídas de 30FPS a 10FPS cuando salen todos los coches en pantalla. Notándose mucho la bajada y perjudicando la respuesta en el control y afectando a la jugabilidad. En la mayoría de elementos 3D del menú va a 60 FPS con caídas leves.

Hardcore 4×4 en PSX también tiene caídas tanto en el juego como en menús, pero no tan bruscas, manteniéndose más tiempo en 30FPS y bajando a 20 FPS muy puntualmente. Con todos los coches se mantiene a 25FPS mínimos salvo alguna excepción.

En Hardcore 4×4 posiblemente estemos ante el caso de combinación total de problemas: Deficiente optimización de la etapa de Trasformación e Iluminación, mala gestión del flujo CPU<>BUS-B y Redibujado del VDP1.

¿Qué pasa cuando bajan mucho (muchoooo) los FPS?

Puede que otro causante sea el tipo de sincronización vertical que sé este usando en la parte del VDP1. El V-sync nativo por hardware de SS es el Doble Buffer Bloqueado Fijo o Variable. Donde podríamos tener dos escenarios de uso en el caso de la SS, también fue implementado de forma similar en la PSX:

Doble Buffer Sin entrelazado:
En este caso, estamos limitando a la mitad la posibilidad de uso resolución (vertical).
Doble Buffer Con entrelazado:
La ventaja de este tipo de buffer, es que se puede tener más resolución (vertical). El problema es mantener el relleno de pixel óptimo.
O no tener más resolución y usar la misma pero con salida entrelazada.

En ambos casos disponemos de un Buffer completo más que cumple la función de enlazar con el VDP2, será el Frame Final, mientras en otro Buffer se está dibujando el frame siguiente, que será el Frame de dibujo. Consecutivamente se nombran como F0 y F1.

V-Sync Doble Buffer Desbloqueado vs Doble Buffer Bloqueado.

V-Sync Doble Buffer Desbloqueado*^{(al final de esta sección)}:
Tener los FPS desbloqueados permite mostrar los FPS que el sistema es capaz de generar en ese momento. La pega, es que las variaciones pueden ser grandes. Y además con el principal problema de que se incrementa la posibilidad de desincronización y causar Tearing.

V-Sync Doble Buffer Bloqueado:
Bloquear el V-sync a un valor concreto, permite ajustar mejor el barrido vertical y eliminar el Tearing. El inconveniente es que el programa debe estar muy bien optimizado para no producir paradas altas en ninguno de los lugares claves de la Pipeline. Además la posibilidad de saltar algunos frames en este caso se complica, aunque no la imposibilita.

V-sync Doble Buffer Bloqueado Fijo o Dinámico:

V-sync Doble Buffer Bloqueado Fijo:
Fijando el bloqueo a una cantidad de FPS concreta. Como inconveniente tendremos que cuando el programa no sea capaz de dibujar a tiempo la cantidad de FPS fijada, se sufrirá una relentización, en forma de slowmotion. Para ajustar los FPS exigidos fijos con los que el sistema es capaz de dibujar en ese momento. Se dibujaran los mismos FPS pero sin saltos en más tiempo. Por eso esa sensación de slowmotion.

V-sync Doble Buffer Bloqueado Dinámico:
Podemos tener fijados unos saltos de cantidad de FPS determinados, que vayan cambiando según el tiempo de dibujado o determinado por alguna otra variable.
Estos saltos suelen ser 1/k, 2/k, 3/k, 4/k… Donde k son los Hz del sistema de video: PAL=50 / NTSC=60. Dando como resultado los ms que se debe tardar en dibujar un 1 frame o campo, para mantener una cantidad total de FPS objetivo. Siendo siguiendo la analogía anterior para PAL/NTSC: 50/60, 25/30, 20/17, 12/15, 10/12…
Como ventaja podremos evitar los slow motion, pero no mantendremos los FPS iguales durante todo el tiempo. Cambiando la sensación de rapidez del juego. Pero manteniendo una suavidad más homogénea. Además si no se tiene en cuenta esto, también se puede producir un cambio de respuesta en los controles, que pueden empeorar el tiempo de respuesta y la jugabilidad en un juego donde estos sean críticos.
Pero la GRAN pega es que con bajadas pequeñas de frames, este tendera rápidamente a bajar al intervalo inmediatamente inferior. Dando la sensación de más bajada de FPS que la que realmente es. Porque la bajada siempre será a la mitad de la actual. Para evitar el Tearing y poder ajustar los FPS totales a los finales necesarios del sistema de video.
Este tipo de problemas afectan tanto a PSX a SS por igual. Bien es cierto, que cuando un juego con Vsync Fijo, tiene leves bajadas en PSX estas pueden pasar desapercibidas. El mismo juego, sin optimizar, en SS dará como resultado una bajada de FPS aún más clara.
Si el Vsync es dinámico, lo que pasara es que, donde la PSX se mantiene por encima o en los FPS de un intervalo superior, se mantendrá. Si el mismo juego, sin optimizar, en SS tendera a bajar al siguiente intervalo inferior de manera más frecuente y por consiguiente clara.

Conclusiones sobre el V-sync:

La implementación ideal sería un V-sync Doble Buffer Adaptativo(Semi-desbloqueado*):
- Idealmente con las ventajas del Vsync DB Bloqueado principalmente que den flexibilidad a la pipeline gráfica del sistema sumar la opción de un Desbloqueo para pequeños rangos de caídas de frames, para no saltar al intervalo siguiente inferior. Que es la mitad del actual. A coste de generar algo de tearing en esos momentos.
Y compensar los desajustes de FPS en la respuesta final de control. Sin que haya mayor latencia o no pase de un umbral controlado y establecido. Idealmente entre 16 y 32ms.

*Desbloqueado = Frame skipping. Es decir cuando no es capaz de rellenar los 50/60hz para ir «a la misma» velocidad, y la caída sea leve dejar de dibujar x frames y repetirlos x veces. O si la caída es más grande dejar frames a mitad de dibujado y saltar al siguiente, en este caso como resultado tendremos Tearing.

Ejemplos prácticos Reales de Rendimiento:

Antes de avanzar sobre los ejemplos que quiero exponer, quiero entrar en el VDP2.

Durante el análisis previo en este punto he hablado extensamente sobre el VDP1, ya que es la parte que dibuja el 3D en SS. Pero cuando queremos ver exactamente el rendimiento comparativo entre juegos, tenemos que tener en cuenta que fondos(2D o 3D) o la interfaz o HUD en SS se dibujan(idealmente) con el VDP2. Y este era un procesador aún más 2D de lo que ya era el VDP1.

Explicare el criterio que voy a tener para el cálculo de quads texturizados equivalentes para fondos VDP2. Podemos usar dos criterios:

Como hacia en juegos 3D, elementos 2D la PSX. O equivalentes a VDP2 como el plano 3D usado en suelos:
- Fondos 4×4 = 16 quads text = 32 triángulos text
- Suelos(pueden estar iluminados): 8×8 = 64 quads text= 128 triángulos text
  - Algunos juegos hacen suelos a 20×20, no iluminados = 400 quads = 800 triángulos text

Como hacia en juegos 2D con tiles “2D” la PSX para fondos, capas o elementos:
- Fondo juego 2D: 20×20 = 400 quads text= 800 triángulos text

Opto por la 2ª opción. Pues realmente el VDP2 dibujada tileados(células, Caracteres o Patrones) de alta densidad de 8×8 o 16×16 para hacer estos planos. Ya que el primero, no nos daría el detalle que nos da el VDP2 realmente. Y en el caso del plano 3D del VDP2, la PSX nunca conseguirá la calidad de corrección de perspectiva que el VDP2 consigue.

Ejemplo practico de PSX:

Empecemos con PSX y con la geometría real en una escena/frame de Motor Toon 2 desde un ejemplo del manual de PSX Profiler Analizer de Polyphony Digital:

Triángulos: 30 Flat + 41 FlatText + 100 GsFlat + 63 GsText = 234 triángulos

Quads: 112 F + 240 FT + 337 GsF + 5 GsT = 694 quads =1.388 triángulos

Otros: 12 Líneas + 100 Sprites = 100 quads

Polígonos Planos = 254 triángulos

Polígonos con Textura = 521 triángulos

Polígonos Plano + Gouraud = 774 triángulos

Polígonos con Textura + Gouraud = 73 triángulos

Totales dibujados y calculados: 1.834 triángulos por frame→ 917 quads por frame

Totales transformados, iluminados, dibujados y no dibujados pero calculados:

1.731×1,5* = 2.751 triángulos por frame → 1.375 quads por frame

Total a 30 FPS = 2.596 x 30 = 82.530 triángulos/seg → 41.265 quads/seg

*1,5 = Factor para añadir los polígonos calculados(transformación e iluminación) pero no dibujados.

Ejemplo practico de SS:

Sonic R va a 30FPS totalmente estables: 1300x30x1,5= 58.500 quads/segundo.

¿Que pocos no? Pero son quads, no triángulos. Cuando se habla de polígonos en PSX se habla de triángulos. Multipliquemos por 2 otra vez: 117.000 triángulos/segundo. Lo cual no está nada mal. Ya que Sonic R, tenia quads texturizados y con Gouraud más iluminación dinámica y con fuente de luz a 16bit de color.

Sonic R maneja más concretamente estos datos por frame(datos redondeados) en el proceso de dibujo en el VDP1:

Sprite distorsionado Plano (Escenario y Personajes fundido) = 50 quads

Sprite Distorsionado con Textura (Escenario y Personajes fundido) = 150 quads

Sprite Distorsionado Plano + Gouraud = 500 quads

Fuente de luz Color (Personajes) = 165 quads
Luz precalculada (Escenario) = 335 quads

Sprite Distorsionado con Textura + Gouraud = 500 quads

Fuente de luz Color (Personajes) = 165 quads
Luz precalculada (Escenario) = 335 quads

Sprite Scalado = 100 quads

Totales reales, dibujados por el VDP1:

1 jugador: 1.266 quads max @30 = 37.980 quads/seg
Pantalla Partida para 2 jugadores: 1.374 quads max @30 = 41.220 quads/seg.

Sin contabilizar, que la SS dibujaba uno plano 3D “infinito” para el suelo, fondo y UI con los planos del VDP2. Que en PSX eran polígonos. Y en equivalencia a la SS serian aún más «polígonos» en pantalla, más aún en el caso de los planos infinitos. Podríamos estar hablando de los siguientes números:

1) Estos son los números tope de cada plano del VDP2 en uso en Sonic R:

RBG0: Suelo plano 3D “infinito” = 8×8 cell / Pattern Size(1 word) / Tile(2H x 2V=64×64 cells) / Plane size(2H x 2V= 128×128 Cells) / Map con 16(4×4) planos = 512×512 cells) = 144 quads text 8×8 o 131.072 quads text 16×16
NBG0: Fondo = 8×8 cell / Pattern Size(2 word) / Tile(2H x 2V=64×64 cells) / 2×1(128×64) Plane size / Map con 4(2×2) Planos(256×128 cells) = 768 quads text 8×8 o 16.384 quads text 16×16
NBG2: UI = 8×8 cell / Pattern Size(1 word) / Tile(1H x 1V=64×64 cells) / 1×1(64×64) Plane size / Map con 4(2×2) Planos = 384 quads text 8×8 o 8.192 quads text 16×16

2) Ahora vamos a estimar realmente cuantos están en uso, en función de la cantidad de información que se ven en pantalla:

El Suelo plano 3D “infinito” podemos considerar que se está usando el plano RGB0 en su totalidad. Abarca hasta el final del horizonte y su variedad y calidad es clara.
En el fondo estamos también ante un uso excelente. Tanto en detalle y variedad como uso de efectos. También se está usando en NBG0 perfectamente.
En el caso de la UI está claro que no se está usando al máximo. Y el NBG2 solo se esta usando ⅓ de total. Dando como cifra final = 461 quads text 8×8 o 2.730 quads text 16×16

Total VDP2 quads texturizados equivalentes = 300.373 quads text 8×8 o 150.186 quads text 16×16

Totales transformados, iluminados, dibujados y no dibujados pero calculados en el VDP1:

1.374×1,5 = 2.061 quads por frame

Total VDP1 + VDP2 = 2.061 + 300.373 = 302.434 quads por frame

Total para 30FPS = 302.434 x 30 = 9.073.020 quads/seg → 18.146.040 triángulos/seg

Como vemos la cifra es enorme. Pero me gustaría dejar claro, que esta es la información real que es capaz de procesar SS en su conjunto. Como la maquina lo hace.

3) Siendo consciente, que es difícil de asimilar. Voy a transformar estos datos en equivalencias a como se haría en PSX, consiguiendo resultados aproximados. Pero nunca iguales:

Suelo plano 3D “infinito” = 8×8 pattern / 16×16 Tile / 32×32 Plane / 32 Maps = 1024 quads
Fondo = 8×8 pattern / 16×16 Tile / 32×16 Plane / 16 Maps = 128 quads
UI = 8×8 pattern / 8×8 Tile / 8×8 Plane / 8 Maps = 64 quads

Total VDP2 quads equivalentes = 1.216 quads

Total transformados, iluminados, dibujados y no dibujados pero calculados por VDP1 = 1.374×1,5 = 2.061 quads por frame.

Total VDP1 a 30 FPS = 2061 x 30 = 61.830 quads/seg = 123.660 triángulos/sg

Total VDP1 + Total VDP2 = 2.061 + 1.216 = 3.277 quads por frame

Total VDP1 + VDP2 a 30 FPS = 98.310 quads/seg → 196.620 triángulos/seg

Finalmente estamos ante cifras “más” asumibles. Y tan solo con la parte del VDP1 a 30FPS, muestran cifras iguales, por no decir superiores a PSX en un juego equivalente.

¿Millones de polígonos por segundo?

Una breve explicación final sobre el título de este apartado. El cual reza 500 / 1.000 / 1.500 / ~2.000 quads por frame. Alguien se preguntara, ¿pero la SS y PSX no movían cientos de miles de polígonos o millones? Respuestas:

Primera, es una gran mentira en ambas maquinas. Como hemos podido comprobar.

Y segunda, la cuenta REAL total se hace multiplicando los FPS por los quads en pantalla en un frame. De media los juegos de SS más cañeros estaban en los 1.200 elementos en pantalla, según Yabause. Sin contar los quads que no están dibujados pero si calculados, que serian 1,5 más. Sobre 2.000 quads en un frame. Es decir uno 60.000 quads/sg a 30FPS. Si fuesen triángulos 120.000 triángulos/sg a 30FPS. Estas eran las cifras reales máximas para aquellas maquinas en aquel momento.

Conclusión final:

En resumen, he podido comprobar, que salvo alguna excepción (Crypt Killer por ejemplo) los ports o juegos multiversión, durante el 1995 al 1997, movían cifras muy similares de polígonos y calidad de texturas en ambas maquinas. La cantidad de FPS y estabilidad es otra cuestión.

En juegos exclusivos hasta el 1998 la cosa estaba empatada en términos de polígonos en pantalla, sobre unos 1.500(2.000 total calculados) polys a 30FPS. Otra historia es ya a partir del 1999 con la PSX en solitario, los desarrolladores consiguieron elevar las cifras hasta los 2.000(2.600 total calculados) por frame. Incluso a los 2.500(3.750 total calculados), a costa de sacrificar FPS, resolución, calidad de texturas, sombreado Gouraud o iluminación dinámica. ¿La SS podría a ver llegado a estas cifras? Como he repetido antes esto es otra historia, aunque yo creo que si, de igual manera que la misma PSX: Optimizando, optimizando, optimizando…

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

SI, en parte, sobre todo por las First parties y algunas notables Second / Third parties.

He podido comprobar los FPS en muchos juegos gracias a las últimas nuevas versiones de Yaba Sanshiro. En algunos casos el juego aún no funciona, pero claramente en la consola real se ve su suavidad. Tambien he podido comprobar la cantidad de poligonos gracias a la version git de Yabause. Los juegos que tienen la cantidad de “polígonos” calculados están marcados con PolyCount. Los números y el calculo están en esta hoja de cálculo online, que iré actualizando según vea necesario

He dejado fuera juegos estables de FPS que iban a 20 FPS, porque realmente lo remarcable, para mí, era llegar a 25/30 o más FPS. Han quedado fuera grandes y/o interesantes juegos, como:

Panzer Dragoon (1995-03)→ 20 FPS: 16BPP. Sin iluminación. SD.
Daytona USA (1995-04)→ 20 FPS: 16BPP. Sin iluminación. SD. PolyCount
Touge King – The Spirits (1995-11-10) →20 FPS: 16BPP. Sin iluminación. SD. PolyCount
Wipeout (1996-02)→ 20 FPS: 16BPP. Sin iluminación. SD. PolyCount
Ghen war (1995-10-26) → 20 FPS: 16BPP. Iluminación dinámica. SD. PolyCount
Titan Wars (1995-12-20) → 20 FPS PAL: 16BPP. Sin iluminación. SD.
Panzer Dragoon Zwie (1996-03) → 20 FPS: 16BPP. Sin iluminación. SD.
Congo: The Movie – The Lost City of Zinj (1996-03-07)→ 20 FPS:16BPP. Iluminación dinámica. SD. PolyCount
Andretti Racing (1996-12-20)→ 20 FPS:16BPP. Sin iluminación. SD. PolyCount
MechWarrior 2: 31st Century Combat (1997-04-01)→ 20 FPS: 16BPP. Iluminación dinámica. SD. PolyCount
Wipeout 2097 (1997-09) → 20 FPS:16BPP. Sin iluminación. SD. PolyCount
Nascar 98 (1997-11-13)→ 20 FPS: 16BPP. Sin iluminación. SD. PolyCount
Panzer Dragoon Saga (1998-01)→ 20 FPS: 16BPP. Iluminación dinámica. SD. PolyCount
Burning Rangers (1998-02)→ 20 FPS:16BPP. Iluminación dinámica. SD. PolyCount

Ahora vamos con las lista de los remarcables(unos más que otros):

First parties:

50/60 FPS:
- Clockwork Knight: Pepperouchau’s Adventure (1994-12)→ 60 FPS: 16BPP. SD
- Clockwork Knight 2 (1995-07)→ 60 FPS: 16BPP. SD
- Virtua Fighter 2 (1995-12-01) → 60FPS: FullHD. 8BPP. Sin iluminación. PolyCount
- DecAthlete (1996-07-12)→ 60 FPS: FullHD. 8BPP. Sin iluminación.
- Virtua Fighter Kids (1996-07-26)→ 60 FPS: FullHD. 8BPP. Sin iluminación.
- Fighting Vipers (1996-08)→ 60 FPS: Iluminación dinámica. 16BPP. SemiHD.
- Fighters Megamix (1996-12)→ 60 FPS: Iluminación dinámica. 16BPP SemiHD. PolyCount
- Last Bronx (1997-08)→ 60 FPS: Sin Iluminación. 8BPP FullHD. PolyCount
- Digital Dance Mix Vol.1 Namie Amuro (1997) → 60FPS: FullHD. 8BPP. Sin iluminación.
- All-Japan Pro Wrestling featuring Virtua (1997-10)→ 60 FPS: Iluminación dinámica. 16BPP SemiHD.
25/30 FPS:
- Virtua Fighter 1 (1994-11)→ 30 FPS: Iluminación dinámica plana. 8BPP. FullHD. PolyCount
- Virtua Fighter Remix (1995-11) → 30 FPS: 8BPP. FullHD. PolyCount
- Sega Rally (1995-12-29)→ 30 FPS: Sin iluminación. 16BPP. SD. PolyCount
- Virtua Cop 1 (1995-11-24) → 30 FPS: Sin iluminación. 16BPP. SD.
- NiGHTS into Dreams (1996-07-05)→ 30 FPS: Iluminación dinámica. 16BPP SD. PolyCount
- Daytona USA CEE (1996-11)→ 30 FPS: Sin iluminación. 16BPP. SD. PolyCount

Second parties:

50/60 FPS:
- Guardian Heroes (1996-01-26) → 60 FPS: 16BPP. SD.
- Time Warner Interactive’s V.R. Virtua Racing (1995-12-18)→ 60 FPS: Con caídas a 25 FPS puntuales. Iluminación dinámica plana. 16BPP. SD. PolyCount
- Silhouette Mirage (1997-09-11) → 60 FPS: 16BPP. SD.
25/30 FPS:
- Wing Arms (1995-09)→ 30 FPS: Iluminación dinámica. 16BPP SD. PolyCount
- Ghen war (1995-10-26)→ 30/40 FPS: Pausa en modo vista. Iluminación dinámica. 16BPP. SD. PolyCount
- Manx TT (1997-03) → 30 FPS: Sin iluminación. 16BPP. SD. PolyCount
- The Lost World Jurassic Park (1997-10-07)→ 30 FPS: Iluminación dinámica. 16BPP. SD. PolyCount
- Duke nukem 3D (1997-10-29)→ 30 FPS: Con caídas a 20 FPS puntuales. PolyCount
- Sonic R (1997-11-21)→ 30 FPS: Iluminación dinámica. 16BPP. SD. PolyCount
- Sega Touring Car Championship (1997-11-24)→ 30 FPS: En Menús y Clasificación. En carrera fluctúa mucho entre 20FPS y 30FPS. Sin iluminación. 16BPP. SD.
- Quake (1997-12-03) → 30 FPS: Caídas a 15 puntales. Iluminación dinámica. 16BPP SD. PolyCount
- Shining Force III (1997-12-11) → 30FPS: En Mapa caídas puntuales a 20FPS. Batalla a 30FPS. PolyCount
- Stellar Assault SS (1998-02-26) → 30 FPS (NO YabaSanshiro): Iluminación dinámica. 16BPP. SD. PolyCount
- House of the Dead (199xx) → 30 FPS: Sin iluminación. 16BPP. SD.

Third parties:

50/60 FPS:
- Road Rash (1996-07-26) →60 FPS: Con caídas a 25 FPS y muy puntuales a 20 FPS. Parece que por el problema del VDP1 de redibujado excesivo en “quads to tris” grandes. Sin iluminación. 16BPP. SD. PolyCount
- Skeleton Warriors (1996)→ 60 FPS: Sin iluminación. 16BPP. SD.
- Street Racer Extra (1996)→ 60 FPS: Sin iluminación. 16BPP. SD. PolyCount
- Striker ’96 (1996-05)→ 60 FPS: Sin iluminación. 16BPP. SD.
- Hardcore 4×4 (1996-12) → 60 FPS: En menús 3D con caídas a 30FPS
- Tempest 2000 (1996)→ 60 FPS: Durante el juego. Efectos Render-to-texture en menús a 10FPS. Sin iluminación. 16BPP. SD.
- Dead or Alive (1997)→ 60 FPS: Sin Iluminación. 8BPP. FullHD. PolyCount
- Goiken Muyou: Anarchy in the Nippon (1997)→ 60 FPS: Sin Iluminación. 8BPP. FullHD.
- Mass Destruction (1997)→ 60 FPS: Sin iluminación. 16BPP. SD. PolyCount
- Terra Cresta 3D (1997)→ 60 FPS: Iluminación? 16BPP. SD.
- Shinrei Jusatsushi Taromaru (1997)→ 60 FPS: Iluminación? 16BPP. SD.
- Thunder Force V (1997) → 60 FPS: Caídas a 35/40FPS en puntos.16BPP. SD.
- Layer Section II (1997)→ 60 FPS: Iluminación? 16BPP. SD.
- Zero Divide: The Final Conflict (1997)→ 60 FPS: Sin iluminación. 16BPP. SD.
- League Go Go Goal! (1997)→ 60 FPS:
- Jonah Lomu Rugby (1997) → 60 FPS: Sin iluminación. 16BPP. SD.
- Radiant Silvergun (1998)→ 60 FPS: Iluminación dinámica. 16BPP. SD.
- Savaki (1998)→ 60 FPS: Iluminación dinámica. 16BPP. SD.
- Akumajo Dracula X: Gekka no Yasokyoku (aka. Castlevania: Symphony of the Night) (1998) → 60 FPS: Con caídas puntuales a 30 FPS. Posiblemente por el V-sync y falta de optimización. Iluminación? 16BPP. SD.
25/30 FPS:
- Titan Wars (1995-12-20) →25 FPS NTSC: Sin iluminación. SD.
- Need for Speed (1996-07) → 30 FPS. Sin iluminación. 16BPP. SD. PolyCount
- Loaded (1996-06)→ 30 FPS: Con caídas a 20 FPS puntuales. Iluminación dinámica. 16BPP. SD. PolyCount
- Exhumed (E) / Powerslave (U) (1996-09)→ 30 FPS: Con caídas a 20 FPS puntuales. Iluminación dinámica. 16BPP. SD. PolyCount
- Battle Arena Toshinden URA (1966-09-27) → 30 FPS: Sin Iluminación. 8BPP. SemiHD. PolyCount
- Tomb Raider (1996-10) → 30 FPS: Con caídas puntuales a 15 FPS. Iluminación dinámica. 16BPP. SD. PolyCount
- Judgement Force Proto / Fighting Force Rolling Demo (1996)→ 30 FPS. Sin iluminación, igual que PSX. 16BPP. SD. PolyCount
- Hardcore 4×4 (1996-12) → 30 FPS: Con caídas a 15FPS con todos los coches en pantalla y en puntos de los circuitos con algún coche. Iluminación dinámica. 16BPP. SD. PolyCount
- Touge King the Spirits 2 (1997-04-18) → 30 FPS: Iluminación dinámica. 16BPP. SD. PolyCount
- Resident Evil (1997-07) → 30 FPS: Iluminación dinámica. 16BPP. SD. PolyCount
- Darklight Conflict (1997-07-17) → 25 FPS PAL/ 30 FPS NTSC: Iluminación dinámica a color, igual que PSX. Iluminación dinámica. 16BPP. SD. PolyCount
- Croc: Legend of the Gobbos (1997-09-17) → 30 FPS. Igual geometría y texturas que PSX. Iluminación precalculada en escenarios, igual que PSX. Iluminación sin fuente en assets y protagonista, en PSX es con fuente. Iluminación dinámica menús. 16BPP. SD. PolyCount
- Black Dawn (1996-12-10) → 30 FPS: Caídas puntuales a 20. Sin iluminación, igual que PSX. Sin iluminación. 16BPP. SD. PolyCount
- NHL 97 (1996-12) → 30 FPS: En menús 3D y cambios de jugador en partido a 60FPS. Sin iluminación. 16BPP. SD
- Fighting Illusion K1 Grand Prix (1997-01-31)→ 30 FPS: Iluminación dinámica a color, 16BPP. SemiHD. PolyCount
- Drift King Syutokoh Battle 97 / Shutokou Battle ’97: Tsuchiya Keiichi & Bandou Masaaki (1997-02-28) → 30 FPS: Iluminación dinámica. 16BPP. SD. PolyCount
- Pandemonium! (1997-02-28) → 30 FPS(NO Yaba Sanshiro): Con caídas a 20 FPS puntuales donde hay mucha área de VDP1 Half-Transparency y en niveles concretos como el final(iluminación y/o VDP1 H-T) Iluminación dinámica. 16BPP. SD. PolyCount
- Hexen (1997-03)→ 30 FPS: Con caídas a 20 FPS puntuales.
- FIFA 97 (1997-04) → 30 FPS: Sin iluminación. 16BPP. SD. PolyCount
- D-Xhird (1997-05) → 30 FPS: Iluminación dinámica. 16BPP. SD. PolyCount
- Bulk Slash (1997-07-11) → 30 FPS. Iluminación en Briefing. Sin iluminación en Juego. 16BPP. SD. PolyCount
- FIFA 98 (1997-12) → 30 FPS: Sin iluminación. 16BPP. SD.
- Virtual Kyōtei 2 (1997-12-04) → 30 FPS: Con fuertes caídas, 15FPS cuando la cámara muestra la mayor parte del circuito hacia el fondo y rotando. Iluminación dinámica. 16BPP. SD.
- World League Soccer 98 (1998-06-05) → 30 FPS: Totalmente estables durante el partido.Sin iluminación. 8BPP. FullHD.
- Code R (1998-07-09)→30 FPS: Totalmente estable en partes jugables. Solo en Repeticiones tipo Manga/comic a 15FPS. Iluminación dinámica. 16BPP. SD. PolyCount

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

Judgement Force Proto / Fighting Force Rolling Demo
Judgement Force que es como sé llamo previamente Figthting Force, que fue un prototipo fechado en 1996-11-26. Aprovecha la SS muy bien. Ambas CPUs SH2 y se ve uso del SCU, llegando a un 26% de uso del mismo. Hace un uso de la RAM principal y VRAMs bueno, llegando al 77% del total. Del DSP de sonido hace un uso del 20% usando CD-DA para la música. Como detalle destacar que como en el resto de juegos de Core Design, este no usa el registro HSS para acelerar el dibujado del VDP1. Puede ser que ellos tuviesen ya optimizado su pipeline de dibujo para SS y no quisiesen usar HSS para no perder calidad de dibujo, y fuesen sobrados de tiempo de dibujo con su código. Lo que parece ser es que este fue un desarrollo que se comenzó para SS, como propuesta de Core a Sega para un el Street of Rage 4. Parece que no pudo ser, y se convirtió en un juego multiplataforma tal y como lo conocimos, quedándose por el camino la versión final de SS. Todas ellas con igual resolución de pantalla/texturas y profundidad de color para pantalla/texturas. Con una cantidad de geometría y contenido igual, con ligeras diferencias según maquina. Corriendo en el caso de SS a 30FPS constantes. Y dejando un detalle que delata que SS fue la consola en mente para este juego. El suelo en este juego es plano y se extiende hacia el infinito. En el caso de la SS con el VDP2 era fácil hacer esto, con una calidad muy alta. En el resto de maquinas de la época ya era otra historia. En el caso de PSX, PC y N64, se puede observar como hay un truco que intenta imitar al VDP2 de la SS en el horizonte. En PC y N64 podemos encontrar como contra partida iluminación por Gouraud a color y en PC además mejores texturas. Está claro que Core Design ya a finales del 1996 tenia por la mano a la SS. En el proto del 1996 se puede observar el uso de transparencias VDP1>VDP2 para sombras, iluminación o estelas de poder. Las cuales se perdieron en la versión del 1997-03-14 Rolling demo ya llamado como Fighting Force, donde solo se ve el uso de “mesh” para todos estos casos. El juego fue lanzado finalmente en 1997-11-15, un año después del prototipo. Podemos observar que hubo tiempo de sobra para acabar la versión de SS e incluso mejorarla, ya que al ser un juego perteneciente a la 3ª ola de desarrollos para SS, esta fue ya un época donde la calidad esta igualada a PSX en la mayoría de aspectos. Pero esto ya es otra historia.
Darklight Conflict
Publicado el 1997-07-17, ya a finales de la 3ª ola de juegos para la SS, Rage se quita la espina clavada de Doom, ambos en el mismo año. Bien es cierto que contaron con el paraguas de EA, que cuando ponía un equipo con tiempo y recursos a trabajar en SS conseguía resultados espectaculares. En este juego Rage y EA usan la SS de forma magistral. El motor 3D esta a la altura de PSX sin ninguna duda: Geometría e iluminación dinámica a color. Incluso buscan la forma de usar las transparencias de SS con mucho acierto, en este caso de tipo VDP1>VDP2. Todo ello a 30FPS como una roca.
Quizás este equipo de Rage, los mismos de Doom, en un siguiente titulo de esta envergadura, podrían haber llegado aún más lejos en el tema de las transparencias. Con respecto al uso de las CPUs y coprocesadores, se usan magistralmente todos. Ambos SH2 y el SCU-DSP con la DMA del mismo, llegando a un nivel de 54,25%. Con respecto al uso de la memoria principal disponible usaron 62%. Queda bastante espacio libre en las VRAMs, puede que al usar el contenido de PSX, esta al usar un modo de resolución más alto no le cabían más texturas. Además la SS tiene 0,5MB de memoria por su VDP2, lo cual siempre es un plus que no siempre se usaba igual entre maquinas. Con todo un gran uso, llegando a un 85% del VDP1.
En la versión de SS el motor 3D esta a una resolución más baja que PSX en la Horizontal: 352 vs 512, pero igual en vertical: 256. Es la única diferencia importante con PSX, además de la usuales, de más transparencias y algo más de uso de la pantalla completa en los FMV.
A nivel de sonido no uso de DSP para efectos como reverberación, y para la música se usa CD-DA. En este aspecto se podía haber usado mucho más la SS, con música orquestada dinámica y uso del reverb para el espacio.
Las FMV corriendo a cargo del codec de EA y de sus librerías de descompresión, las cuales usan la SS al límite, acercando el MPEG a la consola, tanto en calidad de compresión y color, como de audio. Usando para ello los dos SH2 junto al SCU-DSP al límite sobre un 64%. Haciendo un uso del SCU-DSP de forma semejante y rendimiento que el MDEC de la PSX.

Croc: Legend of the Gobbos
Publicado el 1997-09-17, también a finales de la 3ª ola de juegos para SS. Argonaut programa un motor 3D pensado para competir con el mismísimo Mario 64. Motor 3D que construye para PC, PSX y SS. El cual mantiene sus principales características iguales entre plataformas. Tanto el contenido de juego, niveles, items, musicas, cinemáticas de juego, es igual en todas las versiones. Incluido el contenido 3D: la cantidad de geometría y calidad de texturas, incluso sombreado Gouraud principal. Las únicas diferencias notables entre PSX con SS, es iluminación con fuente en el personaje principal y algunos assets durante el juego, con menos transparencias y con algo menos de resolución horizontal. En PSX se llega a los 512 mientras que SS se queda en los 352. También son levemente diferentes los diseños de menús, pero con igual contenido, y las pantallas de carga diferentes. Los assets 3D de los menús en este caso con iluminación de fuente con Gouraud. Por último destacar el uso muy inteligente del VDP2 para la UI, fondos y elementos planos de los suelos. Esto último usando el plano rotado infinito del VDP2.
Con respecto al sonido, destacar del uso de Dolby Surround en SS, algo muy poco común, y que sin embargo en PSX estaba más usado. Demostrando que SS también podía con el Dolby perfectamente. Además de uso de sonido ADPCM, para sonido y voces. También menos usual en SS, pero también posible. Podemos destacar el uso del DSP de sonido de SS en 50% de su memoria. Aunque se hecha en falta el uso del DSP para el echo o reverb en la zona de la cuevas como en PSX, posible también en SS, pero que no se uso.
Aprovecha la maquina de forma notable, usando los dos SH2 y el SCU-DSP para los gráficos, este último a un 50%. Para obtener una tasa de 30FPS constantes, igualando en este tipo de juegos 3D en suavidad y estabilidad con PSX. Por otra parte hace un uso medio del 77% de los recursos totales de memoria del SS. Una gran cifra.
Podemos notar que Croc, como otro muchos títulos del momento, fue desarrollado para PC/PSX de forma simultanea dada su cercanía técnica para el desarrollo. Y que SS se difiere lo suficiente como para concluir que fue un desarrollo a parte. Detalles como: FMV de logos de inicio, diseño de menús idénticos y algunos cambios de texturas en los mismos lugares.
Aunque en este juego finalmente y a pesar de esta diferencias el resultado es satisfactorio, no perfecto, pero muy notable. Que pena que Argonaut no hubiese rematado su presencia en SS con el Croc 2 y hubiese mejorado estos detalles que le faltaron en este 1º.

3.1 Lo complicado I – Bola EXTRA I: Uso del SCU-DSP

Como veníamos diciendo pocos desarrolladores usaron el SCU-DSP de la SS. No el SCU de forma genérica, ya que en las librerías de Sega este se usaba evidentemente. Hablamos de usar el DSP del SCU de manera especifica para calcular y acelerar los juegos en áreas criticas como: FMV, proceso/render de imagen, descompresión de Audio y procesos 3D como trasformaciones geométricas o iluminación dinámica. Quien sabe, también para físicas o cálculo de colisiones.

Teóricamente incluso para varias tareas a la vez. El SCU-DSP era un procesador especializado en procesar pequeñas cantidades de datos pero ejecutando hasta 6 instrucciones en un solo ciclo. El problema, era que para ello hay que diseñar con extremo cuidado los procesos, las tareas, los tipos de datos, los pozos de memoria a usar y los DMA a usar. Pues el proceso de SCU-DSP va intercalado y en paralelo al conjunto del resto de procesos de la SS: los dos SH2, los accesos a los pozos de memoria, los procesadores gráficos VDP1 y 2, el sistema de sonido con la CPU M68000…

Este trabajaba en exclusiva con el SH2 Maestro y con la Memoria RAM Rápida mediante un canal de DMA exclusivo. En muchos sentidos el SCU-DSP y el GTE son extremadamente parecidos. En esencia eran procesadores DSP especializados con posibilidad de hacer procesos en paralelo con instrucciones básicas y rápidas. Podríamos decir que se podría haber implementado de igual forma a nivel de SDK que el GTE. Es decir crear unos macros pre-programados, compilados en ensamblador, ultra-optimizados y accesibles con código C para facilitar aún más su programación. Para tareas concretas de matemática vectorial o gráficos 3D: matrices transformación, matrices iluminación, calculo escalar, Dot product, Normal Clipping y Depth Queuing.

Pero Sega no fue en este sentido, sino que dejo el posible uso de esta parte muy debilitada cara a los desarrolladores más modestos, la inmensa mayoría. Estoy convencido de que el SCU-DSP puede igualar la eficiencia en los cálculos y el uso al GTE, si no en el 100% de registros que existían en el GTE, en una gran mayoría. De hecho, es muy posible que algunos ports intentaran hacer algo parecido, en algunos casos incluso sobre el mismo SCU-DSP, pero que llegaran al mismo nivel de optimización que los macros de Sony para su GTE, más en aquella época, casi imposible o muy improbable.

Dicho todo esto, podríamos aplicarlo al segundo Co-procesador integrado en la CPU de la PSX, el MDEC. La SCU-DSP puede hacer esa tarea de igual forma y eficiencia. De hecho es más que posible que algunos desarrolladores lo usaran en este sentido, como veremos en el punto de FMV.

Bueno como podemos observar un conjunto de variables a controlar muy importante. Pero a pesar de ello, hubo ejemplos muy buenos de uso del mismo, y muy satisfactorios.

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

NO. Aunque existen casos especiales donde se llegó a usar el DSP de la SCU para ayudar en el cálculo 3D, de manera similar al GTE de la PSX. Aquí tenemos que tener en cuenta que de 258 juegos analizados, 44 hacen un uso claro del SCU para proceso 3D o descompresión de FMV. Que es un 17,5% de total analizado, que podríamos extrapolarlo al total de catálogo.

Además señalar que usando la SCU para 3D no todos la usan de manera óptima, ya que no se aprecia en todos un rendimiento óptimo, o un % de uso de la memoria o los registros, alto.

Por último aún hay muchos casos donde no hay certeza de para que sé esta usando el SCU. Que en este caso es un porcentaje similar: 12% del total analizado. Podría estar siendo usado para transferencia DMA entre buses o quizás en algunos casos para descomprimir sonido ADPCM.

De este 12% solo 6 juegos (un 2,33% aprox.) están usando el DMA del SCU-DSP con máxima certeza, porque es necesario activar el DMA Timing en Yabause para que se vean bien. Esto no significa que no se este usando en otros casos. Determinando claramente en estos casos su uso, al menos, para las transformaciones 3D.

También habría que diferenciar los casos donde el SCU-DSP está trabajando solo con el SH2 maestro. Situación que se pudo dar, según informaciones de la época, porque era más sencillo teóricamente, usar solo un SH2 más el DSP del SCU. También porque al inicio no se sabia muy bien como usar el SH2 esclavo. Aunque se puede ver como, desde el inicio se usaban los dos SH2 más el SCU-DSP en el mismísimo Virtua Fighter 1. Y más adelante en más títulos, como hemos dicho antes. Aunque bien es cierto que existen varios títulos donde se da esta combinación de 1xSH2+SCU-DSP. En mi investigación solo me he encontrado con 4 juegos del total analizado, significando un % reducido del total: 1,5%.

Dicho esto, pasemos a analizar juegos por desarrollador donde se usa el SCU-DSP con claridad:

First parties:

Virtua Fighter 1 (1994) → 2xSH2+SCU-DSP Transformaciones e iluminación de vértices
Virtua Figther Remix (1995) → 2xSH2+SCU-DSP Transformaciones de vértices
Burning Rangers (1998) → 2xSH2+SCU-DSP Posible descompresión ADX e iluminación
SEGA GAME SAMPLE 1 For SBL 1.1 → Transformaciones e iluminación de vértices 1x SH2 + SCU-DSP DMA On ← menos el Ejemplo de “Alfombra”

Second parties:

Quake (1997) → 2xSH2+SCU-DSP Posible dibujo Cielo por capas y/o iluminación y/o transformaciones de vértices
Shining Force III (1997) → 2xSH2+SCU-DSP Render de Texturas con degradados y/o procedurales
Sonic R (1997-11-21) → 2xSH2+SCU-DSP Transformaciones geométricas.

Third parties:

Wipeout 1 (1996) → 2xSH2+SCU-DSP Transformaciones de vértices DMA On
Lemmings 3D (1996) → 1x SH2 + SCU-DSP DMA On
Destruction Derby (1996) →2xSH2+SCU-DSP Transformaciones de vértices DMA On
Tokusou Kidoutai J SWAT (1996) → 1xSH2 + SCU-DSP
Pandemonium! (1997-02-28) → 2xSH2+SCU-DSP Transformaciones e iluminación de vértices
MechWarrior 2: 31st Century Combat (1997) → Transformaciones e iluminación de vértices 1xSH2 + SCU-DSP
Touge King the Spirits 2 (1997-04-18) → 2xSH2+SCU-DSP Posible Transformaciones geométricas.
FIFA 97 (1997) →2xSH2+SCU-DSP Transformaciones de vértices DMA On
Darklight Conflict (1997) →2xSH2+SCU-DSP Transformaciones e iluminación de vértices DMA On
Assault Rigs (1997) → Transformaciones e iluminación de vértices, 1xSH2 + SCU-DSP DMA On
Dead or Alive (1997-10-09) → 2xSH2+SCU-DSP Transformaciones de vértices, posible DMA On.
Croc: Legend of the Gobbos (1997) → 2xSH2+SCU-DSP Transformaciones e iluminación de vértices DMA On y posible descompresión ADPCM
Virtual Kyōtei 2 (1997-12-04) → 2xSH2+SCU-DSP. Transformaciones e iluminación de vértices.
Code R (1998)→2xSH2+SCU-DSP, Posible descompresión ADX.

Como vengo haciendo, selecciono 3 juegos que destaquen en este punto para su análisis más extenso:

Virtua Fighter 1
Siendo el primer juego lanzado para SS, allá en el 1994-11-22. Si casi 24 años. Me ha sorprendido que se están usando los dos SH2 más el SCU-DSP, este último con bastante uso un 95% memoria y 48% de registros. Es cierto que extrañamente, no se utiliza para el suelo el RBG0, si no quads, con un cono de recorte más que evidente. Cabe destacar que la conversión con respecto al Arcade adolece de una reducción de la geometría en los luchadores, en detalles como los dedos de las manos. Pasando de 2300 polígonos a 550 en los personajes. El resto del juego esta intacto, iluminación(1 Luz Paralela Dinámica con fuente), contenido y colores incluidos. Según los datos oficiales el juego mueve 39.000 quads/sg. Como decimos 1100 aprox. para los personajes y 220 para el escenario. Todo se mueve a 30FPS como en el arcade, o según algunos incluso mejor, porque el arcade puede bajar a 15FPS en algunos momentos. A una resolución de 640×224 NTCS en PAL 704×256 comparados con la del Arcade que era 496×384, no está nada mal. Finalmente detallar el uso total de la memoria disponible del sistema que llega a un 60%, siendo el uso del VDP1 un 30% realmente bajo, subiendo al 60% en la versión Remix que salio unos meses después. El uso del DSP de sonido sube a un 60% de la memoria. Posiblemente estemos ante uno de los primeros proyectos que se usaron para crear la librería SGL, muy usada en los siguientes títulos de AM. Por último añadir que la versión Remix que salio unos meses después, es prácticamente el mismo programa. Pero en vez de quads planos se usan quads con texturas. Se reducen los polígonos por personajes, sin apenas apreciarse. Se usa el VDP2 para el suelo, ganando en detalle y sin recortes. Perdiendo la iluminación dinámica del primero.
MechWarrior 2: 31st Century Combat
Lanzado en el 1997-04-01 principios de la 3ª ola de desarrollos. Mechwarrior procedente de PC, es una conversión digna. Quizás sea uno de los pocos juegos que usa los dos RGBx del VDP2 para: dibujar el suelo y el cielo. También tiene otra particularidad, puede que sea de los pocos juegos que usa la transparencia de VDP2 con elementos del VDP1 texturizados con Gouraud. Tiene sombreado Gouraud con iluminación con fuente y estática. Usa los dos SH2 para 3D y FMV, además el SCU-DSP para el 3D, llegando a un uso de 50% en Memoria y 43,5% en registros. También usa el DSP del sonido con un uso del 30% de la memoria. Del resto de la memoria total del sistema 71%, llegando a un 90% del VDP1. El juego se muestra a 320×240 a 20FPS constantes, y usa LOD para elementos del escenario y assets. Con respecto a la versión de PSX, SS llego después con una diferencia de menos de un mes. Y en términos generales, excepto el tema de transparencias, y algún detalle más, los juegos son iguales. Como curiosidad final, destacar que tiene un formato de vídeo propietario, que da una calidad muy interesante dentro de lo visto en SS.
FIFA 97
Lanzado en el 1997-12-17 finales de la 3ª ola de desarrollos para SS, con 4 meses de retraso con respecto a la versión PSX. Con una falta de uso, cuestionable, de las transparencias, tanto en menús como en la parte 3D. Con todo estamos ante un port notable, el nivel de geometría, texturas y animaciones es idéntico al de las versiones PC/PSX. Los comentarios, musicas están intactas, como el resto del contenido del juego. El juego se presenta a 320×240 16bit y va a 30FPS estables, mostrando más de 1000 quads en pantalla. Igual que en PSX, salvando la diferencia de que en esta la resolución es ligeramente superior 512×240. Hace uso del RGB0 del VDP2 para el campo dándole una calidad que PSX no puede, faltando solo el degradado de horizonte totalmente posible y sencillo en el VDP2. Hace uso de LOD en los jugadores y sombras, en las sombras en SS el LOD es más alto, mostrando solo 2 sombras completas contra las 5/6 PSX. Al menos estas sombras son transparentes(VDP1>VDP2) con respecto al campo. Hace un uso de la capacidad de proceso de la SS notable. Mostrando uso para 3D y FMV de los dos SH2 más el SCU-DSP, este último con un uso de la memoria de un 90% y de Registros del 43,47%. Además encontramos un uso del DSP de sonido de hasta un 35% de memoria. En la versión de SS no hay Dolby como en la de PSX, totalmente posible por otra parte. Sin embargo encontramos fuertes indicios de uso de ADPCM para música, publico, comentarios… Algo poco común en el sistema y de agradecer. Se aprovecha el 64% del total de memoria del sistema, no llega al 50% de la RAM principal. Por último destacar la inmensa calidad de los FMV de este juego. Como viene siendo habitual, me estoy encontrando con que EA tenia unos codecs de video para SS excelentes, en este juego posiblemente estemos entre uno de los mejores, en términos de calidad(DCT), color(32bit), resolución(304×192) y sonido(PCM Mu-Law / Estereo/ 8bits / 22Khz). Solo hecho en falta que no use el zoom de VDP2 para extender el vídeo al máximo, extraño.

3.2 Lo complicado I – Bola EXTRA II: Resolución pantalla SD/HD

Al ir avanzando en este viaje de investigación y profundización en las tripas de SS, me he encontrado con temas que ni tan siquiera me había planteado en un inicio de esta entrada. Como la resolución de renderizado 3D en los juegos. He ido encontrando entradas en foros y opiniones al respecto comparando con PSX ports o juegos parecidos donde comparar la potencia de ambas consolas.

Después de ver como muchos, la mayoría de ports o versiones usan la misma resolución. Un poco más en una u otra según port, hablamos de 320×240 en PSX y 351×240 en SS en algunos juegos. O 320×256 en PSX y 320×224 en SS. En Tomb Raider 364×240 en PSX y en SS 352×256. Poca cosa. O a saltos más grandes como en juegos muy similares como: Croc, Darklight Conflict y Die Hard Trilogy (Nivel aeropuerto) a 512×240 en PSX y en SS 352×240.

O comparando dos juegos similares como Burning Rangers con Soul Reaver. Muy parecidos en muchos aspectos en el motor pero el de PSX a 512×256 y el de SS a 351×224. Son bastantes puntos menos tanto en X como en Y. Ambos renderizando a 16bit de color con una tasa de FPS similar 25FPS en el caso de PSX y 20FPS en el caso de SS. Bien es cierto que no son comparables en el sentido que el juego de PSX es de 4ª generación y el de SS de 3ª generación. 1999 contra el 1998. Un año da para mucho.

Podemos observar que en la mayoría de juegos, las texturas son similares o iguales. Salvando la manera diferente de texturizar de cada maquina. Pero porqué no llega SS a estas resoluciones en juegos similares. La respuesta la encontramos en las diferencias de distribución de la memoria en ambas maquinas y las restricciones resultantes al incrementar la resolución. Tambien en el soporte, de alguna forma, de algunas resoluciones. En SS no se puede tener ni en 16BBP o 8BPP valores de X: 256, 364, 384, 512. Teniendo espacio de Frame buffer. En Y si hay la misma disposicion de valores, con diferentes restricciones.

Al subir la resolución no solo hay que procesar más datos, sino que hay que almacenarlos. Y aquí es donde la SS tenia otra pega. Cuando subes de 351 en X y/o de 256 en Y ya pasas al modo Hi-Res del VDP1. Obligatoriamente se pasa de 16bit a 8bit de capacidad de renderizado y como resultado ya no puedes usar cálculos de color como Gouraud o Semi-transparencias. Pero incrementas la capacidad de almacenar texturas con respecto al modo 16bits. Pues tienes el mismo espacio para guardar las texturas pero a 8BPP obligado, lo que hace poder meter más texturas aun.

Sin embargo lo que si puede hacer la SS es jugar con la resolución Y como la PSX. Haciendo entrelazado: 256 en Y máximo x2, nos da 512 en Y total. Muchos juegos aprovechan el Full VDP1 Hi-Res más el Hi-res VDP2 doble-entrelazado.

Aunque en este sentido como en otros, la PSX era más flexible. Puede subir de resolución y aguantar los 16bit de color, pero ira perdiendo capacidad de almacenar texturas de manera exponencial. Por eso los juegos que usan estos modos, tienen menos texturas y usan más Gouraud para suplir esta falta.

Cosa que no pasa con SS, que subiendo la resolución nunca perderá capacidad de almacenar texturas, solo de su profundidad de color.

Aunque en global, podemos decir, que SS perdía más que ganaba, pues perder su capacidad de sombreado en general o las funciones de calculo de color el Raster VDP1, es mucho a mi manera de ver. El VDP2 tambien podia perder opciones en modo Hi-Res, pero solo en el especial, que es un modo para monitores especial.

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

SI, en parte. Hay juegos en alta resolución en SS. Incluso algo más que la máxima de PSX. Y muy suaves. Pero sin Gouraud o Transparencias, como norma casi general. Hay un caso que si hace transparencia en Hi-Res del VDP2, aunque solo en las sombras, es Last Bronx: El cual renderiza a 351×511 8bits color en el 3D del VDP1 y con salida del VDP2 a 704 x 256 con Doble Entrelazado, que como resultado es: 704×512, para los gráficos dibujados por el VDP2. Como podemos ver no está nada mal. Tenemos 351 en X de los 704 totales que si dibuja el VDP2 y 512 puntos reales en Y, tanto en el VDP1 como en el VDP2. Y todo a 60FPS fluidos.

Queda la duda pendiente de como hubiese sido tener iluminación dinámica en alguno de estos juegos en “Hi-Res” a 8BPP: Virtua Fighter Remix, Virtua Fighter 2, Virtua Fighter KIDS, Last Bronx, DOA o Battle Arena Toshinden URA. Como si tubo el mismísimo Virtua Fighter 1. Y de como hubiesen quedado con ese extra de iluminación. Resultando seguro más espectaculares, como lo fue en PSX el Tekken 2 o Bloody Roar 2 que hacia algo similar.

Las causas pueden obedecer a que el calculo de iluminación extra, harían más complicado el objetivo de 60FPS. Y no disponer de Gouraud complicaba un poco más cambiar la luminosidad de los polígonos. La suma de ambos, quizás se materializo en sacarlos de ecuación y centrarse en los máximos FPS y resolución.

Hay muchos más juegos que usan el modo Hi-Res de SS, la mayoría solo del VDP2 y/o en los menús. Algunos juegos durante todo el juego o de forma mixta. Hay va una lista cronológica:

Todo el juego VDP1 Hi-Res >> VDP2 Normal:

Virtua Fighter 1 (1995) → 704×256 No-Entrelazado
Virtua Fighter 1 Remix (1995)→ 703×255 >> 704×256 No-Entrelazado
NBA Live 98 (1997) → 639×239 >> 640×240 No-Entrelazado
Battle Arena Toshinden URA (1996)→ Juego Lucha, menús en SD. 703×255 >> 704×256 Doble entrelazado
World League Soccer 98 (1998) → 640×255 >> 640×256 No-Entrelazado

Todo el juego VDP1 Hi-Res 2x «Y» Resolución >> VDP2 Hi-Res:

Virtua Fighter 2 (1995) → 703×511 >> 704×256 Doble entrelazado
Decathlete / Athlete King (1996) → 703×479 >> 704×240 Doble entrelazado
Virtua Fighter Kids (1996) → 703×511 >> 704×256 Doble entrelazado
Vatlva Taikenban (1996) → No System Clipping >> 640×224 Doble entrelazado
Dead or Alive (1997) → 703×479 >> 704×240 Doble entrelazado
Digital Dance Mix Vol.1 Namie Amuro (1997)→ 703×479 >> 704×240 Doble entrelazado
Winter Heat (1998) → 703×479 >> 704×240 Doble entrelazado

Mixto VDP1 Normal o Hi-Res >> VDP2 Hi-Res:

Fighting Vipers (1996) → 351×255 >> 704×256 UI HD
Fighters Megamix (1996) → 351×255 >> 704×256 UI HD
Fighting Illusion K1 Grand Prix (1997) → 351×223 >> 704×224 UI HD
D-Xhird (1997) → 351×223 >> 704×224 UI HD
All Japan Pro Wrestling Featuring Virtua (1997) → 351×223 >> 704×224 Doble entrelazado UI HD
Elan Doree (1998) → 703×223 >> 704 x 224 Fondos UI Doble entrelazado

Mixto VDP1 Normal 2x «Y» Resolución >> VDP2 Normal o Hi-Res:

Last Bronx (1997) → 352×507 >> 704×256 Doble entrelazado, No Hi-Res VDP1, Si Hi-Res VDP2.
Zero Divide: The Final Conflict (1997) → En menús. 352×479 >> 352×240 Doble entrelazado, No Hi-Res VDP1, No Hi-Res VDP2.

Solo(algun elemento en VDP1) VDP2 Hi-Res en menús o partes del juego:

Daytona USA CEE (1996) → VDP2 pantalla inicial
Cyber Troopers Virtual-On (1996) → VDP2 pantalla inicial y menús
Black Dawn (1996) → VDP2 menús
Doom (1997) → VDP2 Logos y pantalla inicial
Touge King the Spirits 2 (1997) → VDP2 Pantalla inicial
Formula Karts (1997) → VDP2 menús
Sega Touring Car (1997) → VDP2 Pantalla inicial y menús
FIFA 98 (1997) → VDP2 menús
Panzer Dragoon Saga (1998) → VDP2 pantalla inicial
Burning Rangers (1998) → VDP2 menús
Akumajo Dracula X: Gekka no Yasokyoku (aka. Castlevania: Symphony of the Night) (1998) → 640×240 Doble Entrelazado VDP2 menú pausa
World League Soccer 98 (1998) → 640×511 >> 640×256 Doble entrelazado en menus
Code R (1998) → Menús

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

Virtua Fighter 2
Lanzado en el 1995-12-01, principio de la primera ola. Este juego puso por fin a la SS en su lugar. Se nota que el equipo AM2 asignado para SS buscaba igualar en lo posible el acabado de sus versiones en Arcade. Queda patente como en este título, se sigue apostando por la máxima resolución posible por SS(703×511), a coste de perder profundidad de color de 16bit y quedarse en 8 bit. Y con ello, perder poder usar el sombreador del VDP1 como el Gouraud, útil para recrear la iluminación plana o suave. Quizás también el equipo de AM2, prescinde del sombreado porque tampoco quieren implementar la iluminación por fuente, que ya tenían en el VF1, sombra humana animada incluida, pasando a estas a ser una proyección ortogonal, eso sí con forma humana animada. Quizás esto responda al deseo de llegar a los 60FPS. Ya que los cálculos de iluminación, para caras planas o suaves, esta última incluso más compleja, son muy caros y difíciles de implementar en SS en este momento de desarrollo de librerías. Perdiendo el punto de espectacularidad que da, y viendo que en Arcade era iluminación plana, da la impresión de que una versión remix de este con este detalle hubiese sido el broche perfecto. En este caso siguen la línea marcada en VF1 Remix, e incluso dan un paso más. Reducen la cantidad de polígonos en los personajes algo más. Eso sí como contra partida, hacen un uso más intenso del VDP2 y sus fondos. Supliendo la carencia de fondos 3D con varias capas 2D, con traslación y zoom según el caso. Insalvable en el caso del nivel de la barca en el rio. Por supuesto usando para el tatami el plano rotado del VDP2, dando, aquí sí, una definición al nivel del Arcade. Como es obvio, el resto del contenido del Arcade permanece intacto. Luchadores, diseños, animaciones, músicas, sonidos… Algún modo extra y un par de FMV se añaden en esta versión para SS. En el uso de los procesadores, ya podemos ver como AM se centra en el dúo SH2(tanto para el 3D como para las FMV) y aparta al SCU-DSP, lo cual podemos ver reflejado en su SGL. Aunque como en otros tantos títulos vemos algún tipo de uso del SCU-DSP que hasta ahora para mi es desconocido. Podemos ver un uso del DSP de sonido con un uso del 80% de memoria. Con respecto al uso total de la memoria disponible llega a un 85%, a un 90% de la RAM principal y al 85% del VDP2. Y aun 75% del VDP1. La calidad de los FMV son aceptables, haciendo uso de DUCK(Video y audio) en modo 15bit con dithering a una buena resolución(320×168) a 20FPS.
Last Bronx
Lanzado en el 1997-08-01 a finales de la 3ª ola de desarrollos japoneses ya vemos que el nivel de conocimiento sobre la maquina es alto. Creado por AM3, creando un motor nuevo para él, y presumiblemente sin usar nada de AM2. En fin, estamos ante una conversión de Model 2B CRX espectacular. Manteniéndose en la barrera de los 600 quads a 60FPS como en el resto de títulos de AM2(Excepto VF1 y Remix a 30FPS) pero no a HiRes en VDP1 y 2. Solo en el 2. Pero con doble entrelazado y renderizando el total en Y en el VDP1. Pero manteniendo el uso de solo paleta y buffer a 8bits, aun teniendo la posibilidad de usar 16bit. Quizas la razón sea garantizar la velocidad al máximo, para el objetivo de 60FPS. De esta forma en el borrado del buffer el VDP1 puede ir el doble de rápido. Con una resolución real total para los elementos 3D de 351×507. Con una resolución final de salida del VDP2 de 704×256 con doble-entrelazado, resultando en 704×512 en los gráficos del VDP2. Se hizo una traslación perfecta y con calidad de la geometría, texturas, colores y animaciones, estas últimas perfectas. El uso, como es habitual desde VF2, del plano rotado RBG0 para el suelo, con un detalle equivalente al de la recreativa. Y un uso del resto de planos para fondo brutal. Doble plano rotado(Suelo y techo) en algunos escenarios, y elementos seleccionados que hace el VDP1 o planos del VDP2 para dar mayor detalle y profundidad. No tenemos tampoco iluminación sobre la geometría ni tampoco son sombras humanas animadas proyectadas, son una sombra circular simple pero si es transparente al menos con respecto al fondo. Algo muy excepcional por la configuración de resolución que tiene el juego. En teoría no se podía hacer. Sigo. El uso de los procesadores es muy bueno, usando el tándem de SH2 muy bien tanto para 3D y FMV, y con señales de uso del SCU-DPS más elevadas de lo habitual en juegos que no es claro que se esté usando para 3D. En este caso hasta un 35% Memoria y un 20% de registros. Se aprecia el uso de música MIDI además de CD-DA, con un uso del DSP de sonido del 35% de memoria. La intro FMV está en formato DUCK(Video/audio) con una calidad aceptable de resolución(288×200) a 15bit con dithering y audio(44100 mono), pero a 30FPS. Por ultimo podemos observar un uso total de la memoria de la SS del 80%, llegando a un 90% del VDP1. Un 80% del VDP2 y un 75% de la RAM principal. Comparado en su momento con Soul Blade, creo que Last Bronx no llega a rivalizar con este. Es cierto que un muchos aspectos se tocan de la mano, pero el hito grafico que supuso Soul Blade en 32bits es remarcable, incluso dentro de la misma PS1, ningún otro juego llega donde este, quizás un par más, pero no pueden replicar la magia y la maestría que Namco arrastraba sobre la máquina y sobre todos los títulos a sus espaldas. Las Bronx es un gran primer título de lucha para AM3, y un primer port magnifico para SS. Quizás con más juegos de este tipo a espaldas y más tiempo con SS, hubiesen brindado un Soul Blade a SS por parte de AM3. Pero no lo fue.
Dead or Alive
Lanzado en el 1997-10-09 finales de la 3ª ola de desarrollos Japoneses. En este título podemos ver un auténtico hito en el manejo y aprovechamiento de la SS. Un juego que procede de la Model 2A-CRX / 2B-CRX. De una superioridad manifiesta. Tecmo ejecuta un port sublime. Donde los modelos, texturas, colores y animaciones son calcados al original, exceptuando la iluminación y sombras humanas animadas. Y claro esta los fondos en 3D. Estos últimos sustituidos por varios planos 2D del VDP2 ejecutados con inteligencia y pasando realmente desapercibidos muy bien, exceptuando algún escenario como el monasterio. El suelo de nuevo es dibujado con un plano rotado del VDP2 con una calidad equivalente a la recreativa. La resolución final y suavidad son el signo que hace gala en este juego y en la conversión. Es el punto que los une a ambos. Poniendo la resolución máxima que puede la SS(VDP1 703×479, final VDP2 a 704×480) a 60FPS como una roca. Como ya hemos hablado, llegar a esta resolución en el VDP1 conlleva solo poder tener 8BPP de color y perder las Funciones de Color como el Gouraud del VDP1. El gran trabajo de texturas en DOA hace casi imperceptible que no haya iluminación dinámica por fuente en los modelos. Con respecto al uso de los procesadores estamos ante el único juego de estas características que aprovecha todos los procesadores para el 3D. Así nos encontramos un uso del doble SH2 más el SCU-DSP, este último con un uso del 100% de la memoria y de un 45.5% de registros. En DSP de sonido encontramos un uso del 90% de memoria. Con respecto al uso de memoria del sistema está al 74%, con un uso del 65% del VDP1 y un 65% del VDP2, de un 87,5% de la RAM principal. Finalmente el port tiene una intro FMV, como era habitual por otra parte, en este se utiliza compresión DUCK(Video/audio) con una calidad aceptable de resolución(304×176 20FPS) y sonido(Estéreo 22Khz) pero a 15bit de color con dithering en una capa VDP2 sin zoom, desaprovechando tanto la posibilidad de máximo color, 32bits, como escalar al 100% de la pantalla para hacer le video lo más grande posible. El video como es común en Namco es de una factura alta. Ya si comparamos con la posterior versión de PSX, las diferencias son amplias. Desde la dirección de diseño, más moderna en el caso de PS1, como en la espectacularidad del juego. Ambos los son, pero de forma totalmente diferente. Ambos explotan a la máquina, pero con objetivos diferentes. En PS1 se utiliza iluminación dinámica, con sombras humanas y sombreado Gouraud. Una resolución y color estupenda 512×480 a 16bit con doble entrelazado a 60FPS. Sin llegar a la definición de SS, pero con gráficos más bonitos en otro sentido. También pierde geometría en los luchadores y contenido en los escenarios, quedando estos últimos bastantes más planos, y el suelo con error de perspectiva claro, donde en la SS es perfecto. En conclusión dos grandes, pero muy diferentes, versiones.

3.3 Lo complicado I – Bola EXTRA III: Teselación / LOD escenario / Mip Mapping

En este caso el Tomb Raider me llamo siempre la atención. Porque ese salto que daban las texturas según la distancia era más que evidente. Más adelante al poder verse con Wireframe confirme mis sospechas. Se usa una Teselación/LOD/Mip Mapping en el motor. También lo percibí en el Wipeout 2097 que también tiene wireframe. Aunque hubo muchos más.

En este punto señalar que es complicado saber si realmente sé esta usando una División en tiempo real de las mallas(Teselación) o estas ya vienen divididas antes, que seria LOD(Teselación precalculada). Lo mismo podemos aplicar para las texturas con respecto al Mip-mapping. Si se hace en tiempo real, consumiremos memoria RAM principal para código extra y ciclos de cálculo para dividir polígonos y texturas. Si lo precalculamos, hemos de guardar estos datos «duplicados o triplicados» en RAM principal para geometría y texturas Mip en la VRAM.

El Teselado y el mip-mapping, de nuevo, en la PSX era más accesible. Podemos ver en sus librerías al menos dos funciones orientadas a ello: 1) «Polygon Division» y 2) «Mip-map Function Library». Ambas usando el procesador GTE más la GPU. Lo cual nos lleva de nuevo a la conclusión de que Sega podría haber hecho algo similar. Usando el tándem 2xSH2+SCU-DSP+VDP1. Incluyendo funciones similares en las librerías para hacer esto de forma eficaz y dar a los desarrolladores el efecto de salida deseado.

Al final este «efecto» lo que hace es subdividir, incrementando o disminuyendo la cantidad de polígonos en función del tamaño relativo de una superficie en los escenarios o terrenos según la distancia a la cámara. Normalmente en función de valores de cercanía o lejanía máximas. El resultado que se consigue en una sensación de más polígonos en pantalla, cuando en realidad hay menos. Y una forma de controlar la cantidad máxima de los mismos en cada momento, para poder garantizar que el rendimiento en FPS no caiga dramáticamente. Este efecto junto al LOD en objetos, consigue optimizar de manera efectiva la cantidad de geometría y texturas óptimas en cada frame a dibujar por la GPU o VDP1 de SS.

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

SI, en parte. Hay juegos donde se ve claramente. Aunque quedan por descubrir, cuando algún emulador actual incluya el modo wireframe. De los juegos que tienen este modo como truco y podemos incluir los que posiblemente también lo tengan, o algo muy parecido.

Con modo wireframe:

Tomb Raider (1996) → Subdivision+Mip-map en clipping cercano, medio y Lejano.
Wipeout 2097 (1997) → Subdivision en clipping medio y Lejano.
Nascar 98 (1997) → Subdivision+Mip-map en clipping cercano..
Courier Crisis (1997) → Subdivision+Mip-map en clipping medio y Lejano.

Posibles:

Wipeout 1(1996) → Muy posible, en PSX estaba. Subdivision en clipping medio y Lejano.

Como ya vengo haciendo al final de un punto importante, me quedo con tres títulos que puedan ilustrar el mismo y que aprovecho para analizar, resumidamente, más en profundidad:

Tomb Raider
Lanzado en el 1996-10-24 siendo un juego de final de la 2ª ola de desarrollos Europeos. Podemos observar como los mundos en 3D dieron un salto increíble en este año y Tomb Raider fue culpable en parte de ello. Reconozco que la primera vez que vi el juego, unas capturas de PC en una nota de prensa. No me llamo la atención. Cuando lo jugué en una demo quede inmediatamente impactado. En aquel momento estaba a punto de tener mi primer PC. Y me compre el juego completo antes de tenerlo XD. Ya en aquel momento recuerdo comparar la versión PC con la de PSX con un primo mío. Después mucho más tarde he podido disfrutar de la que fue la primera versión de TR, en la consola de 32bit que quise en su momento y no tuve. Y me encontré con una versión increíble, para el momento y la maquina en la que corrió. Es cierto que en ciertos aspectos, y como se reconoció por uno de sus desarrolladores, salió quizás demasiado pronto y con algún bug. Con todo se nota que esta versión recibió mucho cariño por parte de Core Design. Y no se le puede reprochar que hicieron un gran trabajo, ya que no era una tarea sencilla.
Estamos ante un juego donde todos los elementos tienen Gouraud, algo que no encontraremos usualmente en la vida de la máquina. Además con iluminación con fuente en personajes/enemigos/assets y precalculada en el escenario y animado con color en la partes de agua.
Sigamos con los hitos de este juego. Esta dentro del club de polycount alto, 1300 en pantalla máximos (vistos por mí en Yabause, quizás más) por supuesto muchos más calculados, pero con bajadas de FPS. Las bajadas se producen en zonas complejas y grandes o cuando además se suman enemigos iluminados dinámicamente y con sus animaciones.
Más su IA y sonidos que se activan en este momento, movimientos de cámaras rápidos, etc… todo ello hace que el código implementado y la SS no dé para más, produciéndose los bajones por Vsync hablados. En versiones de 60Hz: De 30 a 20, de 20 a 15. En versiones de 50Hz: De 25 a 17, de 17 a 13. Además tengo mis sospechas de que el sonido en estos momentos está también participando mucho en la bajada de rendimiento. Quizás una saturación del BUS-B, por una mala optimización de código de sonido o del conjunto de datos. Es cierto que no he encontrado rastro del driver de sonido oficial de SEGA, no sé si estaban usando uno propio. El que no haya ajustes de sonido más los problemas con este, llevan a pensar que esta parte no está todo lo depurada que se necesita. Aunque podríamos decir que a pesar de todo sobre los 600 polys en pantalla con todo lo que pueda aparecer, el juego se mantiene por encima de los, al menos, 25FPS.
Más logros. Subdivisión y mip-map para elementos lejanos. La primera es una técnica muy útil para reducir los vértices totales a transformar para la CPUs y la segunda es una reducción de pixeles de textura a escribir para el VDP1 o cualquier GPU. Una técnica también utilizada por PS1 en el mismo sentido y además para reducir la distorsión por perspectiva en distancias cortas, además de facilitar el clipping o recortado de polígonos, traduciéndose en menos overdraw. Bien es cierto, que esta técnica, no era igual de funcional en ambas maquinas, resultando en SS más complicado ajustar el look final de los mip-maps y ocupando más VRAM para ello. Pero en conclusión siempre útil para un juego con una cantidad tan grande de polígonos que manejar. Y este lo era, de los que más en el momento.
Corriendo a la máxima resolución que le permite el VDP1 para tener Gouraud y 16bit de color, 352×256, muy parecida a la resolución de PC (320x240x8 la única a la que iba medio suave por software en el momento) o PS1(364×240). Las tres versiones comparten el nivel de subdivisión y el efecto “depth cueing” de desvanecimiento a negro en el far clipping y el valor de distancia del mismo. Estamos hablando entonces que las tres versiones mueven la misma cantidad de información geométrica. Con respecto a la cantidad de color, SS y PS1 están en 16bit, con un Gouraud más suave y una paleta de colores para las texturas muy similar. El aspecto del final es por la diferencia en el rasterizado de ambas, el de SS tan particular. La resolución máxima de las texturas es la misma, solo en SS el uso de Mip-maps como hemos dicho.
Otro logro en SS, hacer Render-to-texture de todo el frame-buffer del VDP1 que pasa a una capa del VDP2 cuando entramos en pausa/inventario para usarlo de fondo. El mismo efecto que en el resto de versiones. Pero en SS no es baladí. Y lo hace muy rápido, prácticamente es instantáneo. En esencia es en parte el mismo efecto que se usa en el reflejo de cristal en PS1, pero PS1 hace esto super gratis, a una mucha más velocidad que SS o PC.
TR hace un uso del doble SH2 formidable, en principio, a pesar de los slowdowns de los que hemos hablado. Se nota que Core hizo un gran trabajo para ir lejos con ellos dos. No es justo comparar este trabajo con el hecho en PSX, porque más de la mitad del trabajo equivalente en PS1 con su GTE estaba hecho en sus librerías. Lo dicho, lo hecho aquí por Core es remarcable y muy respetable, salvo los problemas que aún quedaron. Hay una presencia de uso del SCU-DSP que suele ser la normal encontrada en otros juegos de un 20% de Memoria y un 17,5% de registros, no sé exactamente si se está usando para algo de la pipeline 3D o alguna otra cosa. Lo más probable es que no. Por otra parte el uso del DSP de sonido es importante, el 60% de memoria.
Los FMV tienen una calidad muy similar entre versiones. Pero en PS1 la compresión DCT da un poco más de calidad. Pero el tamaño y la resolución final es igual entre todas 320×120 a 30FPS. En SS se usa Cinepack/PCM, con una calidad aceptable 24bit color y audio estéreo a 22KHz 16bit. El problema es el desaprovechamiento de esta profundidad de color en el archivo de video y la reproducción en el VDP1 limitado a 15bit.
El uso de la capacidad de memoria de SS queda en un 73%. Con un 95% del VDP1 usado, un 90 de la 85% de la RAM principal. Y con un 50% del VDP2.
Con respecto a las otras versiones del momento nos encontramos con que la versión de PC como de PS1 tienen un mejor acabado en detalles. Pero la que mejor sale parada es sin duda la de Sony. La suavidad que hacía gala en la época era un puñetazo en toda la cara. Cuando en PC, con una buena máquina, y SS en los mismos lugares había caídas importantes en PS1 se mantenía si no a 30FPS sobre los 25FPS. Es cierto que hay puntos, donde incluso la PS1 también sufre un poco. Tomb Raider era un juego muy exigente en la época. Siendo justos con la versión de PC, es la que menor deformación de perspectiva tiene y sin baile de vértices.

Zona donde PSX también sufre.

Lo más probable es que hacia final del desarrollo (2/3 últimos meses) el equipo de Core Design tuviese que repartirse el trabajo entre las 3 versiones. Al llegar a un acuerdo con SEGA para salir un poco antes y como se puede ver en el estado de las betas filtradas, por esta razón fue la versión que llevaban más adelantada. Cuando ya se pusieron a acabar el resto, y dado a los mayores requerimientos que tenía la SS para optimizar que el resto de versiones, dieron como resultado lo que tenemos.
En el fondo son tres versiones “casi” idénticas. Con una diferencia de apenas un mes entre los lanzamientos. Para mí las principales debilidades de la versión SS son:
- Un Mip-mapping muy agresivo (Mip-map lejano a igual resolución que el mediano pero poligono el doble de área), quizás buscando un aumento del rendimiento o por espacio en la VRAM en los niveles finales. Aunque creo que el VDP1 estaba dibujando con tiempo de sobra. En la beta de julio no está así, el Mip-map lejano es justo el doble de resolución que el cercano (Justo al contrario que la versión final). Sin notarse la división de polígono como en el resto de versiones. Es cierto que el rendimiento de esta Beta es incluso más bajo. Todo ello me hace pensar que la subdivisión, quizás, está más pensada para PC y PS1 para reducir la deformación por perspectiva, que para SS. Ya que por su forma de dibujar con esta técnica se reducía mucho este problema. Aunque el hecho de poder reducir vértices es atractivo cara a reducir la cantidad de información a procesar y cara al near-clipping de la cámara. Y no sé si a SS esta, tal y como esta implementada, puede perjudicar más que ayudar a la versión de SS.
- Falta de optimización en el código de transformación e iluminación. He llegado a la conclusión de que el problema real de la versión de SS es este, se ve claramente cuando pones el juego con wireframe, el rendimiento no varía.
- Falta de color en la iluminación bajo el agua sobre los personajes, como ya se hace en escenarios y Assets cuando miras desde dentro hacia fuera. Se ve que es algo que fueron implementando también en el resto de versiones, viendo las betas. En SS se quedó fuera.
- Algunas texturas corruptas en la versión EU (la primera), corregido en la USA y Japonesa.
- Problemas de texturizado en polígonos planos con texturas y mascara, apareciendo duplicadas ambas caras. En la Beta no existe este problema:
  - Piano Gym corregido en la USA y japonesa.
  - Puerta madera primer nivel no arreglado en USA. Si lo miras por detrás se ve bien.
- Problemas para el descartado de caras ocultas o Backface Culling.
  - Barandas nivel casa Lara. Solo en SS se ven las de atrás.
  - Puentes de madera que se ve la cara interior del madero. Esto se traduce en más polígonos con textura dibujados.
- Sonido con problemas, ruidos y paneo (L/R) extraños.
- Tiempos de cargas largos y sin barra de carga.
- Z-figthing es excesivo en plantas/billboards.
- Temblores y flickering excesivos en todas las texturas de los niveles y assets(maderos puentes), incluso más que en PS1.
- Transparencias en sombras (con un Scaled Sprite) y partículas planas como chapoteo agua cascadas, al ser planas no había problema de redibujado.
- Falta de pantalla carga casa Lara. Si en betas. Corregido en la versión USA y Japonesa.
- No hay configuración de sonido. En la beta “esta” se puede ver e interactuar con las opciones, pero no funciona.
- Faltan de colisiones en algunos assets. Corregido en la versión USA y japonesa.
- FMV a pantalla completa y a 24bit de color.
- Más efectos espectaculares:
  - Como el de distorsión del agua, pero mejor acabados.
  - Reflejo rombo del guardado, también posible en SS con limitaciones, pero posible.
- Mayor uso del VDP2 tanto en el juego 3D (UI, Fondos) como en FMV (Para mostrar los colores del video al máximo de 32bit color de VDP2)
- Falta la animación Lara’s handstand.

Finalizar con una anécdota. Me sorprendió que Tomb Raider no usara el High Speed Shrink. Primero pensaba que era una gran oportunidad para ganar rendimiento. Después descubrí que siéndolo, es poca. Y que el problema de TR en SS no está en el VDP1, el cual creo va holgado (incluso con un Mip-Map menos agresivo) si no en el código de transformación e iluminación como ya hemos hablado.

Nascar 98

Lanzado en el 1997-11-13. Final de la 3ª ola de desarrollos 3th party de USA. Para entender mejor este último juego de Nascar de EA es necesario entender de donde procede gran parte de su código. El origen de Nascar 98 es Andretti Racing, lanzado un año antes. Fue un port de Press Start sobre un desarrollo de Stormfront para un proyecto completo para PC y PS1. Ya en este juego las diferencias entre el tándem PC/PS1 y SS, eran patentes. Lo que simplemente paso, es un año después sobre esta base se creó este juego. En el caso de PC/PS1 se evolucionaron detalles, unos más grandes que otros. En SS, simplemente no llegaron todos estos, y otros ya no estuvieron en el anterior. Ni siquiera intentaron añadir lo que se quedó en Andretti Racing. Hagamos un pequeño desglose comparativo entre Andretti Racing y Nascar 98 de SS. General y con lo que se quedó fuera o inferior al resto de versiones:

Desarrollos originales para PSX por Stormfront, port de Press Start Inc. con 5 personas en total. 1 Programador. Tiempo desconocido.
Menús en SD en ambos.
Ambos con sonido ADPCM.
Sobre 1000 quads a 20FPS en SS. En PSX calculo que por lo menos 1500 a 20/25FPS.
La distancia de dibujo es menor en SS, y ademas tiene un Mip-Map bastante agresivo. PSX no tiene mip-mapping.
No tiene retrovisor. Aunque en PSX se reduce la distancia de dibujo como en SS o un poco más cuando lo pones.
No hay Render-to-texture para pantalla gigante en algún circuito, que si está en PSX.
Un mes de diferencia con respecto al lanzamiento en PSX.
Se mantienen los polígonos en los coches y sin Gouraud en ambos.
El fondo horizonte, no se ajusta en Y correctamente.
Igual resolución durante el juego 3D, texturas y color.
Hay sonido con reverberación en túneles.
Los FMV casi iguales a PSX (BPP, compresión, audio y FPS), excepto la resolución ligeramente inferior en él Y. En una capa VDP2 y no usa el zoom para llevar el video al máximo. ¿Por qué no? No lo sé. Con un codec de EA propietario muy bueno, usando el SCU-DSP en ambos juegos.
Contenido jugable y resto de características jugables. Excepto retrovisor.

Ahora entre las versiones concretamente de Nascar 98 para PC/PSX y SS:

Pequeño brillo animado solo en PSX.
Coche menos polígono en la parte delantera.
Gouraud estático en todos los coches en PSX, en SS no.
SS tiene teselacion/subdivision en el circuito en el clipping cercano, 1/2.
Los coches lejanos en PSX son LOD con menos geometria sin textura con Gouraud, en SS LOD con menos geometría, igual textura que en LOD cercano.
En cockpit de SS no hay manos, ni sombras barrotes animadas y ni lens flare del sol.
Las vallas en PSX son transparencias como cristal, en SS es una textura de reja.

En un año entre ambos proyectos hay una diferencia grande en la evolución entre las maquinas. En PSX hay un progreso en el motor y en la optimización, uso de Gouraud, un cockpit y efectos mejores. En conclusión aprendieron y fueron más lejos. En SS, nada. Todo igual.

En el 3D no usa el SCU-DSP.
No mejoran el código que tenía un año atrás con 2xSH2.
No aprenden a usar el VDP2 mejor para los fondos.
El VDP1 para usar el Gouraud.

En fin… Nada. ¿No tuvieron todo ese tiempo? ¿Esperaron a tener el código de PC/PSX y lo convirtieron al final? No lo sé, pero no representa lo que podía hacer la SS.

Con respecto al resto de datos. Como en el resto de títulos de EA para SS, Nascar hace uso del magnífico códec propietario DCT de EA, al igual que en Andretti Racing. Este hace un uso de los dos SH2 más el SCU-DSP intensamente, llegando en este último a un 90% de la Memoria y un 39.2% de los registros, unos datos muy altos de uso. Con respecto al DSP de sonido, se mueve de un 35% (FMV/menús) a un 70%(juego 3D) de la memoria, con signos de uso de efecto de reverberación. Y aunque hay alguna pista CD-DA, estoy casi seguro de que hay sonido ADPCM en ambos títulos, pues hay ficheros con extensiones tipo “adp”. Y es conocido que EA en este tiempo tenía un códec de Audio propietario basado en ADPCM. Con respecto al uso de la memoria disponible usa un 75% del total, llegando, también, a un 75% del VDP1 la RAM principal y el VDP2.

Courier Crisis

Lanzado en el 1997-12-20 a finales de la 3ª ola de desarrollos de USA también. Un título multiplataforma totalmente. Se ve claramente que está desarrollado a la vez y en mente, para SS y PSX. Comparten toda la información, pros y contras. Exceptuando algún detalle típico y otros curiosos. Comparten:

Igual resolución y color.
Subdivision y Mip-map.
Distancia dibujo.
Frame rate desbloqueado y muy inestable. Entre 60-20FPS. Una media de 30/25FPS.

No comparten:

SS tiene Depth Cueing, PSX no.
SS tiene algo más de distancia de dibujo que PSX.
Transparencias. En SS alguna en menús usando VDP1>VDP2.
Codec FMV diferente, pero calidad en resolución y área pantalla igual por escalado. SS DUCK/PCM, VDP1 a 15bit color dithering a 15FPS, audio mono.
Tiempos de carga un poco más rápidos SS.

Con respecto al uso de los procesadores, nos encontramos un uso de los dos SH2 estándar y signos interesantes de uso de SCU-DSP, no sé exactamente si para FMV o 3D. Pero llegando a un 23% de uso de memoria y 26% de registros. Con respecto al DSP de sonido está en un 35% de uso de memoria. Finalmente con respecto al uso de memoria disponible 83%, siendo el del VDP1 un 95% y del VDP2 un 50%. La RAM principal un 85%.

Fin de segunda parte.

9 comentarios

Pingback: Sega Saturn to the limit (I) | David Gámiz Jiménez | Portfolio and Personal Site
Alejandro Virgós Müller dice:

29 diciembre 2018 a las 22:31 10Sat, 29 Dec 2018 22:31:12 +000012.

Genial, superinteresante. Gracias mil!

Responder
zyrobs dice:

30 diciembre 2018 a las 04:42 04Sun, 30 Dec 2018 04:42:15 +000015.

Regarding the VDP1 fillrate calculation equation:
k + (x * y * l) + (y * n)

– k is the setup time, the amount of time it takes to read the draw command, set up all the internal registers, read the gouraud shading table (if there is any), set that up, etc. Playstation should also have a value for this, but I don’t know the exact figures.
– x / y are the sprite (texture) dimensions. Important to note that since this is a 2 dimensional values (X * Y), it includes the pixel overdraw.
– n is, according to Steve Snake, an approximate of the sdram cycle miss penalty. It is not an exact calculation, but a good enough general approximation.
– l is 3 cycles, for reading a texture, processing a texture, and writing a texture pixel. If you draw untextured polygons, you should only have 2 cycles here because you only need to process and write a pixel, no need to read textures. But this is just conjecture.

I think what the VDP1 does is, use 1 cycle to read a texture to internal register, 1 cycle to process it, and 1 cycle to write out the data from internal register to framebuffer. This is very inefficient. Yes, this does cut the max fillrate to less than 9,56 MPixel/sec. I don’t know why it does this, maybe a limitation due to the nature of SDRAM, or they just didn’t knew how to do it otherwise. This also explains why semitransparency can be so extremely slow. But for semitransparency, the «up to 6 times» figure may have been a best case versus worst case comparison, best case being untextured pixel, worst case being textured, gouraud shaded, semi-transparent pixel.

I don’t know exactly how the Playstation textures, but from the fillrate numbers it is evident that it can draw a textured pixel in 1 cycle (33,8 MPixel/sec). Maybe this was due to it using VRAM which is double ported (later SGRAM which could simulate this), maybe because it was just a better chip, maybe both.
For the 66MPixel value, it can only achieve this by directly copying pixels in memory without processing. I don’t know if the lack of processing is what doubles the speed, or the fact that such data is always rectangular so it can make 32bit read/writes safely. But you get no shading, no lightning, no deformation, only copy rectangular textures at twice the speed.

By the way you can do gouraud shading in 8-bit palette mode for Saturn. You have to use red colour only gouraud shading on a palette pixel. The 5 bits for the red shading correspond to the palette entry of the pixel. So this way you can ramp up/down the palette index using the VDP1, doing hardware lightning. The downside is that you have to pre-calculate the lightning gradients in the palettes, losing you colour count. The upside is that you can change the lightning colour by updating the palette. I think the cubes in the CD player do this to change colour.
You could even set custom colour gradients, like inversions, to do crazy things like simulate bump mapping. But only one tech demo of that exists.

I don’t think CPU usage can be measured in a percentage, because you also need to spend time using the bus or copying data. Maybe using the Slave SH2 or the SCU DSP at 100% would have made the Master SH2 too busy to process their data, leaving it less time to crunch numbers. A single usage percentage would not account for this. You also need time to upload draw commands to the system. And memory usage is even trickier because half the main memory is slower, and you might not have anything relevant in your game code for that, so you leave parts of it empty.

The percentage calculation is also misleading for texture usage, because textures and draw commands share VRAM. Have too much of one, and the others will suffer. You will end up needing to upload commands twice per frame or upload texture more often between frames, and while you do that, the VDP1 can’t draw anything (you are hogging the VRAM from it by uploading). So you have to balance things out, which leads to lower memory usage on average, to allow for higher peak values in poly count.

Great job on writing up a list of which Saturn games use which texture modes! That’s really fascinating!

And for the most graphically impressive Saturn games, I’d recommend you check out Scorcher. It uses very detailed and colourful textures (easily Playstation quality texturing), semitransparency (rectangular only to avoid the pixel overwrite bug), and decent speed. It is also one of the only games to use both rotating playfields of the VDP2, one of them being transparent. I think each level uses more textures than what fits in the memory, and the game is uploading it dynamically, which explains both the checkpoints and why sometimes they take longer than usual, and a very rare bug where if you race too fast, the game stops texturing for a second. For shading, it only has static pre-baked lightning on the level textures (plus fogging), but nonetheless it looks great because it has so many colours on screen.

Responder
SymbianRulez dice:

08 enero 2019 a las 15:59 03Tue, 08 Jan 2019 15:59:56 +000056.

Muy interesante. Esperando con ansias las siguientes partes jeje

Responder
Fafling dice:

15 febrero 2019 a las 23:38 11Fri, 15 Feb 2019 23:38:45 +000045.

Nice article. Emulators certainly are a great way to better understand how these games where programmed, and how they performed.

However, you should use caution when measuring the framerate of a game in an emulator : they are not accurate enough to match exactly the framerate of the same game on a real console. For example, you list Panzer Dragoon Zwei as 20 FPS, but on console it runs at 30 FPS in game and 60 FPS during cutscenes.

Also, I would add another feature that games could use to push the console to the max : using the higher clock rate of 28 MHz instead of the default one at 26 MHz. Increasing that chock makes both SH2, VDP1, VDP2, SCU and their memory faster. VDP2 displays automatically 10 % more pixels horizontally (352 instead of 320 in SD), but you don’t have to draw the additional pixels. That way you can cover the same screen area than at the lower clock rate, but with more cycles per pixel.

Strangely enough, all 3 Lobotomy Software FPS run at the lower clock rate. There’s always room for improvement, even in well programmed games…

Responder
Pingback: Sega Saturn to the limit (III) | David Gámiz Jiménez | Portfolio and Personal Site
Pingback: Sega Saturn to the limit (IV) | David Gámiz Jiménez | Portfolio and Personal Site
Pingback: Sega Saturn to the limit (V) | David Gámiz Jiménez | Portfolio and Personal Site
Ashmil dice:

03 agosto 2024 a las 15:53 03Sat, 03 Aug 2024 15:53:49 +000049.

Yo tengo una duda respecto a porque Sega Optó por el bendito SH-2 Teniendo otras opciones. Lo ideal hubiera sido un Motorola 68040 a 33Mhz o PowerPC 601.
Creo que les hubiera salido más barato usar un CPU a 66Mhz que lanzar la Saturn con esos dos SH-2 en 1994.

Lo mismo paso con Dreamcast que siguieron con el bendito SH, ya en ese momento había otras CPU Mejores en el mercado como: los Pentium II, Los AMD, Nec, IBM PowerPC G3, entre muchos para elegir.

Para mí gusto la Sega Dreamcast así tal cual está diseñada es una consola para 1997 cuánto mucho. Porque después de ese año sacarla sería un problema tecnológico con las muchas tecnologías que había y mejores.

Responder