Source: http://www.davidgamizjimenez.com/es/inpositivegames/sega-saturn-al-limite-iii/
Timestamp: 2020-04-04 14:07:15+00:00

Document:
Sega Saturn al límite (III) | David Gámiz Jiménez | Portfolio y Web personal
por david.gamiz.jimenez el 20 enero 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 321 juegos. De los aprox. 1200 títulos en total. Que son un 20% aprox. del total:
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
4. Lo complicado II: FMV pantalla completa y calidad color.
¿Qué era lo que esperaba ver en SS? Yo al menos, esperaba ver vídeos que:
Que estuviesen a pantalla completa o al menos con barras de imagen ancha tipo 16:9. Con una resolución de 320×240 para 4:3 o 320×144 a 16:9(bandas negras).
De 15 a 25/30 FPS sostenidos.
24bit de color o con una calidad en los degradados de color correcta y con artefactos de compresión mínimos.
Con una calidad de sonido mínima de 22Khz y 16bit de muestra. Estéreo en cinemáticas y música. Mono para diálogos o similares.
En aquel momento el codec que mejor conseguía esto, era el MPEG-1 para la imagen. Y MP2 para el sonido. SS no descomprimía por hardware este codec, podía mediante un complemento(tarjeta de expansión de descompresión de video MPEG1+MP2) de un precio alto. La 3DO y CD-i también tuvieron una tarjeta MPEG de expansión con una implantación similar a SEGA Saturn y 3DO. Las tarjetas salieron después del lanzamiento de las máquinas.
PSX también tubo una tarjeta de expansión hacia el final de su vida. Aunque por si sola tenia un formato de video que estaba implementado a nivel de hardware. De nuevo, en esta característica la PSX lo volvía a poner más sencillo y barato a los desarrolladores. Dando una calidad cercana al MPEG-1 y sencillo al ser JPEG por fotograma y procesados por PSX nátivamente. Este permitió vídeo a toda pantalla, con alto color, sin penalizar para usarlo y mezclarlo en 2D o 3D. Además con una licencia de uso y edición para la calidad obtenida muy buena. Se llamó MJPEG, aunque otros desarrolladores usando como base los algoritmos del co-procesador de FMV de la PSX, el MDEC, hicieron variaciones de codecs, como la propia Square Soft. Es un codec que no tiene compresión entre frames, ni compensación de movimiento como el MPEG1. Solo el algoritmo Discrete Cosine Transform (DCT) que comparten con JPEG. El ratio de compresión puede ser alto, similar al MPEG1, pero dado que carece de todas sus características el pasar de 20:1 degrada la imagen demasiado. Siendo este el valor más usado.
Mientras la SS tenia que descomprimir video y el audio de los FMV por software totalmente. Es decir de nuevo había más complicación, pero se pudo hacer cosas similares. Tanto en Mr. Bones(FMV de fondo a pantalla completa) con Duck Motion Video o Shin Megami Tensei: Devil Summoner (pantalla completa con transparencia) con Cinepak, ambos muy bien usados. Ejemplos en el otro extremo como en el caso de Time Commando, que en general es una versión muy(muy) mala para la SS, pero en el tema FMV es desastrosa y mejorable claramente visto los ejemplos anteriores.
Los codecs al final codifican o descodifican la información multimedia. Pero otras de las variables esenciales en la calidad de estos es su factor de compresión y la calidad final después de esta compresión/descompresión. Estos codecs en la época eran tecnologías muy complejas y costosas, al día de hoy también. Pero en aquella época aún más. Conseguir digitalizar información multimedia con calidad y cantidad era y es uno de los objetivos principales. A donde quiero llegar es que el “bitrate” o la cantidad de información necesaria por segundo para video o audio, era otra variable que influenciaba tanto en la calidad de los contenidos, el espacio que ocuparía en los soportes y los requisitos de proceso según la complejidad de cada codec de compresión. Es aquí donde las velocidades de los CD-ROMs de la época jugaban su parte del problema.
Los sistemas CD-ROM, tanto de PSX como de SS, de la época compartían las siguientes limitaciones comunes:
Lo que no tengo claro es si en el caso de SS al tener más cache de CD-ROM, CD-ROM DRAM y el SH1 ayudaba a tener más capacidad de transferencia final:
Otro punto interesante a tener en cuenta en esta área son las herramientas y tecnologías que de las que disponían cada soporte. Con respecto a las herramientas de edición de video, patentes y licencias de uso de codecs/decoders de vídeo… Sony ya era en aquel momento una propietaria de estas muy importante, y SEGA no. SEGA tenía algunas patentes y conocimiento, gracias al SEGA-CD(Mega-CD). Pero Sony como compañía dedicada a la Electrónica General tenia(y tiene) divisiones de Vídeo y Audio para consumo electrónico y de cine.
Aquí de nuevo SEGA hizo lo que pudo aliándose con Hitachi y JVC para el desarrollo del FMV via hardware más apostando por el extendido Cinepak junto con el avanzado Duck Video para la via software. Curiosamente ambas soluciones vía software también en la competencia más directa: 3DO.
Además más adelante creó junto a su subsidiaria tecnológica(a día de hoy también) CRI/CSK, el MPEG SoftDec. Un MPEG-1 por software completo, aunque estaba muy limitado en SS vía software(también aprovechaba la tarjeta de expansión de Video de la SS), además de ser más caro con respecto a Duck Video, ya no decir con respecto a Cinepak.
Lo que está claro es que SS tenia potencia de cálculo. El problema como de costumbre, era sacarle partido. Pero analizando la evolución del desarrollo he podido ver como poco a poco se iba usando la SS mejor y obteniendo mejores resultados. Usando la unidad VDP1 y un SH2 con sonido WAV mono, hasta llegar a usar ambos VDPs, color 24bits total, los dos SH2 más el DSP de SCU y sonido estéreo ADPCM. Incluso con la posibilidad de que se llegara a usar el DSP del SCSP para mejorar el sonido ADPCM o PCM. Llegando a una calidad de FMV muy cercana o igual PSX en muchos aspectos y en bastantes casos.
Finalmente, también es importante tener en cuenta. Que al existir un add-on para ver Video-CD. Y claro, a SEGA y sus socios no les gustaría la idea de que se pudiese obtener lo mismo vía software, sin pasar por ellos. Como decíamos en SS, todo se complica un poco más. Y esto, de nuevo, no ayudaba al desarrollador o al cliente final a dar o tener la misma o más calidad frente a PSX.
¿Al final se consiguió arreglar esta situación de desventaja?
SÍ, pero parcialmente. Me explico:
A) Por parte de la propia SEGA en sus SDK podemos ver el tema según codec y timeline de vida de la SS. Tenemos que aclarar que una cosa es cuando se da soporte a una característica y cuando esta llega a un juego finalmente. Así podemos tener diferencias pequeñas o grandes de tiempo:
1. Desde el 1993/94 (Pre-lanzamiento) y el 11-1994 (Lanzamiento oficial):
Cinepak+PCM. SBL 1994-10-31 [Prelanzamiento o Release 1]
Introducido desde el inicio de las SBL como librería a parte de las mismas.
Cinepak es un codec que nació en el 1991. Muy extendido y usado en Mac OS después en PC-Windows. Su licencia en el tiempo era la más competitiva, y sus requisitos para funcionar también. En este mismo sentido la competencia directa, es decir 3DO y Jaguar también lo implementaron. Curiosamente, y parece ser, usando o quizás licenciando parte de la implementación a la propia SEGA. Porque en algún juego de 3DO se ha visto el contenedor .FILM, seria el caso de Lemmings de Psynosis.
SEGA empezó a usarlo en el Mega-CD y CD-32X, y lo fue evolucionando en su propia rama. Con mejoras sobre el estándar a lo largo del tiempo. En esencia “el Cinepak de SEGA” o visto como CPK es en el fondo un tipo de contenedor FILM de SEGA. Donde la tecnología de compresión usada es la misma que la de Cinepak original. Con perdida, basada en VQ (Vector Quantization) más el control de diferencia entre frames. Consigue una compresión aceptable con ficheros de videos usables para CD-Roms de la época desde 1x, con una calidad de color u artefactos aceptables. Y con bitrates entre 2100 y 1800 kbps para el video con una calidad buena para 2x de velocidad en CD-Rom. En el lenguaje tecnológico estándar podríamos estar hablando de un ratio de compresión general de 20:1 a un máximo posible de 200:1.
SEGA tanto en USA como en Japón desarrollaron mucho su codec y conocimiento para FMV mediante Cinepak. Aunque podemos percibir que SEGA Japón se centro más en Cinepak que SEGA USA. Se ve en el catálogo que el uso de Cinepak es mayoritario en lado nipon. Llegando a evolucionarlo junto a ADPCM y más adelante junto a ADX.
Otro handicap que tenia ya entonces Cinepak. Es que buena parte de las herramientas necesarias para crear video estaban en los OS de referencia de manera preconfigurada. “Abaratando” aún más los costes para los desarrolladores y homogeneizando aún más el aprendizaje entre sistemas. Así Mac OS como Windows 95 ya llevaban los codecs de Cinepak integrados en sus sistemas multimedia en aque momento. A parte de alguna herramienta extra para edición o “autoring” básica.
En las versiones liberadas publicas al día de hoy del SDK de Cinepak de SEGA para SS, está solo la versión 1.20 en forma de un conjunto de librerías llamadas de “Authoring” (1994/12/26) muy típicas de la época. Donde encontramos el código fuente para el reproductor de Cinepak por software para la SS y también el soporte para MPEG vía tarjeta de expansión. Además de software para PC o compatibles para conversión o “authoring” de los videos sobre en el contenedor de “Film” de SEGA.
Conocemos la existencia del SEGACODEC v2.0 por un DTS de SEGA que lo anunciaba en el 10-1994 donde solo hace referencia al SEGA-CD. En el SDK oficial liberado, podemos ver que es la Cinepak for SEGASATURN Rel.3 y SATURN Author Rel.2 datada el 31-10-1995. Con código fuente GNU del reproductor y de la librería en general.
En este SDK la versión de la librería de Cinepak es la 1.20. Podemos ver un histórico bastante largo que empieza en el 0.8. Y ver como evoluciono desde al menos 09-1994 hacia adelante. Mejorando el uso primero en VDP1, más adelante el del VDP2, también el manejo de sonido y transferencia de los datos usando CPU-DMA, SCU-DMA y SCU-DSP. En otra librería podemos ver como fecha inicial 1994-11-10. Aunque a buen seguro esta librería de Cinepak para SS se lanzo o desarrollo entre el 9 y el 11 del 1994. Meses antes del lanzamiento final de la consola en Japón. Y tuvo un fuerte desarrollo durante todo ese año.
Aunque a través de la investigación que he hecho podemos ver que en una primera etapa varia entre el uso de 1x SH2 y 2x SH2. Pero tendía más hacia el uso de 1x SH2. Como en general el resto de los juegos en la 1ª ola. Los ficheros están en su totalidad 24bit BPP, porque Cinepak trabajaba sobre un espacio de color fijo de 24-bits RGB. Pero en muchos casos el vídeo es mostrado en el VDP1, limitado a 15BPP de color el resultado final. Aunque durante esta primera parte algunos usaban el VDP2 para mostrar el máximo numero de colores disponibles. También puede que una de las razones para usar el VDP1, era el poder escalar fácilmente los vídeos que no estaban al máximo de resolución. Aunque el VDP2 también soporta escalado, no tan flexible pero lo soporta. Solo unos pocos usaron el escalado del VDP2 para los videos a pantalla completa. También he encontrado el uso de 2 layers del VDP2 alternativos en color de 16-bits, aunque solo en 2 juegos. También podemos ver uso de SCU-DSP en la reproducción de Cinepak. Según he podido leer en la Documentación del SDK, era posible para hacer transferencia de datos del BUS-A al BUS-B(VDP2 32bit y SCSP), aunque estaba limitado este uso por lo delicado del mismo.
Destacar como detalle que Mplayer y VLC marcan 600FPS en muchos vídeos. Que según explica detalladamente en Wikimedia parece más probable que sean 15 o 30FPS. Con la nueva versión de VLC podemos confirmar como algunos van a 15FPS y otros a 30FPS. La mayoría a 15FPS. Lo cual tiene bastante sentido para la época.
Aunque se llegan a ver vídeos a 24 o 30FPS, en esta primera época es raro, pero a coste de bajar la resolución. O introducir aún más artefactos y perdidas de degradados o colores entre frames.
El sonido usado principalmente es sin compresión PCM. La relación de peso entre el video y audio, hace que la calidad de la compresión cambie mucho. Era un handicap tener la parte de sonido sin compresión. Porque restaba mucho a la de video. En estos normalmente el video no pasa de 1800 kbps. Precisamente por esta causa, para poder llevar al máximo el espacio para el video, en muchos juegos se usaban valores de sonido bajos para llegar a mimos de 176 kbps hasta máximos de 706 kbps:
Normalmente: 11025 Hz 8bit Mono / 22254 Hz 8bit Estéreo / 22254 Hz 16bit Mono
Es raro ver: 44100 Hz 8bits Mono / 44100 Hz 8bits Estéreo / 44100 Hz, 16bits Mono
Aún más extraño 44100 Hz 16bits Estéreo. Porque es llevar la calidad a CD-DA, y la cantidad de kbps al máximo. Pero en esta etapa particularmente no se ve, quizás también por los problemas de transferencia de datos a lo que se hace mención el histórico del codec.
Como usos destacables del codec Cinepak, podríamos destacar el hecho por parte de Nextech. Usando los dos SH2 y la máxima resolución. Con buena compresión con relación a los FPS y una calidad de sonido buena y ajustada. En los dos Battle Arena Toshinden, D-Xhird y Resident Evil. En este último llegando a su tope de calidad.
Duck TrueMotion S [Pre-lanzamiento (1994-10)]
Duck TrueMotion 1 fue introducido por SEGA USA dentro de la plataforma SS y en SEGA Japón fue AM2 la que lo integro rápidamente en sus SGL de manera interna. Pero en la proporción de uso, Duck es más usado en desarrollos de USA además desde muy temprano, que seria el caso de Crystal Dynamics.Aquí nos encontramos con una posible explicación. Ya que Crystal Dynamics desarrollo también en este momento los juegos para 3DO usando estos codecs, podía usar el mismo trabajo para ambas maquinas. Aunque la calidad entre algunos juegos no era igual. Por ejemplo en Off World Interceptor Extreme, los videos de SS están en 24bit y los de 3DO en 16bit. Es posible que el ARM o/y el DSP de 3DO no pudieran descomprimir este nivel de calidad disponible en el codec.Podemos concluir finalmente que la procedencia del uso de este codec partió de SEGA USA. Ya que el codec es de una empresa de New York, y además fue usado primero(con casi total seguridad) en la plataforma 3DO de procedencia USA también.
Hay código fuente GNU del reproductor y de la librería en general. Este codec tiene varios perfiles de compresión. Los primeros juegos en usarlo principalmente fueron de USA, como Crystal Dynamics. Además en su opción de calidad de algoritmo superior: 24BPP.
Ahora quiero entra más en detalle en los algoritmos de video disponibles de Duck Truemotion S.
Pero antes de empezar a ver los pros y contras de los dos algoritmos de Duck. Hay que destacar que al igual que Cinepak, este trabaja sobre un espacio de color RGB, de 15 o 24 bits de color. Para ambos tenemos un frame rate Variable(VBR), sin capacidad de control más allá de las opciones típicas.
Bien, el algoritmo de 16BPP ya de por si es excelente. Tanto en opciones de configuración, como en resultados finales. La única pega que se le puede achacar es que la falta de degradados de color en determinadas situaciones es muy clara y la perdida de detalle también. Es cierto que tenemos opción de añadir el efecto de dithering, pero por desgracia, al menos bajo mi punto de vista, este se sigue notando mucho incluso en las antiguos monitores o TV de CRT. Por lo demás la suma de la magnífica compresión de frame clave más el uso del interframe(también hay opción intraframe menos eficiente) hace que el ratio de compresión general y el frame rate final sean muy buenos. Si esto le sumamos el stream de audio comprimido. El resultado total, es un formato que gana en muchos aspectos al MPEG de PS1, y que queda bastante cerca en calidad final. Puede llegar con facilidad a la máxima resolución de la época 320×240 a 25 o FPS. Con ratios de compresión altos y frame rate bajos con valores muy buenos. Además de ser útil en el uso dentro del VDP1 con todo lo que ello conlleva. Por último, permite dejar suficiente ancho de banda para tener un stream de audio a la máxima calidad del ADPCM de duck: 44100Hz Estéreo.
Sin embargo con el algoritmo de 24BPP, tenemos el doble de datos para el color. Dando como resultado unos degradados y calidad en los detalles casi perfectos, y prácticamente a la par de los resultados del algoritmo IDC. No igual, pero muy cerca, y quizás en algunos aspectos mejor. Un ejemplo sobresaliente es Congo, donde todo el metraje de imagen real luce de manera magistral, con unos degradados de color magníficos y unos artefactos en el color mínimo de 4x4. Donde he llegado a ver hasta cerca de 45.000 colores únicos en un frame. El coste está en que es más complicado llegar a las resoluciones máximas y menos aún a FPS altos. Podemos llegar a ver algún caso de 320x196 como resolución máxima, encontrándonos valores por debajo de 320 en X en la mayoría de videos. En FPS, la mayoría esta a 15FPS. Aunque podemos encontrar algún caso aislado a 20FPS o 24FPS. También pasamos a necesitar usar el VDP2 en modo 24-bits de color, perdiendo la flexibilidad del VDP1, y aumentando la complejidad de los buffers para el reproductor. Además, por contra al de 16BPP bajamos el ratio compresión y subimos el frame rate. Perdiendo a su vez espacio para el stream de sonido. En los videos 24BPP encontramos que se prefiere bajar la calidad del ADPCM para ganar espacio para el stream de video. Lo cual es lo más lógico. Bajar a ADPCM 3bits a 22100Hz Estéreo, no es una gran perdida. Sigue sonando maravillosamente bien. Con el ADPCM de Duck no es posible bajar más de 22050Hz en el sampleado, en ADX por ejemplo podemos bajar hasta los 8000Hz. Lo cual hubiese permitido algo más de margen para el stream de video. Con una bajada de calidad sonora también considerable.
El autor de los mejores vídeos en DUCK de SEGA fue Eric Caplain o Eric Ameres que fue unos de los ingenieros jefes de Duck en aquel tiempo. Que también desarrollo y mantuvo, al menos, el reproductor y todo lo relacionado con el KIT de video para SS. Como el mismo nos ha podido confirmar en las chat Discord de la scene de SS.
Antes de seguir con la cronología detallada de la evolución de este codec. Voy a hacer un resumen de la evolución en general del codec:
Calidades video/audio:
*1 Aunque el soporte de 24BPP parece que esta desde el lanzamiento soportado en el reproductor. No se ven señales de configuración en el codec de Windows en la versión 1c, única versión publica ahora mismo. En los tutoriales también solo se hace referencia al algoritmo de 16BPP. Puede ser que durante un tiempo Duck solo diera esta opción como servicio interno o de consultoría en sus instalaciones. No lo tengo claro.
Primero 4bit. Estándar 44 kbps.
Después 3bit. Reduce los 33 kbps, al mínimo. Disponible al menos desde la “Preliminary Version TM 200 (Jan)01-1995”
Uso de la SS:
Uso 1xSH2 o 2xSH2. Usando código ensamblador para acelerar al máximo la descompresión.
Uso del VDP1 solo.
Uso del VDP2 en 16 bit
2 layer alternados, especie de doble buffer.
Uso de VDP2 en 24bit
1 layer con máscara/transparencia.
Como texturas con máscara para el VDP1.
Uso de doble buffer, no se como exactamente, pero tubo soporte de doble buffer el modo 24-bits. Confirmado por el propio desarrollador.
Finalmente, el uso de SCU-DSP y del SCSP-DSP es desconocido:
En el del SCU-DSP he podido apreciar que aproximadamente el 50% de los FMV de Duck tienen alguna señal de uso del SCU-DSP. Muy pocos con señales clara, sobre un 7%. Puede que en algún juego se uso alguna librería de SEGA, para transferencia o sonido, parecido a Cinepak que haga uso del SCU-DSP.
En el del SCSP-DSP es aún más desconocido. He podido ver algún uso en los FMV pero muy reducido. No puedo determinar si el uso es directamente por parte del reproductor de Duck o por algún uso del eLinker de Yamaha para el sonido. Si he podido ver algún código en “ASM” de el KIT de Duck para el sonido, pero el uso exactamente lo desconozco.
Por último, según Eric Caplain/Ameres dice que el no uso para nada ninguno de los dos DSP, el todo lo hizo con los 2x SH2. Aunque cabe la posibilidad de que otros desarrolladores que implementaron su reproductor hicieran algún añadido. Como digo, posible pero desconocido su uso real.
Duck True Motion 16/24*1 + PCM 8bits [Preliminary Version TM102 1994-12]
Podemos ver en alguno de los primeros desarrollos de SEGA el uso del codec Duck en la parte de video, pero no en la parte del audio.
En la parte del video vemos evidentemente el uso del modo 16BPP. Aunque no tengo evidencias claras de si el modo 24BPP ya estaba listo en este momento.
Por otra parte como decíamos en la parte del sonido no sé uso la posibilidad ADPCM que el codec Duck daba en el stream de audio y se ve un uso sin embargo de PCM. El porque es claro, en las primeras versiones no disponían aún de esta característica. A partir del Preliminary Version TM102 tenia como opción PCM: Sampleado a 22 o 44Khz, 8bit solo y mono o Estéreo.
1xSH2, SCU-DSP Señales, SCSP-DSP 35% Memoria
Estamos ya ante versiones mucho más maduras que la anterior pre-lanzamiento. Ya podemos encontrar un soporte total para reproducción de 16 y de 24bit de color de DUCK. Este último entiendo que así, porque la cantidad de juegos ya con este era considerable. Tanto en esta franja ya de tiempo, como un tiempo después. Entiéndase ya en desarrollo y más adelante lanzados.
Desconocemos si en algún momento entre las versiones 1 y 2. Duck implemento en el codec de codificación de Windows la opción del algoritmo de 24BPP. Si es cierto que podemos ver más juegos con videos a 24BPP(Un 16% del total en 24bits de los que he analizado) en estos momentos curiosamente la mayoría de Crystal Dynamics como explicamos antes:
Además de sonido Duck ADPCM a 4-BIT, ya se disponía de la opción de Duck ADPCM a 3-BIT que fue implementada en algún momento entre las versiones preliminares y la primera release. Bajando desde los 44 kbytes/sec a 33kbytes/sec para la máxima calidad 44Khz Estéreo.
Incluso ya en estas mejoraron el soporte de PCM.
También destacar también la mejora en la gestión de los bufferes para reproducción. Ellos hablan de 3 Buffers. Creo que entendido, leyendo el código, que se usaron la VRAM del VDP1. El Framebuffer del VDP1. Y En el VDP2 normalmente se usa un layer de 24-bit para videos de esta profundad de color.
Pero he encontrado el uso de 2 layers del VDP2 alternativos en color de 16-bits para videos de esta profundidad de color. Me resulta este último caso muy curioso. Solo 7 juegos del total, significa un 2,2% del total. Un numero realmente bajo. Puede que sean videos con alguna configuración de interframe o resolución o tasa de bits alta, y el reproductor usa esta solución para poder cargar toda la info a tiempo. No deja de ser curioso.
Por último comentar, no por menos importante. También la mejora de la implementación de la característica de compresión entre frames y la resolución de color en X/Y. Parece ser que fueron mejorados también entre las versiones previas y estas finales.
Podemos ver finalmente ya el soporte para sonido de profundidad de 16bits, calidad CD, en las librerías de Duck. A partir del 02-1995. Y el uso en algún juego.
En general podemos hablar que el uso de PCM con Duck es muy reducido. Estamos hablando de un 16% del total analizado. Lo cual tiene todo el sentido. Pues usar ADPCM tenia muchas más ventajas que desventajas. La única razón puede ser, que los costes fuesen algo más reducidos. Porque el codec de compresión de ADPCM para que iba aparte del de video.
1411 kbps 44100 Hz Estéreo16 bits = CD-DA
2xSH2, SCU-DSP Señales
Como hemos comentado ya, Duck primero implemento el ADPCM estándar de 4bits de profundidad. Después, poco después la verdad, implemento el de 3-bit. Pero encontramos muy pocos juegos que lo usen la verdad. Solo un 6,7% del total usaron el ADPCM DK3.
354 kbps 44100 Hz Estéreo 4bits
267 kbps 44100 Hz Estéreo 3bits
2. Poco después desde 11-1994(Lanzamiento oficial) a 04-1995(1/2 año del Lanzamiento oficial):
Solo estaba disponible mediante un add-on, que no era precisamente asequible. El cual se insertaba en el puerto de expansión posterior de la SS. Este descomprimía totalmente y de manera autónoma el video en MPEG-1 y el audio bajo el estándar MPEG-1 Layer II. Esta tarjeta de expansión poseía un conjunto de chips de descompresión de video y audio, más memoria adicional para hacer todo dentro de la misma tarjeta. Sumándose a la SS aprovechando las salidas a el VDP2 y el SCSP para llevar la imagen y el sonido ya descomprimidos.
Con un máximo de 352×240 a 30FPS a YUV/24bit de color y una calidad de sonido equivalente a la del CD-ROM:MPEG Layer II a 44100Hz Estéreo.Con picos totales estables máximos de 2550 / 1150kbps. Y tasas de datos muy bajas tanto para video: 2326 / 926 kbps y audio: 224 kbps.
Además este poseía una serie de efectos y utilidades exclusivas para mejorar la calidad de imagen final o para ser usados en videos interactivos.
Ratio de compresión teórico de 26:1 a 160:1 para video y de 4:1 a 6:1 para el audio. La combinación de Discrete Cosine Transform (DCT) más corrección por movimiento. Consigue este gran cantidad de compresión en el video.
Su uso en juegos no se vio hasta bien entrado el 1996, y solo en Japón.
La calidad visual, el tamaño de archivos y bitrate era el mejor de la época.
El uso de la tarjeta para MPEG-1 en juegos en el sistema es anecdótico y limitado a Japón, donde más se vendió el add-on de SEGA junto a Corea. Donde la oferta de Video-CD fue más grande y expandida que en USA o EU.
En este momento ya con la disponibilidad de SGL, también se introdujo la librería de Cinepak para las SGL. Sin mayores cambios y con prácticamente las mismas opciones que para SBL.
3. Desde el 04-1995(1/2 año del Lanzamiento oficial) a el 11-1995(1 año del lanzamiento oficial aprox.:
El último release que se conoce data del 11 de Octubre del 1995. Es la release 3.0. No disponemos de la notas de lanzamiento. No sabemos exactamente que mejoro o añadido, al ya magnifico estado del codec. Seguro que correcciones y pequeñas mejoras de mantenimiento. Pero también seguro que alguna característica nueva. Ya que un cambio de numeración significa siempre algo de este tipo.
4. Desde 11-1995(1 año del lanzamiento oficial aprox.) hasta el final de la vida de SS (1998-2000):
No tenemos datos que puedan marcarnos un soporte en las librerías de Cinepak. Puede que estemos ante una implementación vía librerías SBL del ADPCM junto con el Cinepak. El primer juego que vemos hace uso de esto es NiGHTS into Dream. También podemos aprecias dos hechos más. El uso de CD-XA y un tipo de CPK no estándar. Está claro que el Sonic Team, busco la máxima calidad posible para los FMV, e hizo todo este trabajo nuevo.
Aunque podemos encontrar en más juegos esta combinación de factores no son muchos. Significando un ínfimo 2,3% del total de juegos que están usando Cinepak.
No he podido determinar los datos del stream de video o Audio por .cpk no estándar, Film 1.08.
Siendo posible que haya alguno más. Yo solo he podido detectar un juego que combine Cinepak junto a MIDI. Este es The Story of Thor 2. Subiendo al máximo los kbps para el video, alrededor de 2200kbps. La verdad que sin llegar a tener una resolución y calidad final destacables. Y para colmo usando VDP1 para mostrar el video.
Efectos de máscara y transparencia
Tanto en Duck como en Cinepak se implemento la posibilidad de usar los datos gráficos de video, como si fueran Sprites para el VDP1 o para poder usar la transparencia de VDP2 para efectos más especiales. En el caso de Duck, no he llegado a identificar ninguno juego, pero de Cinepak si. La saga Devil Summoner:
Los primeros juegos que se ven utilizando esta combinación son en el 1998. Aunque el copyright de ADX pone 1996-97. Son solo un 5,5% del total de juegos con Cinepak. Lo que podemos apreciar claramente en estos FMV es un uso de SCU-DSP. Que he llegado a la conclusión es por parte del codec ADX para la descompresión con tasi total seguridad. Además también he visto uso del SCSP-DSP durante los videos, puede que para algún filtro de low-pass.Gracias al uso de ADX, estamos hablando que a máxima calidad de sonido. ADX deja para Cinepak 1056kbps extra. Eso puede suponer el doble de cantidad de datos por segundo que usando PCM.
Los resultados en la práctica son fantásticos. Estos “últimos” Cinepak se ven magníficamente. Burning Ranger no especialmente pero otros como: Baroque, Lunar 2 – Eternal Blue y Wachenröder. En Wachenröder he llegado a ver cerca de 3000 colores únicos, una densidad de color por pixel muy alta para este codec. Se ven absolutamente preciosos. La calidad del color, los degradados y los artefactos de compresión llegan al máximo de calidad para este codec.
CAK→En el fondo un tipo de contenedor .FILM de SEGA
ADX a 44100hz Estéreo 4-bits 352 kbps
Uso de SCU-DSP y SCPS-DSP
El codec Sofdec de SS está muy indocumentado. Según su copyright es de 1995-96. Aunque parece que no deja de ser un MPEG1. En algunos unos lugares dicen que tiene frames I y P. Pero no los B. Que hace que en esencia sea algo similar a Cinepak o Duck, ambos con una “especie” de frame I y de frame P o interframe. Pero con un algoritmo base mucho más potente y trabajando sobre el espacio de color YUV. Que da un resultado de color y degradado excelente. También una mejor ratio de compresión. El IDC en este caso. Padre del JPEG. IDC es claramente superior a Duck y a su vez al VQ de Cinepak. Pero en otros lugares que es sin embargo un MPEG1 completo.En esta captura del HRAM que ha hecho el compañero @TrekkiesUnite118 podemos apreciar claramente la naturaleza IDC del codec, muy cercana al estándar MPEG1: Lo que podemos aprecia en la captura de la HRAM a modo sencillo, es una configuración YUV 4:2:0 típica. Pero el canal Y parece estar a la ½ de resolución en la horizontal, y total en la vertical. Así mismo los canales U y V están justa a la inversa. Lo que probablemente al final de descompresión se resuelva escalando por 2 en ambas direcciones. Lo que también podemos ver es lo que parece ser un doble buffer de descompresión por el canal Y e incluso más para los canales U y V. Con el aspecto de escala de grises en cada canal, y la inversión de color en los canales UV a un cuarto de resolución de el Y. No es posible saber si existen, con certeza, los frames P y B. Podrian ser los frames de más que hay en los canales U y V. Pero al menos con esta información podemos confirmar que la SS estaba descomprimiendo por si sola un codec tan complejo como este.
Llegando a resoluciones máximas de 240×160. Que como vemos es realmente 120×160. Estaríamos en una cifra máxima de 75 macrobloques de 16×16. A 12FPS probablemente un total por segundo de 900 macrobloques. Lo cual nos podría estar indicando, que efectivamente Sofdec descomprimía MPEG1 completo, el cual es mucho más exigente que el MJPEG.
Por la parte de stream de audio, también existen dos versiones. Una que el stream de audio es un ADX de CRI, lo cual explicaría el uso del SCU-DSP de la SS. Y es la más extendida y aceptada. Y la otra versión es que es un MPEG audio layer II.
Como digo no hay herramientas oficiales liberadas de este codec para SS. Existe alguna utilidad. Pero no hay un workflow claro para reproducir o analizar su contenido.
Por otra parte el .SFD era en teoría el tipo contenedor estándar de CRI para Sofdec. Que juntaba los streams de video y audio en un solo archivo. Digo en teoría porque en el caso de SS encontramos otros ficheros en los primeros juegos. Donde no sabemos exactamente si están los dos streams o que tipos de streams.
Finalmente una de las ventajas que tenia este codec para SS era que podía ser reproducido tanto solo con la consola base por software o aprovechando el complemento de VCD para reproducirlo totalmente por hardware. Claro esta, la diferencia en el resultado final era obvia. Reduciendo a la mitad la resolución y FPS, si no menos.
Tampoco sabemos si el propio codec degradaba la calidad la vuelo, o si existían el doble de archivos o streams de video en el mismo contenedor, para ambas calidades y versiones disponibles.
Eso si, para la reproducción por software este es capaz de usar en paralelo tanto los 2xSH2 más el SCU-DSP. Es muy posible, como hemos dicho, que el uso del SCU-DSP sea para el audio ADX. Y todo ello sobre una capa del VDP2 a 24-bit de color para poder mostrar el máximo de color en el sistema.
Los primeros juegos en usarlo son del mismo año 1996. Aún no se está usando el contenedor estándar .SFD.
Parecen streams de video al máximo de resolución. No se si son las versiones para la reproducción por hardware.
Audio desconocido. Estéreo. CD-XA Mode-2
Parecen streams de video a la mitad de resolución. No se si son las versiones para la reproducción por software.
Este es el primer juego donde vemos el tandem final de Video+Audio por CRI/CSK vía software para SS. Pero ya como streams dentro de un archivo .SFD.También podemos encontrar datos en el cabezal del contenedor:
ADX Calidad desconocida. Estéreo. CD-XA Mode-2
Por último, he visto un juego que combina su flujo de video con una pista de CD-DA. No he conseguido identificar el tipo de codec, así que puede ser cualquiera o ninguno, por eso el titulo tan variado. Puede que haya alguno más, pero yo no lo he encontrado en este momento. Con todo es una combinación extraña. Es cierto que el proceso de sonido es gratis pues lo hace el bloque de CD-Rom de SS. Pero la tasa de transferencia que necesita es alta, dejando la mitad o menos para el video.
B) Por parte de las Seconds/Thirds parties tendríamos dos grupos claros. Electronic Arts, con sus propias librerías de video y el resto de Third partys que usaron formatos propios u otros licenciados, como: Radical Entertainment, NEON/Ocean, Game Arts para Grandia…
1. El caso de EA:
Es curioso, porque varios de sus formatos se basan en parte, en los algoritmos de MPEG-1, para la compresión DCT. Generando vídeos con un calidad muy similar al MPEG-1 sin serlo. También en algunos usaba compresión ADPCM de EA para el canal de Audio además de PCM. Los codecs, son propietarios de EA, no los licenció a otros.
La calidad general es muy buena. El color de 8/16/24bits. Buena resolución, 15FPS y pantalla completa / ventana casi completa. Aprovechando tanto los dos SH2 como el SCU-DSP.El posible autor de semejante proeza puede que fuese Erick Kornblum, el técnico de compresión de EA en todos sus juegos de la época. Tipos de archivos y formatos:
Resolución: 320×240 a 320×200
Color Paleta 8BPP.
Audio stream 89 kbps for EA ADPCM, para PCM 354 kbps. Siempre Estéreo.
Compresión sin pérdidas para intra-frame.
Movimiento basado en bloques y VQ para inter-frames.
Sonido: PCM o EACS EA ADPCM = 22Khz 8bit Estéreo
Uso SS: 1x SH2 + M68 + SCSP-DSP + VDP1 o VDP2
VDP1 = Generalmente → Scaled o Normal Sprite 8BPP
Excepciones VDP2:
Road Rash y Soviet Strike → NBG0, 16-bit, Bitmap(512×256)
Resolución: 304×192 a 272×176
Color 24bit VDP2 (Probablemente en YUV 4:2:0)
He llegado a ver hasta cerca de 10.000 colores únicos en un frame de FIFA 98.
Audio Stream sobre 89 kbps for EA ADPCM y 354kps para PCM. Siempre Estéreo.
Fue el primero de una serie de códecs similares a MPEG utilizados por EA optimizados para la plataforma de destino. Quizás más parecido al MDEC, MJPEG.
Llegando a una cifra máxima de 228 macrobloques de 16×16. Un total por segundo a 15FPS dan 3420 macrobloques por segundo. Contra los 9000 totales teóricos de MDEC, lo cual no está nada mal.
Cada cuadro se divide en macrobloques de 16×16 píxeles, y cada macrobloque se divide adicionalmente con cuatro luma de 8×8 y dos bloques de croma de 8×8 de media resolución. Se utiliza el orden estándar de bloque MPEG 4:2:0.
Se aplica un algoritmo basado en Inverse DCT(iDCT) a cada bloque.
Sonido: Posible PCM Mu-Law o EA ADPCM = 22Khz 8bit Estéreo
Uso SS: 2x SH2 + SCU-DSP + M68 + SCSP-DSP + VDP2
NBG0 mode, 24-bit, Tile(2H x 2V), Plane Size = 1H x 1V
RES: Posible contenedor con varios streams de TGV.
STR: Posible contenedor con varios streams en TGV o TGQ/UV.
Caso especial de uso NHL 97:
2x SH2 + SCU-DSP + M68 + SCSP-DSP + VDP2(NBG0 + NBG1)
Alterna layers en 16-bit Bitmap mode 512×256
DAT: Posible contenedor con varios streams en TGV o TGQ/UV.
Caso especial de uso Madden NFL 97:
Caso especial de uso Madden NFL 98:
2. Resto de codecs de Third partys:
Game Arts MPEG para Grandia:
Tiene toda la pinta de que se basa en MPEG-1, pero no se sabe aún, que codec es exactamente. Es un codec propio de Game Arts para la versión SS. La calidad de imagen, cantidad de color y FPS es de las mejores del sistema. Y además a toda pantalla, dando un resultado sobresaliente en SS.
352×192 480i (352×179 o 176 448i)
352×144 480i (352×112 o 104 448i) En el caso de que las barras no estén en la propia imagen. En la versión de PSX están en la imagen.
En esta captura del HRAM que ha hecho el compañero @TrekkiesUnite118 podemos apreciar claramente la naturaleza IDC del codec, más cercana a como trabaja el MDEC de PS1: En este caso podemos apreciar la resolución real de los FMV en Grandia. En este caso 176×176 para canal Y, en este FMV que es casi a pantalla completa, y a la mitad en la vertical en los canales U y V: 176×88. También se puede ver un doble buffer completo para los canales Y, U y V. Posiblemente en este caso sea un espacio de color YUV 4:4:0. Para posteriormente en el resultado final de la descompresión duplicar los pixeles en la horizontal y en el caso de la vertical por 2,5 aproximadamente para rellenar la resolución de salida total de 352x448i.
Llegando a una cifra máxima de 121 macrobloques de 16×16. Un total por segundo a 12FPS dan 1452 macrobloques por segundo. Contra los 9000 totales teóricos de MDEC queda bastante lejos. Sin embargo @TrekkiesUnite118 hizo otra captura después con este aspecto:
En este caso podemos apreciar la resolución real de los FMV en Grandia. En este caso 352x176 para canal Y, en este FMV que es casi a pantalla completa, y a la mitad en la vertical en los canales U y V: 352x88. También se puede ver un doble buffer completo para los canales Y, U y V. Posiblemente en este caso sea un espacio de color YUV 4:4:0. Para posteriormente en el resultado final de la descompresión escalar en la vertical por 2,5 aproximadamente para rellenar la resolución de salida total de 352x448i.
Llegando a una cifra máxima de 242 macrobloques de 16×16. Un total por segundo a 12FPS dan 2904 macrobloques por segundo. Contra los 9000 totales teóricos de MDEC en esta hipótesis quedando mucho mejor. Sobre un tercio de total de MDEC.
Entre 7 y 15FPS. Casi seguro 12FPS. En PSX son de 12/15FPS a 320×240.
He estimado que frame rate total es de 1400kbps.
Para el Video stream 1200kbps.
Y para Audio stream 176kbps.
He llegado a ver hasta cerca de 34.000 colores únicos en un frame.
A pantalla completa entrelazado duplicando una línea cada 2 reales.
Se aprecian artefactos de compresión típicos de iDCT, en frames intermedios.
Uso SS: 2x SH2 + SCU-DSP + SCSP-DSP + VDP2
24-bit capa VDP2 layer Bitmap, puede que para calidad color MPEG.
Posiblemente ADX ADPCM versión 3. 4=16bits. 22050Hz. Sonido estéreo.
Como anecdótico comentar que Grandia tuvo un disco demo de pre-lanzamiento. En este los FMV estaban en Cinepak. A una calidad excelente:
PCM 8bit, 22050Hz, Estéreo 353 kbps,
Frame rate total de 2500kbps
Solo tres títulos y no se podía licenciar. Investigación de un usuario en la red:C’s Ware’s Lucid Motion “neo animation engine”“It’s capable of 640×360 8-bit color video at 15 FPS, has a .vid extensions and a tVid header. It seems that some of Desire’s cutscenes are actually 640×480 pixels big, but everything else is still the same as what I said above.”
Hasta 2x SH2. Sonido mono. 16Bit capa VDP2, puede que 8BPP color para vídeo. Sobre 15FPS. A pantalla completa. No se aprecian artefactos de compresión en ningún frame, ni en Key-frames intermedios.
Es un codec que utiliza paleta de color RGB. Con una calidad en frame llave e inter-frame asombrosa. 15FPS y una buena resolución 320×200. Sonido mono PCM, en este caso. Usando solo 1x SH2. Posiblemente 15 bit RGB de color, degradados muy buenos y fundidos de imagen también.
Parece que Westwood, al menos para SS, porto su codec versión 2 para el port de Command Conquer. Es un codec con una calidad muy buena para la profundidad de color que tiene. En este caso
El uso del hardware es mínimo, pero a la vez muy optimizado. Solo vemos que use 1x SH2 para la descompresión del video y del ADPCM like del audio.
No se ha ciencia cierta si el codec usado en Cyberia de SS es el codec C93 de Interplay o de la propia Xatrix. Porque los reproductores no lo reconocen como tal. También se encuentra otra extensión en esta versión la Z94. Tanto el C93 como Z94 muestran los mismos valores en mplayer. Parecidos al codec más moderno también de Interplay/Xatrix: M95.
La calidad de los FMV es muy buena. A 320×192 a 12,5FPS, 8BPP con una calidad de los degradados de color alta, teniendo en cuenta la baja profundidad de color. Usando el VDP2 para representar el video. Y sin artefactos de compresión claros. El sonido tiene una calidad aceptable. Se usa PCM. Con un bit-rate bastante contenido de 1100kbps.
Además se aprecia el uso de los 2x SH2 y señales del SCU-DSP.
Interplay parece que tenia varios codecs propios, parecido a EA. El que sé uso para Casper tiene una gran calidad, parece ser que también sé uso para Baldur’s Gate.
En este caso con una gran calidad de resolución y compresión de color. Sin artefactos visibles. Además de un gran calidad de sonido. Y un uso del sistema modesto, pero se entiende que optimizado para la gran calidad tanto de video como de audio.
RGB Paleta de 16BPP 320×224 15FPS VDP2 16BPP 2000 kbps
ADPCM Like 22050 Hz Estéreo 176,5 kbps
Estamos ante un codec que está bastante indocumentado. Pero que extrañamente está soportado tanto por mplayer como VLC, reconociéndolo ambos. Pero sin una reproducción operativa. Podemos verlo siempre en estudios Británicos, parece que el codec tenga su origen en UK, de la mano de Argonaut. Y que después está lo compartiera o lo sublicenciara.
Utiliza el VDP1 de forma directa, sin primitivas, en la mayoría de casos. Usando un espacio de color de 16BPP, posiblemente por paletas, por lo que he comprobado con GIMP. Aunque en la documentación online se habla de 8BPP. Usa una implementación del algoritmo basado en “vector quantizer” bastante sencilla. Aunque se puede decir que la calidad general es muy buena, tanto de color y artefactos de compresión. Con una buena resolución(cerca de 320×240), pantalla completa en la mayoría de casos y 15FPS. El audio es PCM en todos los casos con una calidad media. Los bit-rates suelen oscilar entre 1200 y 1500 kbps. 176 para el sonido y 1000 a 1300 para el video.
Finalmente el uso de la máquina es aceptable, usando los 2x SH2 para ello. Como hemos dicho usa VDP1 al FrameBuffer de manera directa en la mayoría de casos. Exeptuando en Hulk que usa el VDP1 con dos Distorted sprites para cada mitad del total del frame. Y en Creature shock VDP2 en modo 8bits.
Amazing Studios para Heart of Darkness SS/PC – PAF Packed Animation File:
Paleta 8BPP con resolución fija a 256×192 a 10FPS. Sonido Estéreo a buena calidad similar al PCM(PAFA) a 22050Hz. La calidad de la compresión es buena. Uso de un SH2 y signos de uso del DSP del sonido.
SGA Digital Pictures
Esta compañía ya desarrollo su codec para el Sega-CD o Mega-CD y el CD-32X. En SS podemos ver una evolución tímida del último. Con más resolución, calidad de sonido y bit-rate general al tener hasta 2x de velocidad en el estándar SS, contra el 1x del Mega-CD. Gracias ha esto aumentando la calidad del FMV, claro esta. Pero no de forma notable.Con un espacio de color fijo de 8bits mediante Paleta. Con una resolución máxima de 304×208 a 12FPS sobre el VDP2 a 8-bit. Con un bitrate de 1448kbps.Para el audio stream se usa una onda PCM de 8-bit de profundidad a 22050hz de muestreo en mono a un bitrate de176 kbps.Con un total para un segundo de 1624,3 kbps. Suficiente para entre 1x y 2x de CD-Rom de la SS.Con respecto al uso del hardware, este usa los 2x SH2 con (señalkes del SCU-DSP y SCSP-DSP) junto al VDP2 en modo 8bits.
Desconocido usado por Radical Entertainment .egg :
Estamos ante un codec realmente muy interesante por parte de Radical. Todo parece apuntar a que es un desarrollo propio. En los créditos podemos encontrar a Aaron Arndt y Jason Dorie como co-creadores tanto del Reproductor y el Algoritmo respectivamente. Y ha Aaron Holtzman como el creador original del reproductor. Ellos consiguieron un compresión verdaderamente notable, con una profundidad de 16BPP, seguramente con paletas. Ha unos 15FPS aproximadamente con una resolución máxima de 320×200 sobre el VDP2 a 16bits. Con una extensión de .egg.Con una calidad sonora aceptable. Desconocemos el codec, seguramente PCM crudo. Tanto en mono como estéreo.Obteniendo unos bitrates bastante contenido entre 1200/1500kbits/sg totales por frames al segundo. Obteniendo una calidad de color y degradados esplendida incluso en escena con mucho movimiento, sin apenas notarse los artefactos.Sobre el uso del hardware usan los 2xSH2 y el VDP2.
Desconocido usado por Gremlin .rvd:
No podido encontrar ningún rastro documentado de esta extensión. El único codec que existe documentado de Gremlin es el GDV.En los juegos de SS podemos ver en todos FMV y todos con el mismo formato. El codec parece usar una especie de VQ, dando una calidad notable en general. La profundidad de color es de 16BPP, con paletas posiblemente. Usando el VDP1 con primitivas a 15BPP. He estimado unos 15FPS por segundo en los FMV. El codec de sonido es totalmente desconocido. Posiblemente PCM, a una calidad media. Algunos streams están en mono. El uso del hardware en estos FMV es correcto. Usan los 2x SH2 normalmente.
No usa primitivas del VDP1. Por lo tanto está haciendo Render CPU al VDP1 FB directamente.La profundidad de color es de 16-bits, posiblemente con paleta. Parece 320×240 o aproximado, pues ocupa toda la pantalla sin pixelación por escalado. Parecen 15FPS mínimo, va bastante suave. El sonido es Estéreo. Desconozco el formato.El uso del hardware es realmente bajo. Solo usa un SH2 para los FMV. Posiblemente estemos ante un formato crudo tanto en la parte grafica como en el audio. A nivel de VDPs, no los usa. Directamente lo carga todo en el Framebuffer de la VRAM del VDP1.
Desconocido usado por Perfect/Tantalus en Psygnosis ports (Parece Cinepak):
Este codec es todo un misterio. Siempre me ha parecido un Cinepak modificado. Por el aspecto de los artefactos de compresión y los degradados de color sobre todo en las escenas de más movimiento o con colores más realistas. Krazy Ivan por ejemplo. En PS1 gracias al IDC el color de la piel de los protagonistas es perfecto. En imágenes estáticas la verdad es que luce bastante bien. Podríamos estar hablando de un codec que usa un espacio de color de 16bit o incluso 24-bits, si finalmente fuera un Cinepak seria 24-bits con casi toda seguridad. Y también usa algún tipo de compresión VQ entre frames. Por todo esto es el parecido con Cinepak. La cantidad de FPS es desconocida, pero no parece ser más de 15FPS de cualquier modo. De igual manera el bitrate tampoco lo podemos determinar.Pero aún más llamativo es que en ninguno de los 8 títulos de Tantulus/Perfect los FMV pasan de 288×200 aprox. Exceptuando Wipeout 2097 a 320×176. Nunca a pantalla completa.Es complicado saber más porque exceptuando Lemmings 3D todos los datos de los ports de los juegos de Psygnosis para SS fueron codificados en un archivo empaquetado. Un formato parece ser de la propia Tantalus. Hay información sobre la versión de Lemmings para 3DO que uso Cinepak de Sega para los videos.Otra hipótesis plausible es que Psygnosis para estos encargos cediese su propio codec a Tantalus/Perfect. Y que este fuese de ellos. Ya que en otros ports de Tantulus o Perfect usaron codecs de los distribuidores o contratantes principales, como en FIFA 97 para EA o Manx TT para SEGA. Usando MDEC EA Like y Duck Truemotion S respectivamente.Finalmente a nivel de sonido, destacar que la mayoría están en mono. Excepto Wipeout 2097 que si está en Estéreo. El codec es imposible de saber, posiblemente sea PCM crudo.El uso del hardware en estos FMV es irregular. La mitad usan un SH2 y la otra mitad 2xSH2. Todos usan el VDP2 en modo 16bits, NBG0 o 1. Algunos parecen que usan el DSP de sonido, pero sin seguridad de que sea para ello. Aunque se ve presencia de actividad en la unidad SCU-DSP, tampoco podemos asegurar que se usara para las FMV, o también en este caso para la transferencia PCM como en Cinepak.
Desconocido usado por Perfect/Psygnosis en Discworld.
Encontramos una variante diferente Perfect para ports de Psygnosis en estos juegos. En este caso con una buena resolución 320×200 aproximadamente. Pero con una profundidad de color de 8BPP. Pero logrando una calidad excepcional la verdad. Desconocemos también en este caso tanto los FPS, posiblemente 15, y el bitrate.El sonido en este caso es Estéreo siempre. Desconocemos el formato. Posiblemente sea un formato comprimido, por la cantidad de audio que hay en este juego.Finalmente el uso del hardware es modesto. Solo vemos el uso de un SH2 para la descompresión, el DSP de sonido en la primera parte, pero si poder asegurar que se use para esto específicamente. Y finalmente se usa siempre el VDP2 en modo 8bits.
Parece un codec bastante básico, pero no lo es. Si nos fijamos podemos apreciar artefactos de compresión 16×16 en colores puros. Pero en general los degradados y los artefactos son buenos. La profundidad de color usada es siempre 8BPP con paleta. La resolución máxima 320×240. Bastante suave a tramos, estimo mínimo 15FPS y máximo 25FPS o más.Por la parte del sonido es curioso. Parece que no reproduce un stream continuo. Si no sonidos cortos, como si de un “MIDI” se tratase.El uso del hardware es correcto. Desde el uso de un SH2 en Tilt! / Hyper 3D Pinball, hasta el uso de los dos SH2 en Mass Destruction. También podemos ver un uso del DSP de sonido amplio. Posiblemente para la parte de reproducción de estos sonidos “MIDIS”.
Es simplemente fascinante. Justo cuando estaba acabando esta sección sobre FMV. La cual me ha llevabado mucho más de lo que me hubiese imaginado. En los últimos codecs que tenia identificados como desconocidos, he detectado un patrón que se repetía. He mirado los cabezales de fichero. Y he podido descubrir otro codec más.Un codec con total seguridad propiedad de JVC. El cual da una calidad muy respetable, teniendo en cuenta su baja cantidad de color. Sin artefactos de compresión en video con movimiento o colores puros. Eso si con un Dithered muy pronunciado. Eso si regalando un frame rate estable y fluido. Todo los videos están casi a pantalla completa. Y ha 15FPS. Con una tasa de transparencia realmente baja 1200kbps aproximadamente.El formato del audio es desconocido, seguramente PCM crudo. En este caso siempre en mono.El uso del hardware es correcto. Usando hasta 2x SH2 junto con primitivas del VDP1 en modo 8BPP color bank. Cambien se puede observar el uso de SCSP-DSP durante los FMV.
Un codec con una calidad notable. Con una profundidad de color de 8bits con paleta posiblemente. Con una variación de FPS entre 15 y 24FPS. Y una resolución máxima de 320×224.Es unos de los muchos FMV que se renderizan vía CPU en el FrameBuffer del VDP1 directamente.
El formato del audio es desconocido, posiblemente PCM. Aunque se escucha muy claro. En este caso mono.
El bitrate total por frames por segundo es bastante bueno. Sobre 1500Kbits/sg aproximadamente.
En los créditos encontramos como “Cut-Scene Coders” a Patrik Patel y Phillip Trelford, posibles creadores del codec y del port a SS.
El uso del hardware es correcto. Usando los dos SH2 y con señales de uso del DSP de sonido.
Este también se renderiza vía CPU en el FrameBuffer del VDP1 directamente. Con una profundidad de color de 8BPP. A una resolución de 320×224 a pantalla complete y 15FPS aprox. Parece color RAW de 8BPP sin compresión.
Es uno de los poco FMV que he visto que acompaña con música MIDI generada por el SCSP, en este caso en Estéreo.
El uso del hardware es notable, en este caso usando 2xSH2 con señales de uso tanto en el SCU-DSP como en el SCSP-DSP
Como apunte me gustaría señalar que me ha resultado muy curioso que en tan solo una pequeñísima cantidad de casos (2,3%) de los FMV dibujados en el VDP2 se haya hecho uso de la función de Reducción/Expansión para poder escalar a pantalla completa los FMV o vídeos que no llegaban nativamente a la resolución máxima.
Más aún en los casos de EA MPEG-Like o Duck a 24bit de color. Algo que en principio era totalmente posible por el VDP2.
Gracias al compañero de los foros SegaExtreme, hemos podido comprobar que era totalmente posible. @paul_met ha preparado un hack para que los videos se escalen al máximo. Y el resultado es notable al verse, ahora si, a toda pantalla. En este caso además se suma que se está reproduciendo a 352×256, cuando la resolución más optima era 320×256. En la siguiente imagen podéis ver el resultado. Sin hack (Izquierda) y con hack (Derecha):
Lista cronológica de juegos por Codec y uso de la SS:
Detalles en casos curiosos o destacables (más datos en la tabla).
16bits 22254 Hz Estéreo 712 kbps
Magic Knight Rayearth ← Alta calidad compresión y color
16bits 22254Hz Estéreo 712 kbps
Strahl – Himerareshi Nanatsu no Hikari ← Alta calidad compresión y color
352×224 30FPS 1800kbps VDP1. Calidad media/alta.
Buena calidad de sonido PCM a 22,254KHz, 356kbps, 8bit y Estéreo.
2xSH2 + Señales de SCU-DSP.
16 bits 22050 Hz Estéreo 706 kbps
Dragon Force ←Alta calidad compresión y color
22050 Hz Estéreo 706 kbps
Return Fire ← Alta calidad compresión y color
Shockwave Assault ←Alta calidad compresión y color
16-bits 22050 Hz Estéreo 706 kbps
16-bits 22254hz Estéreo 712 kbps
PriCla (Princess Clara) Daisakusen←Alta calidad compresión y color
Shining the Holy Ark ←Alta calidad compresión y color
8bits 22050 Hz Estéreo 353 kbps
22050 Hz Estéreo 352 kbps
DoDonPachi ← Alta calidad compresión y color
Arcana Strikes ← Alta calidad compresión y color
Slayers Royal ← Alta calidad compresión y color
Tasa: 22050 Hz Mono 353 kbps
Uso de la función de Reducción/Expansión VDP2
NBG0 24-bit + Transparencia VDP1 ←No comprobado. Visto en videos.
Rockman X3 ← Alta calidad compresión y color
Lifescape – Seimei 40 Okunen Haruka na Tabi ← Muy mala compresión y color
Mahjong Taikai II Special ← Alta calidad compresión y color
Tasa:16bit 22050 Hz Estéreo 706 kbps
Tengai Makyou – Daiyon no Mokushiroku – The Apocalypse IV ← Alta calidad compresión y color
Rockman 8 ← Alta calidad compresión y color
22254 Hz Estéreo 356 kbps
Assault Suit Leynos 2 ← Alta calidad compresión y color
Kidou Senkan Nadesico – Yappari Saigo wa Ai ga Katsu ← Alta calidad compresión y color
PCM 22050Hz 16bit Estéreo
Thunder Force V ← Alta calidad compresión y color
Resident Evil← Alta calidad compresión y color
8bits 44100 Hz Estéreo 705 kbps
Rockman X4 (Mega Man X4) ← Alta calidad compresión y color
8 bits 22050 Hz Estéreo 353 kbps
Layer Section II ← Media-Alta calidad compresión y color
Shining Force III ← Alta calidad compresión y color
Tasa: 22050 Hz Estéreo 352 kbps
My Fair Lady Virtual Maajan ← Alta calidad compresión y color
22050 Hz Estéreo 705 kbps
8-bits 44100 Hz Estéreo 706kbps
Slayers Royal 2 ← Alta calidad compresión y color
Devicereign (1999-01) ← Alta calidad compresión y color
ADX 22050 Hz Estéreo
Tasa: 22050 Hz Estéreo 200 kbps
Tasa: 44100 Hz Estéreo 352 kbps
Menú con fondo video:
44100 Hz Estéreo 267 kbps
Sound Novel Machi (1998-01) ← Alta calidad compresión y color
Tasa: 22050 Hz Estéreo 178 kbps
22050 Hz Estéreo 177 kbps
22050hz Estéreo
22050hz Estéreo 177 kbps
Nanatsu Kaze – No Shima Monogatari ← Alta calidad compresión y color
44100 Hz Estéreo 354 kbps
THE STAR BOWLING Vol.2 ← Alta calidad compresión y color
Lupin the 3rd Pyramid no Kenja ← Alta calidad compresión y color
Contra – Legacy of War ← Alta calidad compresión y color
Vandal Hearts ← Alta calidad compresión y color
3D Baseball ← Alta calidad compresión y color
ADPCMDK4 44100Hz Estéreo 354 kbps
Off World Interceptor Extreme ← Alta calidad compresión y color
Ghen War ← Alta calidad compresión y color
Gex ← Alta calidad compresión y color
Titan Wars (E) / Solar Eclipse (U) ← Alta calidad compresión y color
The Horde ← Alta calidad compresión y color
GunGriffon ← Alta calidad compresión y color
Slam ‘N Jam ’96 featuring Magic & Kareem ← Alta calidad compresión y color
ADPCMDK3 44100Hz Estéreo 266 kbps
Pandemonium! ← Alta calidad compresión y color
304×200 15FPS 457 kbps
All-Japan Pro Wrestling Featuring Virtua ← Alta calidad compresión y color
Estéreo 22050Hz
Enemy Zero ← Alta calidad compresión y color
Riven: The Sequel to Myst ← Alta calidad compresión y color
22050 Hz Estéreo 178 kbps
Tasa: 44100 Hz Estéreo 354 kbps
Mr. Bones (1996-10) ← Alta calidad compresión y color
3D Baseball (1996-11) ← Alta calidad compresión y color
44100 Hz Estéreo 266 kbps
Fighting Illusion K1 Grand Prix ← Alta calidad compresión y color
Sonic 3D Flickies’ Island ← Alta calidad compresión y color
MP2 224kbps 44100Hz Estéreo
MP2 192kbps 44100Hz Estéreo
Need for speed →320×240, Estéreo
Madden NFL 97 →320×240, Estéreo
Space Hulk: Vengeance of the Blood Angels →320×240, Estéreo
PGA TOUR 97 →320×240, Estéreo
TGQ – Software basado en MPEG-1:
Andretti Racing → 304×192, Estéreo
Crusader: No Remorse → 272×176, Estéreo
NBA Live 97 → 304×192, Estéreo
Battle Stations→ 304×192, Estéreo
Darklight Conflict→ 304×176, Estéreo
Warcraft II: The Dark Saga → 304×144, Estéreo
Nascar 98 → 304×192, Estéreo
UV(TGQ) – Software basado en MPEG-1:
FIFA 97 → 304×192, Estéreo
NBA Live 98 → 304×144, Estéreo
FIFA 98 → 304×144, Estéreo
NHL 98→ 304×144, Estéreo
Posibles formatos contenedores de varios videos:
Posible TGQ:
Posible TGV:
Game Arts basado en Software MPEG-1:
24BPP 352×192 480i (352×179 o 176 448i)12FPS?
ADX ADPCM 22050Hz Estéreo
ADX ADPCM 22050Hz Estéreo.
PDQ2 Varios estudios Ingleses – .AVS:
Desconocido usado por Radical Entertainment .egg:
Desconocido usado por Digital Pictures
Desconocido usado por NMS .PAT
VDP1 8-bits color 320×240, 8 BPP Video pantalla completa Normal sprite 8bpp replace, muy suave, posible 25FPS
Cabecera dmpwe
VDP1 Render CPU to VDP1 FB directamente
El bitrate total 1500Kbits/sg
8BPP 320×224 15FPS aprox, Parece color RAW sin compresión.
Música MIDI Estéreo
2xSH2 SCU-DSP señales. SCSP-DSP
Finalmente, ahora si, nos quedamos con tres grandes títulos para ilustrar este punto del análisis:
Juego de la segunda ola de desarrollos Second Parties de SEGA, lanzado el 1996-03-07. Y quizás para muchos este es sea un titulo mediocre dentro del catálogo de SS. Y no les falte razón. Con todo opino que existiendo argumentos para ello, creo honestamente que los desarrolladores crearon un juego interesante para el catálogo, original e innovador. Pero que el resultado final quedo inacabado o a falta de pulir en su conjunto. Con un diseño del arte y en general irregular y muy heterogéneo. Dando la sensación de no saber donde iban con el mismo.También es cierto que el recorrido del estudio Jumpin’ Jack Software fue bastante irregular. Hicieron un juego por año desde el 1995 al 1997. Este fue su segundo desarrollo, en el cual ya vemos una notable evolución con respecto a su primer titulo. Bajo mi punto de vista, evolucionaron su engine 3D(que es básicamente el mismo que el anterior) y su conocimiento. El cual parece que tiene un sistema de generación de terreno por mapa de alturas y tileado. Pero en este añadieron armas en 3D e iluminadas con fuente, realmente espectacular. Además de objetos 3D en el escenario e iluminación en los mismos con fuente. Es cierto que en este los enemigos pasaron a ser 2D contra los 3D del anterior. Aunque aún tenían mapas grandes y abiertos en algunas zonas pero ahora con más detalle y variedad que en el anterior. Con un uso en general tanto del VDP1 como del VDP2 notable, usando el VDP2 de manera extensa. Usando las transparencias del VDP1 y del VDP2 de forma inteligente. Ya desde su anterior juego hacen un uso del Gouraud muy bueno y repiten aquí el uso para el escenario y para el Depth cueing. Pero por contra y aun con un rendimiento final en FPS bajo. 20FPS para la cantidad de geometría en pantalla, sobre 700 quads vistos y unos 1000 calculados, se antoja poco para las posibilidades reales de la SS.
Realmente es sorprendente que con un equipo bastante fijo y con un tamaño suficiente(3 programadores a veces 5 y 2 diseñadores). Donde parece que la persona destacada fue Robert Leyland. Sorprende pues que no fueron capaces de mejorar el rendimiento o conseguir productos más pulidos. Incluso todo apunta a que recibieron bastante soporte de SOA. No se, tampoco quiero quitarle merito a su trabajo y los problemas que seguro tuvieron.
Con respecto a los FMV primero me gustaría destacar que ha sido muy complicado para mi decidirme por el mejor Duck de todo el catalogo. Estuve dudando hasta el final entre este y Titan Wars, Gungriffon o su anterior juego Ghen War. Todo ellos con unos FMV magníficos, con unos colores y detalle increíbles. Pero el que nos ocupa es el top. Máxima resolución junto a un gran sonido. Y una calidad de color y detalle excepcional. En los créditos aparecen como artífices tanto el ya conocido Eric Caplain/Ameres, seguramente por la autoría del reproductor, y Katy Weathers. Posiblemente esta ultima la artífice del video, pues Eric en el canal de Discord de Segaxtreme nos dijo “no recordar que él hiciese este”. Con todo gracias a la suma de ambos tenemos este gran logro técnico en la máquina:
24-bits color 320×196 15FPS 1498 kbps
VDP2 NBG0 Tile(1H x 1V) Plane Size = 1H x 1V
ADPCM–DK4 22050Hz Estéreo 177 kbps
Con picos de transferencia totales mínimos de 1000-1500 y máximos de entre 2000-2600. Realmente impresionante.
Finalizamos con el repaso general al uso del hardware que hace este juego. Usa un modo SD a 320×240 en 16BPP. Usando la dupla de SH2 tanto para el 3D como para los FMV. Y mostrando señales de uso del SCU-DSP de un 20% de media tanto en registros como memoria. Posiblemente para la transferencia de datos entre buses. También hay señales de uso del DSP de sonido tanto en FMV como en el juego hasta un 35% de la memoria. Posiblemente en el caso de juego para el audio del CD-ROM. Desconocemos para que exactamente en los FMV. Para acabar podemos ver un uso del 70% de uso de la RAM principal, un 65% de la VRAM del VDP1 y un 72% del VDP2.
He dudado mucho para seleccionar el mejor “Cinepak”. Principalmente entre este Wachenröder y Lunar 2 o Baroque.Lunar 2 posee más FPS con una calidad inferior en el audio y el tipo de imagen es menos exigente a ser principalmente anime. Baroque se parece más a Wachenröder, y tiene incluso más resolución, igual FPS y mejor calidad de audio. Pero la imagen es monocroma en su mayoría o con menos exigencia que en Wachenröder. Como digo cualquiera de estos tres seria otra buena elección.También es cierto que en Cinepak más PCM(incluso con ADPCM) también hay grandes ejemplos. Pero gracias a ADX permitiendo ese extra de ancho de banda para el stream de video hacen a este conjunto superior al resto.
Pero vayamos al juego que nos ocupa. Wachenröder fue un lanzamiento exclusivo de la 4ª ola de desarrollos en Japón en el 1998-08-06. Como es lógico ya con todo este recorrido y además en este en particular Wachenröderes un juego sobresaliente, pero sobre todo en la parte de arte. Bajo mi punto de vista en el arte está en la liga de Final Fantasy o Panzer Dragoon. Incluso, bajo mi punto de vista por encima, ligeramente por encima de Grandia o Shining Force. En serio el nivel de detalle, la mezcla entre medieval y barroco. Oscuro y cyberpunk es tremendamente seductor. Pena que el equipo no tuviese un budget al nivel de Squaresoft, porque este JRPG hubiese podido rozar un nivel muy superior. Aún más pena que no saliese de Japón. Estoy convencido de que con un budget como FF, los gráficos, rendimiento y contenido final hubiesen llegado a ese nivel, si no rebasarlos.
Siendo un encargo de SEGA, que se hizo con tres equipos. Recayendo la parte técnica sobre TNS Co. Ltd, y siendo honestoseste fue un equipo bastante modesto, si lo comparásemos con el de un FF o incluso el de Panzer Dragoon Saga o Grandia como equivalentes: 2(+1 de apoyo) programadores y 3 artistas. Sin contar toda la experiencia y solera que ambos equipos tenían, frente a un equipo que prácticamente hizo su primer juego. En fin, como se suele decir: “Hicieron lo mejor que supieron y pudieron”. Donde notamos esta falta de recursos precisamente es la simpleza de los combates 3D o incluso en el mapa 2D/3D. Con grandes ideas y diseños, pero que se quedan a medio camino. Por ejemplo los combates 3D son realmente espectaculares. Los modelos tienen un cantidad de polígonos alta y muy detallados. Las animaciones también son muy buenas, motion capture en este caso. Todo con una iluminación dinámica muy lograda con fuente. Usando el VDP2 también de forma bastante lograda. Ahora las malas noticias, el rendimiento es bastante pobre, estamos hablando de en el mejor de los casos 20FPS pero bajando frecuentemente a 14 o menos FPS cuando se ejecutan los ataques o las magias. El ajuste de los fondos de VDP2 con el 3D o el suelo 3D del VDP2 deja mucho que desear. La mayoría de modelados son muy buenos, otros la verdad es que son bastante feos, igual con algunas animaciones que no son de motion capture sino tradicionales. En los combates he llegado a ver un máximo de 800 quads vistos e iluminados, puede que unos 1200 calculados en total. Cifras altas, pero que podían a ver dado como resultado mayor estabilidad o estar cerca de los 25FPS como el sistema ha demostrado en otros juegos similares. El uso de la transparencia es muy bajo. Se usa algo al del VDP1 para los mapas 3D para el cursor 3D en forma de diamante, siendo esta inútil contra el resto de elementos del mapa al estar en color bank, solo viéndose efectiva la transparencia con errores de redibujado sobre el propio diamante en 3D. En el resto y sobre todo en el modo batalla 3D se usa el modo mesh. Se usa la transparencia de VDP2 en los menús de pausa en el mapa 3D y parece que para “algo” en el plano rotado infinito para el suelo en el modo batalle 3D, pero no he visto para que. Quizás para el fundido de entrada al modo batalla 3D.
Hablemos ahora de sus FMV. Como hemos dicho este usa la variante de Cinepak .cak. Conocida en la última etapa de la vida de SS, en Japón sobre todo. La intro en concreto es increíblementebonita y la calidad de la compresión y color es excelente. A pantalla complete pixel perfect ratio. Realmente cuesta ver en gran parte de su metraje los problemas de compresión típicos de Cinepak. Los FPS son justos 15FPS, pero apenas se nota. Y la calidad de sonido está justo en límite y se escucha muy bien.
ADX ADPCM / Estéreo / 22050hz / 176 kbps
Con picos de transferencia totales máximo de 2600 kbps.
Ahora hablemos de como usa la maquina. Como hemos dicho ha estas alturas, el uso de base de SS ya era muy alto. Podemos ver el uso de los 2xSH2 tanto para el 3D como para los FMV. También podemos señales de uso importantes en el SCU-DSP tanto en 3D como FMV llegando al 70% de memoria y 18% de registros. Vemos el uso del driver 2.2.0 del SCSP. Además de un uso de ADX en forma multistream tanto para los speech como para la música, adema de para los FMV. El uso del DSP de sonido llega a los 80% de uso de la memoria para ello, quizás para efectos de reverberación u otros, pero no he conseguido identificarlo. Para acabar el uso de la máquina es notable. Se usa aproximadamente el 75% de la RAM principal. El 75% de la VRAM del VDP1. Un 75% de la VRAM del VDP2 y un 95% de la CRAM. Esto último lo podemos ver porque la mayoría de texturas del VDP1 están en modo color bank. Supongo que para igualar la paleta de color entre los elementos 3D y los 2D fácilmente. Y de regalo en este juego he calculado aproximadamente el uso de memoria del M68x en este caso de un 45%.
Siendo un juego de finales de la 3ª ola principios de la 4ª, de parte de una Third party japonesa. Estamos ante un producto con una calidad abrumadora. Además viniendo de Game Arts que posiblemente sea una de las desarrolladoras que más conocimiento y resultados obtuvieron con la SS. Y todo ello se plasma en este Grandia lanzado el 1997-12-18.
Es sencillamente una salvajada. Lo que cada uno de los programadores lograron en cada uno de los espacios diferenciados en el juego es increíble. Así podemos diferenciar: Mapa 3D, 2D y menús. Batalla y UI menús. Y finalmente los FMVs.
El mapa 3D es una combinación perfecta del uso del VDP2, para los suelos y fondos, más el uso del VDP1. Hay iluminación plana por paletas pero extremadamente suave en los cambios de tonalidad. La paleta de color es rica y la correspondencia entre los dos VDPs perfectos. De alguna forma usando el color LUT del VDP1, el programador a usado los mismos colores que para los gráficos del VDP2.
Además tener color LUT le ha permitido poder usar la Semi-transparencia del VDP1 sin problema, de forma inteligente en elementos billboard. Solo en unos cuantos usando el modo mesh, extrañamente en algunos, bajo mi punto de vista podría a ver usado la semi-transparencia. Sobre todo en elementos dentro de las casas como elementos de iluminación o humo. Por supuesto, están usando la transparencia del VDP2 mediante elementos VDP1. No es así para las sombras de los personajes, ya que estas pasan encima de elementos VDP1 y 2 indistintamente, y encontrar una solución validad es aún más complicado. Es un problema bastante común en la máquina, por ejemplo en Sonic R sé opto por usar el modo mesh. Es cierto que idealmente seria utilizar la transparencia adecuada según sé este encima del VDP1 o del 2, pero esto seria complicar sobre manera tan solo para esto. O usar ambas transparencias activadas a la vez, sin ser ideal porque siempre se vería los datos de fondo el VDP2, pero siempre seria transparente contra algo.
El mapa 3D corre la mayoría del tiempo a 30/25FPS con bajadas puntuales a 20FPS cuando muestra planos amplios de las localizaciones. No podido cuantificar la cantidad de quads en pantalla. Las Batallas a 30FPS totalmente estables.Las cargas son rápidas y transparentes, gracias en parte al gran uso de la banda sonora. Que gracias al uso del la tecnología ADX permite cargar contenido y seguir reproduciendo música sin cortes. Game Arts en Grandia hacen un uso esplendido de ADX, tanto para el juego en su banda sonora en estéreo y gran cantidad de diálogos en mono. Por supuesto en los FMV. Como curiosidad comentar que Game Arts es una de las pocas desarrolladoras que tiene su propio driver para el SCSP, que en este Grandia también está usando.
Las Batallas, en 2D. Son increíblemente fluidas y espectaculares. La transición hacia ellas es instantánea con una transparencia a toda pantalla usando el VDP2. En estas podemos ver el grado de maestría y de locura con el que el programador del equipo de Game Arts las ejecuto. Para poder tener una buena cantidad e transparencias a toda pantalla y con superposición entre todos los elementos. Y que no penalizaran en el rendimiento. En este modo solo se usan transparencias del VDP2 en todas sus formas posibles. En todo momento esta transfiriendo los sprites de los personajes o de la UI del VDP1 a la capa NBG1 del VDP2. Además en el VDP1 deja los elementos de la UI con color plano para que actúen como mascara con una prioridad más alta para que los elementos transferidos al NBG1 de una prioridad más baja tapen lo que deben, en este caso los gráficos de la UI. Por otra parte cuando se produce algún efecto de partícula este se dibuja en el VDP1 y se usa la transparencia de VDP2 mediante la función de color ratios y prioridad para mezclar contra el resto de elementos, en este caso la capa NBG1 y la capa RBG0 el fondo. El fondo es una imagen de 512×512 a 8 bits de color. A ambas capas se les aplica paneos y zooms para mostrar la accion que ocurre. Mientras los elementos transparentes realmente dibujados en el VDP1 para ser usados por el VDP2 se mueven(zoom o paneos sincronizados) en el mismo VDP1. A su vez los gráficos, tanto del VDP1 como del VDP2, están simulando el efecto mesh en ellos mismos. Para poder mezclar en sus partes “más transparentes” contra los elementos que están debajo. Este mesh es incluso más permisivo para funcionar entre elementos ya que no está fijo en la parrilla de la pantalla, sino que estos huecos están en la propia textura. Para otros elementos 3D se usa el mesh del VDP1 como en el anillo de selección de acciones. Por último para los menus de magias, items… se usa la capa NBG3 con la transparencia por ratio tradicional del VDP2, dando ese punto de fundido dinámico entre menús y durante la acción. Está misma también se usa para el fundido de estadísticas al final del combate.
A nivel de resolución la mayoría del juego corre a 352×224. Exceptuando los mapas 2D y las FMV. Los primeros están en HD a 704×448, con una definición extraordinaria. Los segundos están a 352×448, VDP1 en SD en X y en “Y” en Entrelazado del VDP2.
Con respecto a los FMV y su codec, no puedo asegurar que estemos ante el mejor codec de video del sistema, porque no he podido corroborar sus capacidades. Pero todo apunta a ello. O estará muy cerca del codec MPEG de EA. Ambos codecs son autenticas proezas técnicas para el sistema y para su momento como tales. Como ya he descrito antes los FMV corren en modo entrelazado y gracias al trabajo de @TrekkiesUnite118 y otros vemos hasta donde llega este. En teoría 352×192 a 12FPS con algoritmo IDC espacio de color YUV, más el canal de audio en formato ADX ADPCM en Estéreo. Todo ello sobre el VDP2 en una capa a 24bit de color.
De nuevo gracias a @TrekkiesUnite118 y su traducción. Un titánico e indescriptible trabajo. En serio, lo que ha hecho es algo demencial. Eso pone de manifiesto la increíble comunidad fan y la calidad de la misma. Yo solo los puedo calificar como genios. Gracias a esta y a la mejora de los emuladores con base Yabause(YabaShansiro y Kronos) he podido analizar esta pieza de ingeniera y de arte para nuestra querida máquina.
Finalmente el uso del hardware, como es logico es absoluto. Se usan todos los procesadores, incluso adivino que el SH1 en este juego esta trabajando de lo lindo. Pues esta constantemente cargando información del CD. Pero los datos contrastados son. Uso de los 2xSH2 en todo el juego: 3D, 2D y FMV. Uso patente del SCU-DSP durante el juego y los FMV. Presumiblemente para la descodificación del ADX o la transferencia de datos de audio al SCSP. El uso aquí es de un 97% de la memoria y un 60% de registros, de los más altos que he visto. Se ve un uso del SCSP-DSP de hasta un 90%, posiblemente para efectos de reverberación y echo. Se usa casi un 70% de la RAM principal. Casi un 90% de la VRAM del VDP1. Y un 65% del VDP2. En este caso el M68x presenta también un 45% del uso de su memoria.
Además como plus, en este transito de profundizar en la SS, he podido descubrir una función especial que hubiese ayudado a suavizar el escalado en estos vídeos a pantalla completa. Que en la documentación la podemos encontrar nombrada de hasta tres formas distintas: Función de Calculo de color Avanzado de “Gradation / Boken / Blur”.
Este efecto es muy sutil, y es difícil de percibir. Ya que lo que hace es suavizar solo en horizontal 3 pixeles a izquierda del original. En el fondo es como si estuviese superponiendo con un nivel de transparencia tres veces la misma información desplazada a la izquierda +1 y +2 píxeles más el original. Por eso es un efecto que está limitado a una resolución normal y a un modo de color especifico para que pueda entrar todo en la VRAM y las funciones de color del VDP2.
@vbt de SEGAextreme hizo hace años una demo con esta función casi desconocida en su uso en el catálogo de SS.
Hay algún juego que lo usa, estamos hablando de un ínfimo 0,93% del total de juegos:
En los FMV. Si funciona, en principio. Difícil de ver.
En los fondos. Si funciona, pero extraño.
En menús y juego 3D en el HUD transparente y pausa. Pero no funciona porque el Mode Color esta a 1, es incorrecto debería ser 0.
← Sega Saturn al límite (II)
2 comentarios para “Sega Saturn al límite (III)”

References: Resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución