Aviso entrada muy larga. En esta entrada he usado mucha información, compleja y en algunos aspectos poco precisa. Es posible que haya cometido errores de interpretación o entendimiento. Procurare corregir todo aquello que surja.
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
5. Lo complicadísimo: Transparencias y/o Semi-Transparencias
El mito por antonomasia en SS, ¿Puede o no puede hacer transparencias por hardware como la PS1? La respuesta como en todo, en la documentación oficial.
Y hablando de documentación oficial. Sin menospreciar el inmenso trabajo que hay detrás de esta. ¡Cuidado! Los documentos tanto del VDP1 como del VDP2 están llenos de incorrecciones gramaticales y errores. Si ya de por si los VDPs son complejos, algunas características más complejas son más difíciles de entender por estos problemas en la documentación oficial
Sigamos, pero antes echemos un vistazo a la competencia en esta característica.
Las transparencias en la competencia
Leyenda: A= Primer plano / Origen ; B= Fondo / Destino
Atari Jaguar
La GPU de la Atari Jaguar era totalmente programable. Podría hacer cualquier cosa, en teoría incluso alpha real. Si puede manejar espacios de color con canal alpha, que lo desconozco, en teoría si maneja palabras de 32bits y sus procesadores lo son, debería poder procesar ARGB5555 o ARGB8888 por ejemplo.
He visto varios juegos que lo hacen. En 3D solo Club Drive en los cristales. En 2D en varios juegos. Efectos de Luz y sombras. Pero el resultado, bajo mi entendimiento, es aún más lento que 3DO, SS o PSX. Quizás por esto se usaban poco o nada en 3D.
Jaguar no tendrá problemas para el efecto ni por la forma de rasterizar ni por el framebuffer, que también es único.
3DO
Tiene el Modo-P es un modo o característica totalmente programable, el cual necesita un modo 16bit sin codificar o 6bit codificado. ARGB1555 y el segundo una combinación de MSB+unused+9+unused+5.
El modo-P también se configura análogamente a PS1 y SS con el MSB, el bit 15.
El Modo-P es muy potente en su etapa de modulación o pre-mezcla(es parecido al VDP2) pudiendo elegir hasta 7 valores de ratio de transparencia en la capa superior y/o inferior. Pero en algunos aspectos superior pudiendo seleccionar el origen(primitiva/framebuffer), destino(zero/valor constante(0…32)/framebuffer/primitiva) o modos de pre-mezcla y combinarlos. También incluso superior a la GPU de PSX por todas las posibilidades que ofrece. Pero por contra es muy lento. Se puede usar la pre-mezcla multiplicativa del Brillo/Intensidad para obtener los ratios por pixel, Teóricamente hasta 32 niveles al ser ARGB1555. O la división para efectos de sombra.
En la etapa de mezclado y simplificando hay 3 grandes modos A+B, A-B y A[XOR]B más estos dividiendo opcionalmente por 2. Que harían 6. Sin contar que se pueden invertir los valores A y B, como en el VDP2. En realidad muchos más por las combinaciones posibles.
Además 3DO comparte con SS que sus primitivas son “quads” o sprites distorsionados. Pero la 3DO lo hace de una manera completamente diferente. Más compleja y lenta por una parte. Pero más precisa por otra. Me explico. La GPU de la 3DO rasteriza en 3 pasos. El primero dibuja el elemento en el espacio de forma ordenada por profundidad y de igual manera que el VDP1 de la SS. Después lo proyecta y finalmente aplica los efectos. Así cuando dibuja un sprite distorsionado finalmente en la proyección que se dibuja línea a línea horizontal(como la PS1) desaparece el problema de redibujado de pixeles que sí aparece en SS. O eso debería ser en teoría porque en el transcurso de esta investigación me topé con esto:
Como podéis ver son errores de redibujado en la sombra. Es el Samurai Shodown de 3DO, cuando el zoom está alejado surge este problema. Me parece curioso, quizás en algunos escenarios la solución de 3DO también generaba problemas similares a SS.
Volviendo a la comparativa, SS hace todo en 2 pasos, como la PS1. Es más rápida, pero menos precisa como decimos en parte, a pesar del problema que he visto en Samurai Shodown. Eso sin contar que la 3DO tiene un buffer final y único. Lo cual le permite mezclar todo como la PS1 o la Jaguar.
Por último, aunque sé un poco fuera del tema, creo que 3DO a pesar de no tener Gouraud por hardware, podría ser simulado con una pequeña parte por software y el resto con motor de matemática de color. Le resultaría caro, como la transparencia. Pero seria posible por lo potente que es.
PS1
Puede hacer cuatro tipos de mezcla 1*A+1*B, 0.5*A+0.5*B, 0.25*A+1*B y 1*A-1*B. Y estos valores sumados a los de Brillo/Intensidad pueden obtener un blend como el “as is” o la función de cálculo Normal o primer blend de la Extendida del VDP2. Es válido para cualquier tipo de configuración de color ARGB1555. En PS1 los valores A y B no se pueden invertir, son fijos, como en el caso del VDP1 de la SS.
En algunos aspectos la GPU de PS1 funciona parcialmente de manera similar al VDP1/VDP2 jugando con el valor MSB para activar modos de cálculo de color avanzados. En el caso de PS1 el MSB es su STP y que es el equivalente en el VDP1 SDP, pero que es un registro a parte, que en ambos sirve para decir si la primitiva tiene o no máscara de color(negro puro en ambas consolas). Con la combinación del STP más una función/registro llamada SetSemiTrans(), se obtienen los modos de Semi-Transparencia en PS1.
PS1 en su etapa de modulación o pre-mezcla procesa la transparencia solo de forma multiplicativa a 16BPP(ARGB1555) y con una mezcla final aditiva con 32 ratios efectivos de brillos a ser usados. PS1 rasteriza por línea horizontal en 2 pasos así cuando aplica su algoritmo de transparencia no tiene ningún problema de redibujado, en principio. Si los elementos no están bien alineados en los vértices, por ejemplo error de precisión del GTE. Es posible que exista redibujado en los extremos. Pero poca cosa comparada con SS.
Finalmente, como ya he comentado PS1 tiene un buffer único, así que no tendrá problema para mezclarlo todo. Con una penalización de uso entre 2 y 3 veces más que un pixel opaco.
¿Alpha Blending REAL? NO
Pero antes de seguir quiero extenderme en aclarar primero de todo. ¿Qué es el “Alpha blending”? Porque ni tan siquiera yo lo había tenido realmente claro durante todo este tiempo.
Este efecto que tanto nos llama la atención y tan espectacular ha sido siempre, para mí y todo el mundo.
El principio matemático fue instaurado en el 1984 por los ingenieros Thomas Porter y Tom Duff de Lucasfilm en el SIGGRAPH’84.
Leyenda: src = Origen ; dst=Destino ; out=Resultado ; A=alpha 0≤alpha≤1 ; RGB=Valor de color por pixel y canal
Fórmula general para Alpha blending Real:
Fórmula para el Alpha blending Real cuando el fondo es opaco:
Fórmula para Alpha Blending Real premultiplicado:
Fórmula para Alpha Blending Real premultiplicado cuando el fondo es opaco:
Llegados a este punto dejar claro que ninguna máquina con implementación de transparencia por hardware de aquel momento hacia transparencia alpha real. Pues no manejaban formatos de color con canal alpha RGBα. Manejan espacios de color ARGB1555 para el 3D con una especie de “alpha premultiplicado” o “chroma key”.
“Alpha Blending” en estas máquinas.
El Alpha Blending en estas máquinas se procesa en dos etapas: la modulación por ratios alpha y el mezclado final o Matemáticas de color.
La modulación por ratios alpha
Podemos decir que tanto la 3DO, como la PS1 y el VDP1/VDP2 hacían Alpha blending con ratios alpha fijos. Lo cual les permitía hacer Semi-Transparencias directas sin información adicional en los colores de las texturas o en los polígonos planos.
Con información adicional nos referimos a interpretar los valores máximos de brillo en cada pixel, para así preasignar un valor alpha en cada uno de estos pixeles. Estos pixeles “premultiplicados” con intensidades más oscuras que actúan como grados de transparencia. Dando ese acabado suave en los extremos de los degradados donde se desvanece el color.
Estos serán “interpretados” después de la primera etapa, que es la modulación. Esta añadirá o quitará % de transparencia sobre toda la primitiva. Quizás la 3DO o la Jaguar puedan hacerlo incluso a nivel de pixel. Pero tanto la PS1 como el VDP2 de la SS lo hacen sobre toda la capa o primitiva.
La etapa de modulación normalmente y según la fórmula conocida del alpha blending es multiplicativa. Vamos una multiplicación de valores comprendidos entre el 0,0 y el 1,0.
En el caso de la 3DO está disponible la multiplicación y división. En el caso de la PS1 sola la multiplicación.
Y en el caso de la SS en su VDP1 es una especie de “división” y en el VDP2 de la multiplicación por una parte y también una especie de “división” por otra. Pongo “división” porque en estos casos lo que hace el hardware es hace un “shift” o “offsets” de los valores en sentido negativo, usados en las funciones de sombra.
No deja de ser curioso como SEGA implementa una tecnología para el efecto de Sombra que parece que lleva utilizando desde el 1986. E incluso en Mega Drive. Pero no implemente el efecto de highlight que también usaba ya en estas fechas 1989 en el VDP1 para conseguir un blend con más luminosidad.
Sobre los valores alpha podríamos decir como conclusión, que los valores alfa para “el origen” y “el destino” en los casos de 3DO, PS1 y SS VDP1 son valores fijos. Y en el caso de la 3DO, PS1 y del VDP2 sumados a los “interpretados” del brillo/valor de los pixeles/pattern/patrón origen.
En el caso de los alphas fijos en la 3DO hay disponibles hasta 7+”2”, en el caso de la PS1 hasta 4+»2″ valores y en el caso de la SS tan solo 1+”2” en el VDP1. Teniendo en cuenta como alpha fijos los valores posibles de “máscara” de 1bit disponibles en todos los sistemas: apagado o encendido.
Por otro lado en el caso de la SS en su VDP2 se pueden asignar hasta 32+”2” valores fijos. Podríamos decir que los Screens del VDP2 siempre tendrán una especie de “canal alpha de 5bits”. Y además de aplicar la fórmula completa para dos elementos, el VDP2 puede mezclar hasta dos capas con valores “alpha” contra un tercera opaca. Lo que hacen tres elementos. Incluso puede una 4 mezcla, pero es un tanto especial y limitado, no comparable a un caso general.
En el caso de los valores interpretados en la 3DO debería poder llegar a los 32, en el caso de la PS1 también 32 valores. Mientras en el caso de la SS hasta 2 en el VDP1. En el VDP2 hasta 32 si lo procesa internamente y con hasta 8 simultaneas de un total de 32 disponibles si lo hace en conjunción con el VDP1.
Como vemos ninguna máquina hace Alpha blending real. La que más aproximado lo hace es el VDP2 con sus 32 ratios fijos configurables más la capacidad de interpretar el brillo en los pixeles.
El mezclado final o Matemáticas de color
Normalmente y más usado es el aditivo/suma. Lo cual nos lleva a la duda del punto anterior, ¿Cómo conseguían interpretar o mezclar suavemente estas partes más oscuras o “pre-multiplicadas”? Quizás la 3DO puede interpretar el dato extra por pixel con alguno de sus modos. Pero tanto la PS1 como el VDP2 de la SS lo hacen de forma sencilla. En la etapa final de mezclado, después de la modulación, con sus modos de mezcla aditivos. Así pues al sumar un valor oscuro en el pixel de origen sobre un valor claro sobre un pixel de destino el color resultante será aún más claro. Quedando oculto el negro y dando fruto a nuevo color mezclado.
Por otra parte tanto 3DO como PS1 tenían algún modo más.
En el caso de la PS1 tenía además el “sustractivo”. El cual usaba para precisamente poder hacer mezclas con valores oscuros de origen: sombras, humo… etc.
Y en el caso de la 3DO tenía también sustractivo y un modo con condición lógica(una especie de máscara o modo ventana). Más todo estos anteriores divididos por 2.
El caso del VDP1 es especial. No es una mezcla aditiva pura. Hace “shift” o “offsets”, sumando o restando valores, con ciertas excepciones. Esta no está totalmente documentada. Pero viendo como funciona el Gouraud en VDP1, explicado más en detalle en la documentación. O como funcionan otros modos de los cálculos de color en el VDP1. Y después de darle muchas vueltas, he llegado a esta conclusión. La clave está en que el VDP1 cuando mezcla colores oscuros o negros no funde estos valores de origen con el destino como se presupone en una suma aditiva. El negro prevalece y no debería. Incluso con un pattern con una forma negra, el resultado es prácticamente igual al modo Sombra. El resultado es que los colores origen y destino se mezclan preservando parte de su color base y si tienen negro este también se queda.¿Otra genialidad del equipo de I+D de SEGA doméstica en Japón? U otro error. Lo que está claro, es que el funcionamiento no es intuitivo como un Artista pueda esperar. Lo digo en primera persona. XD
Por otra parte el VDP2 tan solo tiene mezcla aditiva en la mezcla final.
También podríamos decir que el VDP1 y el VDP2 tienen una mezcla con condición lógica como la 3DO pero no al mismo nivel detalle.
Tipos de blend o mezclado
En el mundo del “blend” o mezclado. O también denominada matemática de color. Existen diversas fórmulas para obtener variados resultados de mezcla entre los operandos “origen” y “destino”. Siendo algunas operaciones conmutativas o no conmutativas. Aunque el más conocido y común, que sirve como base para todo es el Alpha blending.
Voy a poner como ejemplo los usados en programas como Photoshop/Gimp/PaintShopPro o similares, con modos lo más parecidos a los resultados que obtenemos en estas máquinas en sus efectos de mezclado. Estas fórmulas de mezclado las agrupare por resultado de mezcla en función de cómo se interpreta el blanco o el negro como “alpha” para transparencia u opacidad:
El blanco es “alpha” o desaparece:
Multiplicativa [Conmutativa]→Destino x Origen
El negro es “alpha” o desaparece:
Pantalla / Multiplicativa Inversa [Conmutativa]→1 – (1 – Destino) x (1 – Origen)
Aclarado lineal (Aditiva) [Conmutativa]→Destino + Origen
NOTA: En estas fórmulas se suelen usar los valores en escala de 1. Usándose el valor de tono del color base.
En este caso todas las fórmulas son Conmutativas. Pero hay otras que no. Por ejemplo la fórmula del alpha blending real no es conmutativa.
Como podemos ver hay bastante confusión con los términos y los resultados. Ya que sobre estas existen multitud de patentes, y formas de hacerlo.
Resultados finales de “Alpha Blending” de estas máquinas
Según las capacidades de la máquina se podían conseguir efectos diferentes:
A) El Mezclado aditivo junto a una modulación multiplicativa permitía efectos de Aclarado o Luminosidad: destellos, chispas, rayos, sangre, agua, cristales, iluminación, fuego, nubes, niebla, lluvia…etc. Este puede ser similar a un Alpha Blending Aditivo de las GPU del 1996.
B) Y el Mezclado aditivo junto a una modulación divisiva de Sombra o Oscurecimiento: sombras, humo…etc. Este puede ser similar a un Alpha Blending Multiplicativo de las GPU del 1996.
C) La Mezcla sustractiva: Efectos especiales como sombra u
D) La Mezcla condición lógica: Máscaras, “Chroma key” o limitación de aplicación de efectos.
Jaguar en teoría podía hacer cualquier tipo de blend imaginable: luces, sombras, inversiones, aclarados, quemados…
3DO podía conseguir efectos de luces y sombras perfectos. Y otros extras incluso mejor que PS1 pero sin la posibilidad para los degradados al carecer de Gouraud y ni la calidad de los mismos al tampoco tener dithering. Gracias a la multitud de opciones que dispone en su pipeline de color.
SS podía conseguir efectos de luces y sombras correctos. Los de sombra con ambos VDPs. De luces principalmente y con mejores resultados con el VDP2. Se puede sumar el Gouraud en ambos VDP2 para conseguir degradados o cambios de tonalidad, pero sin llegar a la calidad de PS1.
PS1 podía conseguir efectos de luces perfectos, y de sombras correctos. Y algún efecto extra. Con excelentes degradados animados gracias a su Gouraud más el dithering.
Conclusión Alpha Blending de la época
La implementación por hardware con opciones, calidad y rendimiento de “Alpha blending” en consolas del momento no estaba nada mal.
Primero la Jaguar en el 1993, que fue a su rollo con un soporte total vía software sobre hardware programable, con infinidad de posibilidades, pero a la postre un rendimiento muy malo.
La de 3DO, especialmente y en el 1993, por su precocidad en una implementación en hardware, con una alta calidad y muchas opciones, pero con un rendimiento pobre.
El soporte en SS ya en el 1994 fue errático, como la tónica general en el sistema. En el VDP1 mostrando buenas intenciones pero mal ejecutado. Y en el del VDP2, junto al modo compartido con VDP1, si que fue una notable implementación de “su modo alpha” con muchas opciones, calidad justa y extremadamente rápido.
Mientras PS1 también en el 1994 tiene lo justo a nivel de opciones pero con un rendimiento muy óptimo para la época.
Sin tener en cuenta la opción de Alpha blending por software en PC, hasta el 1995 no se vieron en ninguna gráfica 3D aceleradora modos de Alpha Blending. Y estos no pasaban de ser bastante básicos, con mala calidad y muy lentos. No fue hasta la llegada en el 1996 de la 3Dfx Voodoo, cuando pudimos ver un soporte total de Alpha blending real y completo:
| Leyenda similitud implementación por hardware en consolas 1993-4 contra 3dfx Voodoo 1 1996, No incluyo a la Jaguar porque “literalmente” no tiene las características implementadas en hardware con registros como estas:
*1 SS VDP1 *No exactamente aditivo se parece en parte *4 Necesita sombreado Gouraud o similar como cambio de color en paletas *5 Ninguna máquina hace Mezcla multiplicativa. Pero mediante “una división” se puede conseguir algo similar. |
||||
| PC 3DFX 1996 Features | % of similarity 1993-4 Consoles | |||
| 3DO | SS VDP1 *1 | SS VDP2 *2 | PS1 | |
| Alpha Blending / Mezcla alfa | 50% | 20% | 90% | 50% |
| Addivitive Alpha Blending / Mezcla alfa aditiva | 90% | 20% | 90% | 90% |
| Multiplicative Alpha Blending *5 / Mezcla alfa Multiplicativa | 20% | 20% | 20% | 20% |
| Vertex Alpha Blending *4 / Mezcla alfa de vértice | 0% | 0% | 50% *3 | 50% |
| Texture Alpha Blending / Mezcla alfa de textura | 50% | 20% | 50% *3 | 50% |
| Vertex And Texture Alpha Blending *4 / Mezcla alfa de vértices y texturas | 0% | 0% | 50% *3 | 50% |
| Decal-Alpha Texture Blending / Mezcla de textura de calcomanía-alfa | 60% | 30% | 50% *3 | 50% |
| Factor Alpha Blending / Factor de mezcla alfa | 60% | 20% | 90% *3 | 50% |
| Modulate Texture Blending / Modulación de mezcla de texturas | 70% | 20% | 90% *3 | 50% |
| Modulate-Alpha Texture Blending / Modulación-alfa de Mezcla de textura | 70% | 20% | 90% *3 | 50% |
Las transparencias de la SS
Antes de empezar con la SS en detalle, he elaborado esta pequeña tabla con los datos recogidos de %
Mesh
Por aclarar antes de seguir. Podríamos interpretar como posible «transparencia» en la SS el uso del modo mesh o «pseudo Semi-Transparencia».
Para conseguir esta “transparencia” se aprovechaba el refresco o entrelazado de sistemas de video compuesto para tubos CRT. Que lo hacía inválido para salidas/TV RGB o SCART.
En estas capturas del compañero panzeroust en el foro elotrolado.net podemos ver como se ve en una TV CRT Real. A la Izquierda con cable RCA y a la derecha con cable RGB.
El efecto mesh puede ser realizado por hardware en el VDP1. O de forma trama predibujada o por dibujada software en ambos VDPs.
En el caso del VDP1 es una forma rápida a nivel de proceso de realizar una “Semi-Transparencia” por hardware. Como gran ventaja es que “funcionará” entre el VDP1 y el VDP2 sin problema.
Dado a esto último, encontramos en la mayoría de conversiones desde otros sistemas. Que los desarrolladores usaban el modo mesh para sustituir a las Semi-Transparencias. Pues con una función igual que en los otros sistemas tenían “algo transparente y que funcionaba como se esperaba” y además sin ninguna penalización de rendimiento.
% Juegos con Mesh
Estamos hablando que el 53% sobre el total de los juegos analizados usan este efecto.
Vamos a ver ahora el uso por Exclusivos sobre el total de juegos analizados.
Los juegos 1st party exclusivos son aproximadamente el 22% del total de juegos analizados. De estos el 63% de los juegos 1st party usan el mesh.
Los juegos 2nd party exclusivos suponen aproximadamente el 8% del total analizado, de los cuales usaron el mesh un 11%.
Los juegos 3rd party exclusivos son aproximadamente el 42% del total analizado. Y vemos que se usó mesh en un 14% de los mismos.
Algo que llama mucho la atención de los % de uso en los exclusivos, son los juegos 1st parties. Ya que tienen el valor más alto con diferencia. Yo tengo una teoría después de ver los juegos de SEGA y su progresión incluso en Arcade. Mi teoría es que en los departamentos AMx no había interés en este tipo de efectos. No los usaron o intentaron implementarlos en su tecnología Arcade coetánea a SS. Y seguramente, esta fue añadida en SS porque la competencia tenía algo parecido: SNES, 3DO… y lo que llegaron a saber de la PS1. Incluso ya con la SS lanzada, no intentaron usarlo en ninguno de sus juegos.
Por poner un ejemplo que me llamó la atención, tardaron casi 2 años en usar el Gouraud en sus juegos. Cuando otras 2nd parties o 3st parties lo usaron incluso antes. Pero es que en sus Arcade: Virtua Racing, Virtua Fighter, Daytona USA o Virtua Fighter 2, tampoco lo usaron porque ni tan siquiera lo implementaron en el hardware. Lo cual era normal, porque su competencia en Arcade estaba super lejos y más aún en el tema de las transparencias. Como digo a nivel de tecnología SEGA llevaba varios caminos, y andaba un poco perdida entre su presente reciente y el futuro inminente y rápido en el que estaban del 3D.
Ahora analicemos casos de ports de PSX. Estos significan el 24% del total, de los cuales están haciendo un uso de mesh el 63%.
Los Ports de PSX de Psygnosis son 2% del total analizado, donde el 50% usaron mesh.
Mientras los Ports de PSX de EA significan el 5%. De los cuales el 73% usaron mesh en vez de las transparencias de SS.
Aquí en los ports de PSX tenemos más datos importantes, al igual que en los juegos 1st party aquí los porcentajes son que más de la mitad del total de los juegos usaban mesh. Demostrando aún más las causas del efecto o creencia de que la SS “no podía” hacer transparencias.
Limitaciones del Mesh
El efecto mesh del VDP1 es prácticamente gratis para el sistema. Pero tiene una pega. Si debajo hay otro elemento con Mesh del VDP1 no se verá. Solo permite una capa de “mezcla”.
Si se realiza predibujada o por software es posible conseguir que se solapen “algo más”. Pero tampoco sería perfecto, porque según como, o se anularían o habría mucho parpadeo. Además está el hecho de que predibujada implica desperdiciar espacio en VRAM o por software consumo de proceso y RAM, mínimo pero consumo.
Conclusiones del Mesh
Como podemos ver y concluir la inmensa mayoría de los títulos y la práctica totalidad de los más conocidos usaban Mesh. Numéricamente, ahora, es totalmente comprensible entender porque la falsa idea de que “SS no podía hacer transparencias” era tan fuerte. Porque de hecho en sus juegos así se ponía de manifiesto. Nada más lejos de la realidad como veremos, por desgracia.
VDP1
En este caso y empezando por la unidad VDP1 que era el equivalente a la GPU de PS1. Y encontramos estos dos modos de la función para cálculo de color en el VDP1:
Sombra: Los píxeles del framebuffer que estén cubiertos por la primitiva serán reescritos con la 1/2 del brillo, la información de la primitiva [patrón o textura] no se dibujara o tendrá en cuenta.
Semi-Transparencia: Los píxeles sobre y bajo el framebuffer serán promediados juntos.
Semi-Transparencia+Gouraud Se hace el proceso de Semi-Transparencia y antes o después(no lo tengo claro al 100% aunque el resultado será el mismo) se hace el cálculo de Gouraud.
¿Por que incluyo Sombra?
Es sencillo, un efecto típico desde los juegos 2D es la sombra de los personajes. Las primeras transparencias que recuerdo, en recreativas o en la SNES o la mismísima MegaDrive, las vi en ese tipo de cosas. Normalmente se hacían con algún efecto de “transparencia”. Ya sea con cambios de paleta o con efectos shadow/highlight de MegaDrive/MasterSystem/GameGear o la capa de transparencia que tenia la SNES o el efecto de Sombras transparentes que tenían las placas Arcade System 16/32 de SEGA. A esta última es a la que más se parece lo que tiene implementado la SS tanto en el VDP1 como en el VDP2 para el efecto de Sombra Transparente.
Como curiosidad añadir, que Arcades de la competencia en 1991 también tuvieron soluciones para las “transparencias”. Konami en Xerxes y Data East en Desert Assault. También muy cerca en el 1992 la placa Taito-F3 con una solución similar al VDP2.
Como vemos las “Transparencias” del VDP1 son descritas como Semi-Transparencias, ya que las soportadas por hardware, eran transparencias al 50% fijas que no se podían graduar de mayor o menor intensidad por hardware. Aunque si tienen la posibilidad de mezclado sin límite como en la PS1. El tipo de «blend» o mezcla exacto es el aditivo, una suma del valor de pixel del fondo con el pixel de encima partida esta suma por 2, es decir una Semi-Transparencia FIJA al 50%. Al ser de esta forma, en algunos colores llegará un momento en que la suma y división den como resultado después de x capas mezcladas en el color “opaco” original, y no parezca que haya transparencia. Como gran desventaja está el hecho de que solo “verá” la información que hay en la capa VDP1, nunca lo que haya en el VDP2.
En los manuales de los SDK oficiales podemos ver más en detalle:
Sombra (Modo de cálculo de color = 1)
El procesamiento difiere según el MSB de los datos de píxeles ya escritos en el frame buffer. Cuando el MSB del frame buffer es «0», el procesamiento del cálculo del color, incluida la sustitución, no se realiza y el frame buffer se deja como está. Cuando el MSB del frame buffer es «1», se realiza la sombra.
En la sombra, los datos de píxeles ya escritos en el frame buffer se someten a un cálculo de color. El área en el frame buffer en el que se realizará el cálculo del color se busca a partir del patrón de caracteres y sus coordenadas de dibujo en el caso de sprites, y de las coordenadas de dibujo en el caso de no texturas. La luminosidad de los datos de píxeles ya escritos en el frame buffer en el área donde se va a dibujar la parte se convierte en la mitad para cada uno de R, G y B.
Sombra no cambia el MSB del fondo. Las áreas transparentes permanecen transparentes.
Sombra divide a la mitad la luminosidad de los píxeles en el frame buffer. Para hacer que la luminancia sea un cuarto, configure la misma tabla de comandos en VRAM dos veces. Para que sea un octavo, establezca la misma tabla de comandos en VRAM tres veces.
En la sombra, el cálculo se realiza sobre los datos de píxeles leídos de las coordenadas en las que se escriben los datos de píxeles del gráfico original. El dibujo en este caso se ralentiza, así que tenga cuidado: lleva seis veces más tiempo que cuando no se realiza el cálculo del color.
Semi-Transparencia (Modo de cálculo de color = 3)
El procesamiento difiere según el MSB del frame buffer. Cuando el MSB es «0», se realiza el reemplazo. Cuando el MSB del frame buffer es «1», se obtienen resultados de Semi-Transparencia. La Semi-Transparencia es la mitad (promedio) de la suma de los datos del gráfico original y del fondo(frame buffer). El resultado es escrito en el frame buffer.
El cálculo de color de la Semi-Transparencia se realiza en los datos de píxeles del gráfico original y los datos de píxeles leídos de las coordenadas de escritura en el framebuffer. En este caso, el dibujo se ralentiza, así que tenga cuidado: tarda seis veces más que cuando no se realiza el cálculo del color.
Sombreado Gouraud + Semi-Transparencia (Modo de cálculo de color = 7)
El procesamiento difiere según el MSB del frame buffer. Cuando el MSB del frame buffer es «0», se realiza el sombreado Gouraud. Cuando el MSB del frame buffer es «1», se realiza el sombreado Gouraud + Semi-Transparencia.
En el caso de la Sombra del VDP1 como hemos dicho ya es una especie de “división” sólo en el pixel de destino u objetivo. Esta función funciona por píxel(patrón y pantalla) en modo «RGB» o CLUT e incluso “Color Bank/CRAM” para los datos origen. Y sólo sobre datos destino RGB, si se usa sobre datos “Color Bank/CRAM” produce un efecto de “máscara” o de no escritura:
A= Origen/Primer plano ; B= Destino/Fondo/Objetivo ; R = Nuevo Destino/Resultado
P= posición(x,y) ; L = Luminancia base; Fs = Factor de sombra= 2, 4 o 8
P(A) = P(B) entonces R = L(B)/Fs
En el caso de la Semi-Transparencia del VDP1 tiene un método especial. Y se procesa por píxel(patrón y pantalla) en modo «RGB» o CLUT:
A= Origen/Primer plano ; B= Destino/Fondo/Objetivo ; R = Nuevo Destino/Resultado
La primera formula que nos puede venir es esta: R = (A+ B)/2
Pero como hemos dicho ya no es una mezcla aditiva pura. También me gustaría destacar que el resultado del efecto final sobre los colores de origen y destino tiende a oscurecerlos. Y cuando se superponen varias veces cuesta percibir la transparencia.
Como he comentado antes, es curioso que los ingenieros de SEGA no implementaran algo parecido al modo Highlight de la Megadrive para poder tener una mezcla más luminosa.
Si fuese una formula aditiva el blending final seria como el de PS1 o del VDP2. Pero no es así. El CC de VDP1 respeta los negros, para bien y para mal. Para bien, porque puede hacer efectos de sombra u oscurecer. Para mal, porque no mezclara las partes oscuras de forma suave y no aumentara el brillo en las blancas, que da ese acabado luminoso de la mezcla aditiva. Después de otra increíble conversación en el Discord de SegaXtreme y gracias a XL2 y fafling he aproximado algo más la posible fórmula del cálculo de color. Llegando a la conclusión de que los ingenieros de SEGA al final aprovechan el algoritmo o pipeline del sombreado Gouraud en diferentes combinaciones en los cálculos de color del VDP1. Por lo tanto para la semi-transparencia funcionara de manera similar pero con diferentes datos de origen y destino. En el Gouraud la tabla de vértices RGB asignada más la textura. Y en este caso la textura superior contra el fondo en el framebuffer:
R=(“A”+B)
“A” = Tomará un valor con signo negativo si es un valor muy cercano a negro. Si es un valor intermedio se mantendrá el valor. Y si es más luminoso tomará un valor con signo positivo. Los valores exactos, los desconozco.
Tratare de poner unos ejemplos con posibles valores predeterminados similares a los del Gouraud:
Si la primitiva origen es una “sombra”: Todo con valores RGB 1,1,1 y el fondo es 25,25,25. Con el sistema del VDP1 restará el complementario predeterminado de “A” a B: -15. Dando un resultado de 10,10,10 un color bastante apagado u oscuro y que es casi la mitad del destino. En aditivo el resultado antes de dividir por la mitad seria 26,26,26 un color un poco más de brillo o luminoso. A la mitad tendríamos 13,13,13 donde tampoco habría mucha diferencia.
Si la primitiva origen es “humo”: Todo con valores RGB 30,30,30 y el fondo es 25,25,25. Con el sistema del VDP1 sumaria un valor complementario predeterminado de “A” a B: +14. Dando un resultado de 39,39,39, rebasando el límite de 31,31,31 que es un blanco puro. En este caso es normal, pues tanto el origen como el destino eran colores muy claros. En aditivo el resultado antes de dividir por la mitad sería 55,55,55 un color que rebasa él límite. A la mitad tendríamos 28,28,28 tampoco hay mucha diferencia.
En el caso del Sombreado Gouraud + Semi-Transparencia sigue siendo una mezcla “especial” por ambas partes. Procesándose primero la Semi-Transparencia y después el Sombreado Gouraud. Alguien se podrá pregunta ¿Para qué es útil este modo? Bueno, es útil en varios escenarios:
1) Mediante la coloración de pattern/patrones, para ahorrar VRAM que permite el Sombreado Gouraud hacer efectos de cambios de color o paletas para efectos de luces en flares, explosiones o humos.
2) Máscaras dinámicas para explosiones o efectos de desaparición/aparición progresiva.
3) Añadir degradados ricos en tonalidades sobre colores planos más semi-transparencia:
El orden de la secuencia de ambos cálculos es importante, pero dado a cómo mezclaba el VDP1 no importaba. Al ser una mezcla “especial” y no aditivo el resultado iba a ser el mismo. Lo más probable es que en el caso del VDP1 en SS primero se haga el Calculo de color y después el Gouraud, según he leído y entendido en la documentación oficial. Mientras en el caso de la PS1, estoy casi seguro, primero hacia el Gouraud para después hacer la mezcla semi-transparente. Así podía hacer las máscaras dinámicas que la SS solo podría hacer sumando el VDP1+VDP2.
Clipping / Máscaras / Prioridad / ”Z-Buffer”
Era algo que en principio no había pensado tratar. Pero al meterme en profundidad en las transparencias, por propia lógica he llegado al punto de cómo se superponen los elementos opacos con los “transparentes”.
También aprovechó para hablar sobre la diferencia esencial de decir 15BPP o 16BPP. Ese bit de diferencia, normalmente en el MSB. Es el bit de transparencia, que muchas veces podemos leerlo de alpha. No debemos confundir con que el sistema tiene capacidad de alpha blending, esto es algo totalmente diferente. Bien es cierto que ese bit es parte del cuarto canal de información de un pixel. Y que si se expande en bits, será operativo para alpha blending. Asi en la propia SS en el VDP2 veremos cómo de forma similar tiene un canal alpha de 5bits. En resumidas cuentas este 1bit sirve para indicar si el pixel es 100% transparente o 0% opacidad, que es lo mismo. Normalmente se usa para hacer máscaras simples en bitmap, pero en esta generación como hemos podido ver se usaba en combinación con otros sistemas para diferentes fines, incluidos temas de transparencia.
Con ello llegamos a las máscaras o clipping. Porque lo llamo clipping, porque al fin y al cabo es una forma inicial de hacer clipping tal y como se conoce hoy día o como ya se hacía en sistemas más avanzados en la época. El VDP1 tiene un modo llamado local user clipping(no confundir con system clipping también muy útil), el cual le permite descartar pixeles dentro o fuera de una área para no ser dibujados, dentro de un mismo paquete de información grafica. PS1 tiene algo muy similar para su GPU, y si no recuerdo mal la 3DO también. Análogamente también se puede definir como Ventana(Window) que es lo que tiene el VDP2 o incluso sistemas de estas generaciones o pasadas como SNES o Genesis.
En otros sistemas modernos de GPU esto se haría con mezclado avanzado multicapa y según como se usará este clipping sería análogo en cierta forma a una especie de “Z-buffering” muy básico en el VDP1 algo más complejo en el VDP2. Pero que gracias a la “conexión” entre el VDP1 y el VDP2, elementos del VDP1 pueden aprovechar. Ya lo veremos algo más adelante.
Para acabar, la clave de este “Z-Buffering” será los valores de prioridad que tengan cada pixel, sprite/carácter o conjunto de datos. En el caso del VDP1 este valor viene dado por el orden de dibujo en la lista de comandos. En el caso del VDP2 puede tomar hasta 8 valores.
% Juegos con Semi-Transparencia / Sombra
Terminamos de nuevo con los porcentajes de uso sobre el total de juegos analizados. En este caso usan Semi-Transparencia / Sombra el 30%. De este porcentaje usan Semi-Transparencia el 73% y Sombra el 20%. Claramente los desarrolladores se decantan por el primero, al permitirles hacer lo mismo que con el segundo, prácticamente, y más cosas con igual peaje.
Vamos a ver ahora el uso en los Exclusivos.
Los juegos 1st party exclusivos son aproximadamente el 22% del total de juegos analizados. De estos el 27% usan Semi-Transparencia / Sombra.
Mientras los 2nd party exclusivos suponen aproximadamente el 8% del total analizado, donde el 48% usan Semi-Transparencia / Sombra.
Por último los 3rd party exclusivos son aproximadamente el 42% del total analizado. Y vemos hasta un 57% de uso de la Semi-Transparencia / Sombra.
Podemos ver como el uso en los exclusivos 2nd y 3rd party están por encima de la media de uso de su total. Lo que demuestra que era una característica que se necesitaba realmente en la industria y que buscaban los desarrolladores al poder disponer de ella en otras máquinas.
Ahora analicemos casos de juegos aún más “significativos” dentro del total. Son ports de PSX, que son el 24% del total. Y vemos hasta un 50% de uso de Semi-Transparencia / Sombra en ellos.
En los ports de PSX de Psygnosis que son 2% del total analizado. Vemos un 63% de uso de Semi-Transparencia/Sombra.
Mientras los ports de PSX de EA significan el 5% del total. De los cuales el 60% usaron Semi-Transparencia / Sombra.
Con estos porcentajes aún se ve más claro, que el empuje a usarlo en SS venia de PSX. Pues los números son claramente altos con respecto al total e incluso de los exclusivos.
Limitaciones de las Transparencias en el VDP1
El “fondo” del FrameBuffer del VDP1
La primera y más clara limitación es que mientras el VDP1 dibuja sobre el framebuffer vació, aquello que queda sin pintar o señalado como mascara, chroma key o 100% transparente. Después será un lugar donde la información del VDP2 se vea. Desde el Pantalla trasera a el resto de Pantallas por orden de prioridad.
El verdadero problema viene cuando el VDP1 hace un calculo de color y aun no sabe que habrá aquí por lo tanto dejara un color plano sin ningún extra de información de tipo “alpha” o similar.
Todo este problema viene de la separación en unidades de la pipeline grafica. Y la limitación de 16bits para la información de pixel. Solo hay disponible un pixel “libre” para ellos y los ingenieros de SEGA lo usaron como supieron en ese momento. Ese el MSB o bit15.
Quizás usando un pixel extra para este problema podrían haber resuelto el problema. Una suerte de MSB2, en el bit 14.
Espacios de color y tipos de color
La principal limitación que tiene el VDP1 a la hora de procesar los efectos de Calculo de color es el problema de mezclar espacios de color de RGB directos de la unidad con espacios de color indirectos hacia la CRAM del VDP2.
En general el VDP1 no puede leer la CRAM en tiempo de ejecución de su pipeline. Y digo en general porque tenemos el caso sin documentar de usar Gouraud o incluso otros modos como Sombra o Semi-transparencia sobre primitivas origen para los cálculos de color. Exactamente nos sabemos que ocurre, pero sabemos que algo se puede hacer. Y que algo de color de la CRAM es capaz de leer en este momento el VDP1.
Donde está claro que el VDP1 no puede hacer nada es con los datos escritos en su Framebuffer. Si estos tienen formato para la CRAM y MSB=0, no será capaz de hacer los cálculos de color a no poder tener los datos de color disponibles.
Esto no da en general la limitación de que si queremos cálculos de color como transparencias en VDP1 necesitamos que los datos en el Framebuffer sean MSB=1 y RGB directos.
Por otra parte si además queremos aprovechar el VDP2 para los escrito en el VDP1 tenemos la limitación de que si partimos de una textura con datos CRAM si se procesan en el VDP1 en procesos de cálculo de color estos quedan en el Framebuffer como RGB y ya el VDP2 no los podrá usar. En teoría. Porque he visto casos donde si lo hacen, en el FIFA 98 en las sombras de los jugadores. Como, exactamente no lo sé.
Conexión entre modos de color y VDPs:
El Modo 0: 4BPP CRAM-VDP2 <> Modo 1: 4BPP CLUT-VDP1
El Modo 0 es el modo de 16 colores que apunta a la CRAM del VDP2 y estará señalado en el Bit15 de los datos del pixel como MSB=0. Por otra parte está el Modo 1 que el modo también de 16 colores pero que apunta a la VRAM del VDP1 y estará señalado en el Bit15 de los datos del pixel como MSB=1.
Ambos están conectados en la forma que se configuran los datos de color de 16bits del pixel. La diferencia esta en como se configura el dato de color más el MSB en cada caso.
En el caso de CLUT en la primitiva se señala que es el modo 1 e ira a la VRAM del VDP1 a buscar la lista de 16 colores de 16bits. Allí podrá encontrar 2 tipos de colores:
1) Normalmente y principalmente un color de RGB directo de todos los disponibles en el VDP1 de 15BPP es decir 32.768 colores con “1 bit de alpha”. O 16bits totales por color.
2) El otro podrá ser un color “CRAM” que apuntara indirectamente a los colores del VDP2 de los que estén configurados en sus 4KB de CRAM internos. Este lo interpretaría cuando llegue al VDP2, lo procesara con alguna de sus funciones y pondría el color RGB resultado de los disponibles totales configurados en su Modo de color:, 1024 o 2048 colores totales disponibles de un total de 16bits o 24bits respectivamente.
¿Que utilidad tiene este modo? Bajo mi punto de vista, fue el intento de la conexión entre el VDP1 y VDP2 inacabada. Lo que le hubiese dado la versatilidad necesaria a la SS para hacer transparencias y prioridades del VDP2 junto al VDP1. Pero no permite esto. Al final permite tener colores o RGB directos de VDP1 o de la CRAM indirectos del VDP2 mezclados en un mismo patrón/textura.
Señalar, que de esta forma la Sega Saturn podría tener colores de 24bits reales sobre los datos procesados en el VDP1, si el VDP2 tuviese configurada su CRAM en modo 3 o modo 24bits de color.
Lo realmente llamativo aquí es que de alguna forma, como digo, hay una temprana vía de conectar las unidades. Incluso se plantean preguntas de si sería posible ir más allá vía software o con algún otro truco desconocido vía hardware. Como por ejemplo poder usar primero los cálculos de color del VDP1, dejar los colores en formato CRAM en el FrameBuffer del VDP1 para que después el VDP2 pueda hacer algo con ellos.
Justo acabando esta entrada, después de un intercambio de ayuda con @paul_met para el hackeo del Castlevania. Hemos llegado a este problema con las CLUT RGB y las prioridades en el VDP2 Sprite Screen. Pero primero el propio @paul_met ha puesto de relieve que en el propio Castlevania se usaba CLUT con diferentes prioridades en el VDP2 Sprite Screen. Y después @fafling y @XL2 lo han confirmado. Pero también ambos están seguros de que no se puede usar primero en el VDP1 y después en el VDP2. El tipo de color que este configurado en el pixel de la primitiva CLUT determinara o un camino u otro. No ambos. Sigamos de todas maneras con mí disertación.
La mayor dificultad estriba en que los colores entre el origen y el resultado final cambiarán dando resultados diferentes. Lo bueno es que a pesar de esta complejidad. Existe una limitación conocida dentro de los colores que estarán disponibles según sean configurados y de como posteriormente son procesados y resultado que se obtendrá de alguna manera es “conocido” dentro de un rango de conversión. Es complicado, pero no imposible, conseguir usar el modo Gouraud en el VDP1 y después dejarlo en CRAM en el Framebuffer con un subproceso por software. O incluso donde el VDP1 deja una Semi-Transparencia que deje señalado que es “transparente” para el VDP2. Esta idea no es totalmente mía. De nuevo en el canal de Discord hablando con @fafling y @XL2, pudimos llegar a este tipo de conclusiones. Esto podría abrir nuevas posibilidades de uso extra entre unidades.
Por último de manera análoga a esta conexión del Modo 0 y 1. Se me ocurre que podría haber sido posible y útil también conectar los modos 2, 3 y 4. Es decir CLUTs extra para 6BPP, 7BPP y 8BPP. Este último existe como tal en el lado del VDP2. ¿Podríamos tener CLUT 8BPP en el VDP1 de alguna forma?
MSB On
Volvemos sobre el MSB. Bien, como hemos visto antes en los cálculos de color según cómo esté configurado el MSB, podremos o no utilizar estos efectos. MON, o MSB On, es un registro propio de la lista de comandos del VDP1. Este registro sirve para cuando se escribe el píxel final de la primitiva en proceso en el framebuffer el VDP1 lo marque como MSB=1, si este registro está activo. El VDP2 podrá usarlo para sus funciones especiales de transparencia: Cálculos de Color+Prioridad y Máscara/Ventana en la pantalla/capa de Sprites/VDP1 y por otra parte la opción Sombra MSB de la función Sombra del VDP2.
Como es lógico este registro tiene sentido usarlo en una primitiva con MSB=0, o lo que es lo mismo Color bank o CRAM del VDP2. Lo cual anularía en teoría usar los cálculos de color del VDP1 y a la vez también nos limitaría en teoría el uso de en el VDP2 de las funciones especiales de la Pantalla de Sprites.
Pero sobre todo quería hablar del MSB On, como otra muestra primitiva por parte de los ingenieros de SEGA para conectar los dos VDPs. Otra muestra de una conexión incompleta a mi juicio. Y que como he expuesto antes. Y ahora con este MSB On, si se hubiese dispuesto igual que este registro, llamemoslo MSB1 otro para un hipotético MSB2. Podríamos haber visto una conexión total entre los VDPs.
Ahora expondré algún otro inconveniente más y también repasare otros con algunos datos extra e imágenes para ilustrar:
Limitaciones de la naturaleza del raster VDP1
Se veían artefactos en el caso de las primitivas distorsionadas o con perspectiva (sprites distorsionados o polígonos con color plano) rayas opacas en mitad de la transparencia. Que era el repintado del efecto, ocasionando la mala calidad y el gasto extra de ciclos.
- No podía mezclar los datos de los fondos generados por el VDP2, quedando en estas áreas las transparencias como anuladas.
- También podemos tener un caso. Donde ya pintando un elemento del VDP1 en el framebuffer en RGB(las sombras en FIFA 98 son CLUT/RGB VDP1), otro superior en proceso en el VDP1 con Semi-Transparencia no vea en absoluto al primero. En este caso es quizás porque, el elemento se ha marcado para ser usado en el VDP2 para algún cálculo de color o función. O su valor MSB es 0.
Limitaciones Espacios de Color dentro del VDP1 por compartición de datos incompleta con VDP2.
- Solo es capaz de mezclar elementos que estén dentro del espacio de color RGB del VDP1. Si la textura/patrón/color plano/sprite distorsionado ya pintada en el fondo(Frame buffer 0 del VDP1) a mezclar, esta marcada para usar datos de color del VDP2(color de paleta CRAM) la mezcla no se hará, viéndose opaca y con un color plano.
- Esta restricción de tipo de color no afecta, totalmente, a la primitiva superior. Es decir la “textura/patrón/color plano/sprite” superior puede estar en “Color bank/CRAM VDP2” o “CLUT/RGB VDP1” indiferentemente.
- Eso si, hasta donde yo he visto y entendido, si se usa “Color bank/CRAM VDP2” solo funcionara con la primitiva Polígono incluso junto al CC VDP1 Gouraud(que teóricamente tampoco se podría). ¿Como el VDP1 lee el color o colores en este momento de la pipeline? Realmente al día de hoy no lo sé.
- Si la primitiva tiene un “patrón” en “Color bank/CRAM VDP2” puede que “planche” el patrón y quede en color plano haciendo la mezcla. Pero no estoy seguro al 100%. Vi un ejemplo en NBA Jam Extreme. Y durante la redacción de esta parte @Paul_met corroboro mis dudas. Sobre el patrón con degrado en color CRAM, él ha activado el modo H-T. Este intenta mezclarse con los personajes en CLUT RGA bajo él. Con problemas, pero funciona. ¿Mejorable vía una pequeña ayuda por software?
- Lo que si he podido ver usar es un “textura/patrón/color plano/sprite” con “Color bank/CRAM VDP2” y el modo CC VDP1 Sombra. Pero este CC plancha el patrón para dejarlo “gris” por definición del modo. Que es lo que se espera de esta función de CC.
Para finalizar voy a añadir una tabla resumen como en SATs de SEGA para la función sombra:
| VDP1 sobre VDP1 | |
| ¿Penalización por uso? | Entre 3 y 6 veces más que un pixel opaco. |
| ¿Pueden mezclase sprites sobre otros sprites? | Si |
| ¿Tipo de modulación? | “División” |
| ¿Tipo de mezcla? | “Aditiva”
No se interpreta la intensidad del negro como transparencia. Resultados apagados o más oscuros. |
| ¿Pueden los sprites tener diferentes prioridades/profundidades? | Si, usualmente 65.536 valores. Integer16.= 16bits |
| Tipos de color válidos sobre datos origen | RGB o “Paleta” |
| Tipos de color válidos sobre datos destino | RGB o MSB=1 |
| Cantidad de factores/niveles alpha disponibles | 3 fijos. 100%, 50% y 0% |
| ¿Se pueden mezclar varias capas de transparencia? | Si, 65.536 |
| ¿Se pueden combinar más de una función o modo de cálculo de color? | Si, aumentan la penalización. |
Conclusiones Transparencias VDP1
Se puede observar el uso de este efecto en muchos juegos de todo el catálogo, desde el principio y durante toda la vida del sistema. Lo que pasa que el uso es muy pequeño o en detalles que pasan muchas veces desapercibidos. Y esto aumentó la sensación de que no había transparencias o que al no usarlas más, incluso se “creyese” que la SS no podía hacerlas.
Como podemos ver SS podía hacer transparencias con su VDP1. No era alpha blending, pero hacía algo parecido. El que no se usará(de manera general, porque se usó en muchos títulos) como hemos visto fue por múltiples desventajas o inconvenientes. Pero puede que una de las más importantes fuese esta «advertencia»:
Que si NO se usaba bien, podría ser un costo muy alto para el sistema, tomando SEIS veces más calcular el mismo píxel que sin este efecto.
Y yo añado: En el peor de los casos. Mi teoría es que si no hay redibujado, y se utiliza dentro del resto de limitaciones, pienso que la penalización es menor. Entre 3x y 2x.
Queda claro que la combinación de inconvenientes, como la penalización que había por defecto, sumados al desconocimiento de como usarlo bien, en esto quizás ayudó mucho un SDK al principio que no ayudaba lo que debería. O por la facilidad que se presentaba al convertir desde PSX, con solo poner en trama en SS lo que era transparencia, y olvidarse de quebraderos de cabeza. Está claro que usar un efecto u otro en SS, no era igual que PSX… pues la dependencia entre sus chips había que controlarla, y eso tenía un coste. Además, que a pesar de ello, nunca se obtenía exactamente el mismo resultado en casos 3D complejos, si muy aproximados o iguales en caso sencillos 3D o 2D.
Como reflexión decir que en la 3DO o la Jaguar el uso de sus modos de Semi-Transparencias también penalizan(mucho más) pero no tenían los problemas que tenia la SS. Todo un error por parte de SEGA en el diseño, cuando tuvo casi dos años para hacer al menos lo mismo que estas. Sony lo resolvió mucho mejor, aquí también. PSX iguala la forma de usar estos efectos en 3DO o Jaguar. Y mejora en velocidad al usar este efecto.
VDP2
El VDP2 es un chip ultra complejo. En cierta forma me recuerda al VDP de la SNES, que ya era complicado y potente. Pero el VDP2 multiplica por 10x su complejidad y potencia. En la escena lo conocemos como la bestia salvaje.
En otros sistemas gráficos normalmente la pipeline gráfica acaba en un frame-buffer final. En el departamento de I+D Doméstica de SEGA se pusieron creativos, o tuvieron una idea fantástica, según se mire. Y decidieron que el frame-buffer iba a estar en la mitad de la pipeline. Entre el VDP1 y el VDP2. Las razones pueden ser varias. Yo creo que la principal es, que el VDP1 en cierta forma es “más lento” ya que depende de las CPUs para obtener su información de partida para dibujar. Mientras el VDP2 puede hacer “casi todo” por si solo. Así el VDP2 está en modo recepción, coge lo que le llega del VDP1 cuando este “lo tiene listo” y hace su magia.
Esta forma de trabajar entre procesadores gráficos, unida al hecho de que si el VDP1 hacia el “3D” de la consola, de manera “2D”. Mientras el VDP2 era “casi totalmente” 2D más su capacidad de proceso de planos 3D(como el modo 7 de SNES) que era lo único que lo aleja de su naturaleza 100% 2D. Y como decía, todo esto unido hacia que los desarrolladores tuvieran que entrar en un mundo muy concreto y especial. Sega Saturn con su tandem VDP1+VDP2 era poderosa, pero extremadamente novedosa y exótica.
Así el VDP2 puede aplicar diferentes procesos de color, clipping o prioridad sobre pixels, patrones o capas. Tanto en su unidad misma como sobre la información recibida desde el VDP1. Todo ello, bajo una complejidad a configurar y combinar que comprende: Resolución del VDP2, resolución del VDP1, Tipo de color en uso en el VDP2, tipo de color de recepción del VDP1 y datos compartidos entre VDPs mediante los MSB.
Pero centrémonos en sus capacidades para hacer transparencias. El VDP2 tiene 3 tipos de mezcla (A + B) o (B + A) y “As in” que coge los valores de Brillo/Valor del componente “Origen/superior”. En cada modo el VDP2 puede aplicar 32 ratios para A y/o B y en “as is = CCMD(1,1)” en el componente que se seleccione como “Origen/superior”. VDP2 puede mezclar colores RGB o Indexados dentro de su propia unidad.
En el caso de la transparencia del VDP2 esta es de modulación multiplicativa más mezcla aditiva(como la GPU de la PS1), por píxel(patrón y pantalla) en modo «indexado de color y RGB» y con posibilidad de usar ratios o pasos de mezclado como la PSX, en el caso del VDP2 hasta “32” pasos. Pero en el caso del VDP2 totalmente configurables y no fijos, sumados a los brillos/valor, aún más posibilidades de combinación. El VDP de la 3DO si esta casi a la par con el VDP2 en este aspecto, superior en otros. El VDP2 tiene modos especiales para sombras y además puede combinar hasta 3 capas para hacer mezclado en una pasada y un solo ciclo. PS1 y 3DO lo máximo que pueden son 2 elementos para mezclar en una pasada y además en varios ciclos, de 2 a 3 en el caso de PS1 y en el caso de 3DO más de 6, estimo casi seguro por su lentitud vista en juegos reales.
Siendo más precisos:
F = Factor «brillo/valor» o «Ratio configurado»
A= Origen/Primer plano ; B= Destino/Fondo/Objetivo ; R = Nuevo Destino/Resultado
Ratio configurado→ R = A*F(A) + B*F(B) ; F(A)=F(B)=0…31
“As is” → R = A*F(A) + B*F(B) ; F(A)=F(B)=1
Donde F puede estar configurado o configurar el modo «as is» que usará el factor de «brillo/valor» en el color base de cada pixel, patrón o pantalla.
Y donde A y B pueden ser cualquier Pantalla/Capa del VDP2, incluida la procedente del VDP1. Y después puede aplicar dicha fórmula de forma concreta y configurable sobre: pixeles, áreas de píxeles(máscara o ventana), patrones o la pantalla/capa entera. Esta capacidad es superior a la GPU de la PS1 pero muy similar a la de la 3DO.
Ahora vamos a entrar en algo más detalle en cada una de las partes del VDP2 que puede realizar un efecto de “transparencia”.
Funciones de Calculo de color Normal / Extendido (ECC) / Modo «as is»
El VDP2 posee una función principal de Calculo de Color, la cual se encarga de hacer las transparencias. Esta función puede hacer transparencia sobre todas las Screens/Pantallas incluida la del VDP1. Incluida la especial Line Color Screen pero excepto el Back Screen. A su vez tiene dos modos de operación: Normal y Extendido.
El modo de Calculo de color Normal solo es capaz de mezclar “un nivel” o por decirlo de otra manera entre dos capas/pantallas, una superior y otra inferior. Aunque es posible “activarla» en todas las capas sin problema. Haciendo la transparencia correctamente, mientras el pixel de destino sea opaco. Si es transparente no funcionara. Poniendo un ejemplo claro:
Si tenemos 4x capas/pantallas activas, las cuatro con transparencia. Solo veremos la capa/pantalla 1ª mezclada con la 2ª. El resto, la 3ª y 4ª, quedaran ocultas u opacas tras la capa/pantalla 2ª. Este es un ejemplo extremo, pero totalmente posible.
Como todo en el VDP2, y en a la SS, tiene un precio. Usar CC nos hace bajar los bits de color totales. Según como se configure la VRAM del VDP2 y los tipos de color en la pantalla de sprite. Tendremos mayor o menor calidad de color. El VDP2 puede procesar color a 24BPP y hasta palabras de 32bits. A nivel de comunicación con el VDP1 está limitado a 16BPP. Y después si se usa la función de cálculo de color y prioridad exclusiva de esta pantalla, bajamos a 11bits de color efectivo. Pasando de 32.768 colores a 2.048 colores. Pudiendo mezclar sobre información de color RGB o de Paleta. Cuando pasemos a Hi-Res solo se podrá mezclar sobre color de Paleta.
El modo de Cálculo de color extendido (ECC) permite mezclar “hasta 4 capas/pantallas”. Donde en realidad será:
Si tenemos 4 capas/pantallas activas. 2x capas con transparencia, la capa/pantalla de color en línea insertada en alguna de las capas/pantallas y finalmente todo esto contra 1x capa/pantalla opaca. Nos da 4 capas “mezcladas”
Resumiendo, la principal diferencia entre ambos está en el límite de capas que puede mezclar con semi-transparencia efectiva. En el normal puede mezclar hasta 1 capa transparencia y el modo extendido hasta 2 de manera efectiva.
Es cierto que el segundo “blend” de ECC añade limitaciones extra: Los ratios ahora son 3 posibles combinaciones para las 3 pantallas a la vez. Y se “pierde el blend aditivo parcialmente”. No procesando las zonas con degradados de brillos/intensidades o máscara de color negra, en el segundo alpha blending. Además la cantidad de colores de la paleta en la pantalla de sprites se reduce a la mitad, de 2.048 pasa a 1.024 colores si usamos la función de cálculo de color y prioridad. Y si solo la usamos en su modo MSB siendo este RGB de 32.768 a 16.384 colores, teóricamente.
Lo cual no deja de ser impresionante para el 1994. Hacer en un ciclo de sistema dos semi-transparencias “alpha blending”, sobre tres capas de hasta 352×512(entrelazado) es una brutalidad.
Acabamos hablando sobre el modo “as is”, el cual no deja de ser el modo normal pero con valores de alpha sin configurar. Dejando tan solo el paso de mezclado aditivo al sistema. No es complicado de usar, más bien como todo en SS difícil de encajar dentro de una pipeline 3D. No se si este puede ser usado también en el ECC, en una segunda capa, pero diría que no por la naturaleza fija del modo ECC.
% Juegos usan Funciones de Calculo de color Normal / Extendido (ECC) / Modo «as is»
Terminamos de nuevo con los porcentajes de uso sobre el total de juegos analizados. En este caso usan Funciones de Calculo de color Normal / Extendido (ECC) el 44%. De este porcentaje usan el modo normal 38% y del Extendido (ECC) el 6%
El modo “as is» está presente en un 0.93%.
Los desarrolladores se decantan por el modo normal, ya que es más versátil y relativamente fácil de implementar. Sin embargo el Extendido/ECC siendo más interesante y espectacular, se complica aún más su uso. No en exceso la verdad.
Por último, a pesar de que es complicado saberlo actualmente por el estado de la emulación, y siendo consciente de que haya muchos más juegos usando el modo “as is”
Conclusiones de Funciones de Calculo de color Normal / Extendido (ECC) / Modo «as is»
Ambas funciones son sumamente potentes para la época. Y con ellas el VDP2 tenia el alpha blending más cercano a la realidad que había en aquel momento por hardware. El problema ya lo conocemos, que el enfoque era principalmente 2D. Aunque como también sabemos ya, y explicare un poco más adelante también es posible aprovecharlo para la parte 3D del sistema. No sin complicaciones, claro.
VDP2 Screens/Pantallas
Las Screens/Pantallas en el VDP2 son como capas o fondos en otros sistemas parecidos o análogos. Están pueden ser de tres naturalezas: NBG o de scroll XY más escala en cada eje, RBG o de rotación en XYZ más escala en cada uno de los ejes. Después las Screens/Pantallas especiales. La Pantalla de Sprites o FB1 del VDP1. La Pantalla trasera o Back Screen y la Pantalla de color de línea o Color Line Screen.
Como hemos dicho las Screens/Pantallas a las que se les puede aplicar funciones con efectos de color y prioridad exceptuando el Back Screen o Pantalla trasera. Además el VDP2 podía discriminar como procesar dichos efectos con modos espaciales o concretos así pues podría aplicar los efectos a toda la Screens/Pantallas, a nivel de caracteres o patrones, o nivel de pixeles o puntos. Cabe destacar que este último nivel proceso solo estará disponible bajo espacio de color de Paleta.
El VDP2 podrá procesar efectos de transparencia en casi todos sus modos. Exceptuando algún modo especial que restringuira el uso de la VRAM y los ciclos disponibles del sistema. Pero podemos decir que de manera general tanto en el modo de resolución normal como de alta resolución. Como los modos entrelazados el VDP2 podrá realizar efectos de color.
Como curiosidad destacar que el VDP2 podrá representar un Screens/Pantallas a 24bits de color y realizar efectos de color sin problemas contra la Sprite Screen. Cosa que por ejemplo la PS1 no podría realizar.
Por otra parte el VDP2 puede procesar datos de color RGB como de paletas en sus Screens/Pantallas. Aunque internamente trabaje con RGB. Este RGB se configura en tres modos. Siendo el 3 modo el modo 24bits, el cual limita parcialmente los dos especiales o extendidos de cálculo de color, pero no los anula.
% Juegos con transparencias VDP2 Screens/Pantallas
Terminamos de nuevo con los porcentajes de uso sobre el total de juegos analizados. En este caso usan transparencias VDP2 Screens/Pantallas el 38%.
Vamos a ver ahora el uso en los Exclusivos.
Los juegos 1st party exclusivos son aproximadamente el 22% del total de juegos analizados. De estos el 52% usan transparencias VDP2 Screens/Pantallas.
Mientras los 2nd party exclusivos suponen aproximadamente el 8% del total analizado, donde el 59% usan transparencias VDP2 Screens/Pantallas.
Por último los 3rd party exclusivos son aproximadamente el 42% del total analizado. Y vemos hasta un 45% de uso de la transparencias VDP2 Screens/Pantallas.
Podemos ver como el uso en los exclusivos en líneas generales es normal. Sobre la mitad. Volvemos a destacar como en el caso de los juegos de SEGA no se usaba más esta unidad. Las transparencias no era algo que les preocupara mucho parece ser.
Ahora analicemos casos de juegos aún más “significativos” dentro del total, los ports de PSX, que son el 24% del total. Y vemos hasta un 33% de uso de transparencias VDP2 Screens/Pantallas en ellos.
En los ports de PSX de Psygnosis que son 2% del total analizado. Vemos un 25% de uso de transparencias VDP2 Screens/Pantallas.
Mientras los ports de PSX de EA significan el 5% del total. De los cuales el 53% usaron transparencias VDP2 Screens/Pantallas.
Podemos observar en estos porcentajes, la dificultad de trasladar los efectos de transparencia desde la naturaleza de PS1 a la naturaleza del VDP2. Curioso ver que en el caso de EA el esfuerzo es significativo. Estando en los mismos porcentajes que los exclusivos.
Conclusiones transparencias VDP2 Screens/Pantallas
Podemos ver que el uso de la transparencia sobre las Screens/Pantallas existió. En un porcentaje dentro de la media del efecto en si dentro del sistema. A mi manera de ver bajo o muy bajo, sobre todo en el caso de los exclusivos y que además era relativamente fácil de usar, dentro de lo que es el VDP2. Aunque también es justo decir que los que lo usaron lo usaron muy bien. Por parte de los ports desde PSX, ya sabemos que estaba complicado. Con todo sorprende de nuevo gratamente como los juegos de EA hacen un uso de el alto en este caso al menos.
VDP1(FB1) Sprite Screen/Pantalla de Sprites + VPD2 Screens/Pantallas
Los VDPs tienen un modo puente entre el ambos. El VDP1 y el VDP2 están enlazados mediante el uso del FB1, o framebuffer “dibujado” o “final”. Este al final contendrá valores de solo de 16bits o solo de 8bits, según el modo de color configurado en el VDP1. Y después el VDP2 tendrá formas diferentes de interpretar dicha información y procesarla. Desde dejarla como esta a poder hacer procesos extra dentro de la propia Screens/Pantallas de Sprites o contra el resto de Screens/Pantallas del VDP2.
Esto se traduce en una cantidad de posibilidades y complejidad asombrosa. Pero también es la evidencia de poder que tiene el VDP2. La cantidad de pixeles que es capaz de procesar en un ciclo de sistema es monstruosa. Y todo lo que puede hacer con ellos aún más.
El principal problema es el encaje de un chip grafico de naturaleza 2D dentro de un momento de gráficos 3D. Y como este además trabaja conjuntamente con el VDP1, otro chip grafico con ADN 2D pero aún más cercano al 3D.
Principalmente los ingenieros de SEGA resolvieron, parcialmente bajo mi humilde criterio, la comunicación entre VDP2 mediante una función propia del VDP2 que lee y usa los valores en cada pixel que llega de la capa del VDP1. Esta se llama función de cálculo de color y prioridades que también me gusta resumir como CC+prioridades. Y esta buscará primero en el recién llegado FB1 del VDP1 en los bits MSB de cada pixel el valor que exista.
Si el MSB=1 será un pixel RGB y lo representara tal cual, y si el modo de cálculo de color y prioridad es el 3 se aplicará el proceso. Realmente cuando es RGB el proceso que se hace es el de color y que el de prioridad quedará anulado a el valor de prioridad que tenga toda la Screens/Pantalla de Sprite. Sin embargo el proceso de color podrá tener un valor de transparencia dada según se configure. Será un solo valor único para todos los pixels RGB o con MSB=1.
Si el MSB=0 será un pixel de Banco de Color o CRAM. Y ahora viene la parte realmente compleja. Según como se haya configurado el tipo de píxel de Banco de Color para la Screens/Pantallas de Sprites. Entre 8 tipos disponibles. La configuración final del pixel variara y con ello el proceso que haga sobre este la función de cálculo de color y prioridad del VDP2. Estos pixeles están en la CRAM, y no dejan de ser pixeles RGB. Según como este configurado la CRAM serán o 1024 o 2048 colores totales. En cualquier caso para la Screens/Pantallas de Sprites serán 2048 colores máximos los disponibles para los colores de paleta. Ya que estos tienen un máximo de 11bits de disponibles para definirlos:
El MSB (Most Significant bit): Valor 15, de los 16 posibles al ser 16-bit color. Que será el valor que según el modo de color configurado dejara en el FrameBuffer esta marca que actuá para usar la información de ese pixel como transparente entre VDPs. Y para modos especiales del VDP2 como el modo sombra MSB o CC en modo MSB. O incluso como valor usable para las funciones especiales de prioridad o calculo de color.
Los valores LSB (Less Significant Bit) variarán según el modo elegido teniendo un máximo de 11bits y un mínimo de 9bits para definir el color en modo 16BPP. En modo 8BPP el máximo serán 6bits y el mínimo de 7bits para definir el color.
Los valores restantes entre el MSB y los LSB son los valores para las funciones especiales de cálculo de color y prioridad. Que variarán entre 3bits máximo para cada una y 1bit.
Puede usar sus capacidades de mezcla o discriminación de prioridad o profundidad de capa como en las capas NGBx o RGBx. Con una limitación, solo puede tomar 8 valores tanto para el mezclado de transparencia y para las prioridades. Esto significa, que para las transparencias podrá interpretar hasta 8 niveles de opacidad, no los 32 totales posibles. Y para las prioridades las mismas posibles que para las capas.
Es una característica sumamente compleja de usar, pero a la vez muy potente. Ya que en un ciclo de sistema el VDP2 es capaz de hacer alpha blending y una especie de “Z-buffer” sobre la información dibujada por el VDP1.
La función de cálculo de color y prioridad en esta pantalla, no funciona de forma separada como en el resto de Screens/Pantallas. Si no que funcionan de manera conjunta. Mediante una condición de Calculo de Color enlazada con la Prioridad mediante funciones lógicas( ≥ = ≤ ).
Por último esta función aunque trabaja principalmente con los colores asociados a la CRAM. También tiene un modo para trabajar con colores RGB. Usando el MSB identificativo para asociar en este caso solo un valor de alpha blending y un valor de prioridad o “Z-buffer”.
Limitaciones transparencias VDP1 Sprite Screen + VPD2 Screens
Gran parte de las limitaciones o las principales están perfectamente explicadas en una respuesta del Servicio Técnico de SEGA el 16 agosto del 1995. En este caso, no adjuntan una tabla resumen. Como si hicieron para explicar la función sombra, que veremos más adelante. Yo he intentado reproducir una para resumir estas limitaciones añadiendo un resumen de la propias del VDP1, ya que estas al final llegara al lado del VDP2.
| VDP1 sobre VDP2 | |
| ¿Penalización por uso? | Ninguna. |
| ¿Pueden mezclase sprites(VDP1) sobre otros sprites(VDP1)? | En general NO. Pero SI puede de forma muy limitada. Solo con la función MSB Shadow. |
| ¿Tipo de modulación? | Multiplicativa |
| ¿Tipo de mezcla? | Aditiva (la intensidad del negro como transparencia) si es 1ª capa.
Aditiva con error sobre partes oscuras (No se interpreta la intensidad del negro como transparencia) si es 2ª capa con ECC Resultados brillantes o más blancos |
| ¿Pueden los sprites tener diferentes prioridades/profundidades? | Si, 1, 4 o 8 prioridades. De 1 a 3bits. |
| Tipos de color válidos sobre datos origen | RGB o Paleta |
| Tipos de color válidos sobre datos destino | RGB o Paleta |
| Cantidad de factores/niveles alpha disponibles | 2 a 32 posibles según colores origen y/o destino. |
| ¿Se pueden mezclar varias capas de transparencia? | Si, de 1 a 2 (con ECC) |
| ¿Se pueden combinar más de una función o modo de cálculo de color? | Si, con limitaciones o con modos como ECC. |
Enlace a tabla completa (Por acabar)
% Juegos con transparencias VDP1 Sprite Screen + VPD2 Screens
Terminamos de nuevo con los porcentajes de uso sobre el total de juegos analizados. En este caso usan transparencias VDP1 Sprite Screen + VPD2 Screens el 49%. De este porcentaje usan transparencias VDP1 Sprite Screen + VPD2 Screens del CRAM 41,26% y de RGB o modo MSB el 7,74%. Claramente los desarrolladores se decantan por el primero, ya que es el que da los resultados más espectaculares y el más versátil. El segundo es utilizado más para usar como máscara o “Sprite Window”.
Vamos a ver ahora el uso en los Exclusivos.
Los juegos 1st party exclusivos son aproximadamente el 22% del total de juegos analizados. De estos el 39% usan transparencias VDP1 Sprite Screen + VPD2 Screens.
Mientras los 2nd party exclusivos suponen aproximadamente el 8% del total analizado, donde el 33% usan transparencias VDP1 Sprite Screen + VPD2 Screens.
Por último los 3rd party exclusivos son aproximadamente el 42% del total analizado. Y vemos hasta un 38% de uso de la transparencias VDP1 Sprite Screen + VPD2 Screens.
Podemos ver como el uso en los exclusivos es incluso más bajo que en el caso de las Screens/Pantallas. Esta función es compleja, y además el modo de encajarla en la pipeline 3D no es fácil. Podemos decir que los exclusivos están dentro de la media de uso.
Analicemos los que son ports de PSX, que significan el 24% del total. Y vemos hasta un 33% de uso de transparencias VDP1 Sprite Screen + VPD2 Screens en ellos.
En los ports de PSX de Psygnosis que son 2% del total analizado. Vemos un 0% de uso de transparencias VDP1 Sprite Screen + VPD2 Screens.
Mientras los ports de PSX de EA significan el 5% del total. De los cuales el 37% usaron transparencias VDP1 Sprite Screen + VPD2 Screens.
Vemos que los porcentajes bajan aún más también en el caso de los exclusivos. Pero de nuevo EA salva la casa, incluso incrementado su uso. Muy significativo para mí el 0% en los ports de juegos de Psygnosis, posiblemente los ports que más se compararon y más daño hicieron.
Conclusiones transparencias VDP1 Sprite Screen + VPD2 Screens
Ya hemos visto que se uso lo justo en el caso de las Screens/Pantallas siendo bastante asequible su uso. Y siendo las transparencias VDP1 Sprite Screen + VPD2 Screens aún más complejas de usar. Lo más lógico ocurre. Los porcentajes de uso bajan aún más. Una pena, pues el resultado de la transparencia en esta es espectacular. Y era la mejor vía para conseguir la mejor transparencia y la equivalente a PS1 por hardware en la SS sobre elementos 3D. Destacar de nuevo el gran uso que algunos exclusivos hicieron de esta, como no hablar aquí de todos los juegos de Treasure que la usan de manera sobresaliente o el excelente Shining Force 3.
Funciones Sombra: Sombra Normal y Sombra MSB
Seguimos con las funciones de Sombra. Las englobo dentro de la parte VDP1 Sprite Screen + VPD2 Screens porque estas trabajan con datos origen del VDP1 para ser procesados por el VDP2. De igual forma que la función de CC+Prioridades que hemos visto antes. Pero con otros resultados/objetivos y limitaciones como pasaremos a ver:
Sombra Normal
Esta sombra en esencia es idéntica a la del VDP1. Coge el sprite/patrón/textura, sin los datos de color, y todo lo que esta bajo de estos datos lo oscurece o reduce su valores de luminosidad o de los tres canales RGB a la mitad.
Este modo tiene limitaciones similares a la función de CC+Prioridades. Si dos patrones/texturas solapados donde una está con este efecto encima de otros, el de sombra no vera al otro. Podemos decir que solo es capaz de procesar “una capa” con este efecto.
Estas sombras son las típicas sobre suelo rotado RGBx. O sombras de personajes 2D en los juegos de Treasure o la mayoría de las de Story of Thor 2.
El funcionamiento es sencillo. Los sprites que vayan a usar esta función deberán estar marcados en su LSB con valores 0. Según el tipo de sprite configurado en el VDP2 serán más o menos 0.
Sombra MSB
Está en esencia funciona de igual forma a las anteriores. Pero al solaparse entre si los sprites/patrones/texturas que estén marcados para ser usado este efecto con otros, el de sombra se mezclara con el resto debajo de él. Quiere decir que es capaz de procesar el efecto “en múltiples capas” en principio sin límite de solapes.
Principal problema, está solo se puede usar en modo 8BPP. No se podrán configurar prioridad o profundidades y deberán ser colores de la CRAM, no será posible usar valores RGB.
El funcionamiento es igual a la normal, pero además como dice su nombre el valor 15 o MSB deberá ser 1.
Juegos como Sexy Paradious y Astal lo usan exquisitamente. De nuevo The Story of Thor 2 también las usa pero cuando estas están sobre otros sprites/patrones.
Limitaciones transparencias Funciones Sombra
Las limitaciones de las funciones sombra quedan perfectamente resumidas en esta tabla que se adjunta en parte de las aclaraciones del Servicio técnico de SEGA en el 23 mayo del 1995:
La siguiente tabla resume las diferencias entre la sombra de MSB y la sombra normal:
| Sombra MSB | Sombra Normal | |
| ¿Tiene penalización de uso? | Ninguna. | Ninguna. |
| ¿Pueden proyectar sombras sobre otros sprites? | Si | No |
| ¿Puede ser mezclado con sprites RGB? | No | Si |
| ¿Pueden diferentes sombras tener diferentes prioridades? | No | Si |
| Tipos de sprites válidos | 2-7 | Todos |
Tendríamos que añadir una ultima limitación a la función de sombra en el VDP2. A nivel de hardware en su pipeline está justo al final como la función color offset. Esto quiere decir que si antes de aplicar el efecto sobre los pixeles marcados como sombra el VDP2 tiene que aplicar Cálculos de Color, anulara la posibilidad de interpretar estos datos. Sin embargo si los cálculos de color son realizados después del cálculo de sombra, esta si funcionara.
También hay que dejar claro que al mezclarse entre ellas, las sombras da igual cual variante. Estas no se mezclaran entre ellas. Al tener el mismo valor de oscurecimiento para todas ellas, incluso en el caso del MSB. Donde estas son procesadas todas juntas como una sola “Screens/Pantallas” separadas de la Screens/Pantallas de Sprites.
Por último señalar, que según la documentación ambas funciones se pueden usar a la vez.
% Juegos con transparencias Funciones Sombra
Terminamos de nuevo con los porcentajes de uso sobre el total de juegos analizados. En este caso usan transparencias con Función Sombra el 9%. De este porcentaje usan transparencias con Función Sombra Normal 7% y de MSB el 2%.
Claramente los desarrolladores se decantan por el primero, ya que es el más versátil y más sencillo de usar. El segundo es difícil de encontrar, aunque de nuevo, siendo justos los desarrolladores que lo usaron lo hacían muy bien.
Conclusiones transparencias Funciones Sombra
La función sombra como venimos diciendo es un técnica que SEGA y sus empleados conocían muy bien. Y la integración en el VDP2 es natural. Quizás peque de reiterativa y de muy limitada en ciertos aspectos.
Lo que si me resulto interesante de esta es el modo MSB. Como en esta función de alguna forma funciona como buscaba. Es decir una forma donde el VDP2 pudiese mezclar varias capas de “transparencia” sobre las partes opacas del VDP1. Es la única función que hace esto en todo el VDP2, con serias limitaciones, es cierto. Pero para mí es un indicativo de la conexión incompleta entra VDPs y el gran potencial que hubiese tenido poder hacer estos procesos de forma tan rápida en el VDP2 y de forma más funcional con el VDP1. Estoy seguro de que los desarrolladores hubiesen usado más el VDP2 y hubiesen conseguido trasladar mejor las diferencias con otros sistemas en esta área tan espectacular.
Ventana/Clipping/Mascaras y Prioridad/”Z-Buffer”
Como también ya he hecho en el VDP1, creo muy necesario hablar de como el VDP2 puede poner encima o debajo elementos, para poder así componer en función de la prioridad o la profundidad de los datos gráficos.
La manera de interactuar con bits especiales permanece. Así pues el MSB será utilizado para marcar la transparencia total o mascara. O el valor 000 o 0000, será interpretado como transparente total. Y 3bits de LSB para la Función Especial de Prioridad.
En el caso del VDP2 esto se aplica a pixels de 16BPP y 24BPP de igual forma. El bit 15 en uno y el bit 23 el otro. Estos bits de transparencia, que muchas veces podemos leerlos como de alpha. No debemos confundir con que el sistema tiene capacidad de alpha blending como ya hemos dicho. Normalmente se usa para hacer mascaras y usar la función ventana del VDP2.
Pero además del MSB en el VDP2 tenemos hasta 3bits para la profundidad o prioridad. Este dato es usado por las funciones específicas de prioridad. En el caso de las Screens/Pantallas con 3bits fijos y pudiendo ser aplicado a distintos niveles: Toda la pantalla, al carácter o al punto.
De nuevo y ahora con más bits, en el VDP2 también llegaríamos a un concepto similar al clipping. Lo que realmente es interesante en el VDP2. Porque con la función de CC+Prioridades se podría tener hasta 8 valores de una especie de “Z-buffer” en modo banco de color con los datos procedentes del VDP1. No así posible para datos RGB que lo dejaría en 1 solo valor.
Justamente lo interesante aquí para mí, sería buscar un forma vía software, de manera mínima y óptima, para poder estos valores de profundidad también con datos RGB procedentes del VDP1.
Conclusiones transparencias del VDP2
Ahora vamos a cerrar el bloque de transparencias posibles por el VDP2 y vamos a ver el conjunto.
Limitaciones Generales en las transparencias del VDP2
Podemos determinar unas limitaciones generales y comunes en todo el VDP2:
- Límite de capas según modo CC
- Límite de capacidad de mezcla según modo de CRAM
- Límite de capacidad de mezcla según tipo de color: RGB o Paleta.
- Límites de funcionalidades según modos especiales: Hi-res o señal externa.
- Uso del MSB. Definición de su valor y posibilidad de usarlo o no.
- Orden de la tubería interna en el proceso de los cálculos en el VDP2.
% Juegos con transparencias VDP2
Terminamos ahora de forma global con los porcentajes de uso sobre el total de juegos analizados para el uso general de transparencias con el VDP2 el 44%.
Vamos a ver ahora el uso en los Exclusivos.
Los juegos 1st party exclusivos son aproximadamente el 22% del total de juegos analizados. De estos el 46% usan transparencias con el VDP2.
Mientras los 2nd party exclusivos suponen aproximadamente el 8% del total analizado, donde el 46% usan transparencias con el VDP2.
Por último los 3rd party exclusivos son aproximadamente el 42% del total analizado. Y vemos hasta un 42% de uso de las transparencias con el VDP2.
Podemos ver como el uso en los exclusivos ni siquiera llega al 50%, para mi decepcionante. Que ni siquiera en los juegos únicos para la máquina haya un uso alto me parece inconcebible. Pero así fue.
Analicemos los que son ports de PSX, que significan el 24% del total. Y vemos hasta un 33% de uso de transparencias con el VDP2 en ellos.
En los ports de PSX de Psygnosis que son 2% del total analizado. Vemos un 13% de uso de transparencias con el VDP2.
Mientras los ports de PSX de EA significan el 5% del total. De los cuales el 60% usaron transparencias con el VDP2.
Vemos que los porcentajes bajan aún más también en el caso de los exclusivos exceptuando en los de EA, que incluso supera en uso a SEGA. Es cierto que % son menos juegos, pero bajo mi punto de vista tiene muchísimo mérito. Y parte de la mala imagen que tuvo para mí EA se ha rectificado con este análisis. Aún más claro queda después de todo esto, la sensación de que SS “no tenía transparencias” cuando ni la propia SEGA lo usaba como debiera. Una pena definitivamente.
Conclusiones transparencias VDP2
Bueno aún no he terminado el punto de transparencias. Pero ha estas alturas podemos ver clarísimamente dos cuestiones:
1) La SS podía hacer transparencias. Y además con una calidad y rendimiento notables.
2) La percepción de que la SS no tuviera o fuera muy malas queda totalmente clara. Hasta la mismísima SEGA no apostó todo lo que debió por resolver este problema para sus consumidores y sus clientes desarrolladores. Es cierto que en SEGA hay expectaciones, y como veremos soberbias. Que llegaron, tristemente tarde y si la expansión y documentación necesaria.
Con respecto a las transparencias del VDP2, como hemos podido ver las opciones son variadas. La complejidad alta. Pero creo que los resultados valen la pena. El VDP2 es capaz de hacer mucho, rápido y con calidad. Es cierto que precio a pagar es alto. Pero de ahí a decir que no se podía hay un universo, bajo mi punto de vista, inasumible.
Otras funciones del VDP2
Ahora vamos a ver otras funciones interesantes que “no son transparencias” pero pueden hacer algo similar.
Calculo de Color por Offset
Esta función también están en la parte final de la tubería del VDP2 como la función sombra. Su principal utilidad está en que es capaz de hacer cambios en los valores RGB entre dos puntos: A y B. Así se configura por Pantalla/Screen esta función. Pudiéndose aplicar a todas las Screen/Pantallas disponibles en todo el VDP2.
Pudiendo hacer transiciones en los valores RGB a 24BPP. Logrando transiciones realmente suaves, y superiores a PS1 ya que esta solo lo podrá hacer en 16bits y con dithering, que no es lo mismo. El modo 24bits de PS1 es solo usable en color directo, podría usarse en este y conseguir degradados de este nivel pero solo en una capa y sin aceleración de la GPU.
La utilidad de esta función puede ser variada. Desde hacer transiciones entre logos, menús o inicio o fin de niveles o eventos de juego. O pintar la pantalla para efectos de daño, muerte, cambios de iluminación o ambiente.
Limitaciones Calculo de Color por Offset
La única limitación que he visto, es cuando la Pantalla de Color por Línea está siendo usada insertada en alguna Pantalla/Screen. Parece que esta es afectada menos y no de igual forma que el resto de datos por el cambio de color de la función.
% Juegos con Calculo de Color por Offset
Es usado prácticamente en todo el catálogo.
Conclusiones Calculo de Color por Offset
Es realmente útil y sencillo. Además con una calidad de color excepcional.
Inserción de la Pantalla de Color por Línea
Esta función está de alguna forma también la final de una parte de la tubería del VDP2, en este caso en la parte de las Pantallas/Screens. Además esta puede ser utilizada por la Función de Cálculo de color Normal o ECC.
Para funcionar realmente esta debe estar insertada en alguna Pantalla/Screen. Si no, no se vera.
Esta función es capaz de pintar, haciendo mezcla aditiva, líneas de colores(diferentes o siempre la misma) de la CRAM encima de las Pantallas/Screens. Siendo capaz de pintar solo en las que sean asignadas o en todas teniendo en cuenta la prioridad de capa una de ellas. Además en el mismo sentido se adaptara a la rotación o la deformación de las pantallas/screens RGBx.
El caso típico de uso seria el efecto de niebla u horizonte en los suelos infinitos de muchos juegos de SS. O efectos de “transparencia” sencillos sobre alguna pantalla/screen como en el agua del Castlevania: Symphony of the Night.
Limitaciones Inserción de la Pantalla de Color por Línea
Como hemos comentado este no se vera afectado por la función de Calculo de Color por Offset.
% Juegos con Inserción de la Pantalla de Color por Línea
La verdad es que es una función que cuesta ser detectada por el estado de los emuladores. Gracias a una última release de Kronos, ahora podemos ver cuando sé esta usando.
Dicho esto yo la he podido ver en un 11% del catálogo. Allí donde sé esta usando el plano rotado infinito con efecto de niebla, siempre será esta.
Conclusiones Inserción de la Pantalla de Color por Línea
Es una función exótica. Como tantas en el VDP2 y la SS. Es realmente útil para los planos rotados infinitos sin duda. Y si quiere conseguir algún efecto de niebla u oscurecimiento lineal horizontal sobre las Pantallas/Screens.
Software+Hardware: VDP1>transferencia>VDP2
Entramos ahora en el mundo más allá del VDP2. Como conseguir con trucos y usando el hardware de la SS, que esta haga mejores transparencias o lo más cercanas a la competencia. Y además sean más usables o fáciles de integrar dentro de la pipeline 3D.
Burning Rangers
Como no hay que empezar por el Burning Rangers. Este efecto o truco esta totalmente indocumentado por parte de SEGA. Al menos en la documentación y SDK que se conocen.
Se habla que Chris Coffin en el Sega Technical Institute en USA, fue quien la desarrollo y asesoro al Sonic Team. O quizás nació de los programadores del Sonic Team. Realmente no lo sabemos.
Lo que sabemos es que llego en el 1998, casi 4 años después del lanzamiento de la máquina.
Se desconocían sus limites. Por lo analizado, por mí y por otras personas que he visto en foros o hablado en Discord ahora tenemos una idea casi exacta de como funciona.
Para mí el mejor método para mejora la calidad, el rendimiento(en parte) pero sobre todo la usabilidad de las transparencias en SS. Ya que es un híbrido entre el software y hardware.
Funcionamiento
En Burning Rangers se crea una «capa» extra para las transparencias de 176×112 puntos en el VDP2, exactamente en el NBG2. Posiblemente usa SCU DMA Directo más el HRAM como pozo intermedio con la VRAM del VDP2. Como lo ha hecho XL2, ya que BR casi seguro usa SGL como base como él. Y XL2 encontró problemas para usar otros DMAs al estar ocupados por SGL.
Esta capa se crea de forma asíncrona junto a los datos opacos. Es cierto que hay algunos datos «transparentes» que se siguen dibujando en la capa «opaca» pero tan solo para la UI.
BR llega a pintar entre estas dos «capas» cerca de 1300 polígonos. En su capa «transparente» unos 300, mitad para las partes transparentes y la otra mitad para las partes de recorte o mascara. De forma general y aproximada.
Limitaciones
La principal está en la cantidad de primitivas y tipos a usar. Más en el caso de BR bajo mi punto de vista, menos en el caso de XL2 como veremos más adelante. Ya que BR primero pinta los elementos transparentes y envia al VDP2. A continuación del envio este sin borrar el FB0 pinta los datos opacos y ya envia estos al FB1. Por lo tanto el timing en los datos transparentes es crucial para el siguiente paso. La ventaja es que se puede asegurar la sincronización de las “capas” en un mismo “instante” o frame. El mayor inconveniente, es que está consumiendo tiempo en dibujar primero lo transparente, enviar para después dibujar lo opaco. Podría jugar a desincronizar los frames entre estas capas, si pasa de un valor de ms. Para compensar. Que de hecho pasa cuando mueves la cámara rápido en escenas cargadas.
La otra limitación es la resolución máxima a enviar. Esta también esta relacionada con el timing. Ya que dados los caminos posibles, el sistema podrá mandar x bits por sg que determinará un límite máximo para que no reste al resto de procesos del conjunto de este algoritmo y del resto de juego, por supuesto. En el caso de BR como hemos dicho, es justo la mitad de ancho y del alto.
Puede que toda esta combinación de limitaciones expliquen los 20FPS de BR, o no. Podrían ser otros factores.
Por último, la limitación más importante, en mi opinión, es como resolver el solape o la profundidad entre piexles transparentes y opacos. Para ello le dedicare un punto especifico a continuación.
Clipping
BR tiene una solución para ello sencilla pero con ciertas limitaciones. Este utiliza primitivas del VDP1 en la misma área del truco para las transparencias pero pintadas en negro absoluto como mascara allí donde estaría una parte opaca. De esta forma cuando todo estos datos pasan al VDP2 no pintara ahí y lo mezclara con la parte opaca en el VDP2 Sprite Screen.
Limitaciones
Varias. El “recorte” o clipping se realizara en menos resolución, siendo el escalonamiento mucho más evidente. Segundo, pintas muchas más primitivas, o incluso llegas a duplicarlas para poder igualar a las opacas y así tener un recorte o solape optimo.
¿Alternativas al clipping de BR?
Como ya se ha dicho antes, buscar la forma de usar las funciones de prioridad por pixel o carácter del VDP2 con la información del VDP1 de la Sprite Screen. Puede que de alguna forma.
¿Limitaciones de esta solución alternativa?
En principio ninguna cara a las transparencias per se. Ya que incluso para elementos opacos intermedios se podrá pintar una primitiva negra entre dos transparentes para mayor precisión de profundidad. Muchas menos que si usamos solo esta vía por el VDP1. Incluso en casos donde sean Billboards se podría usar el H-T VDP1 para que haya una mezcla correcta entre estos elementos de máscara intermedios. Después el VDP2 con su mezcla aditiva lo mezclara todo correctamente.
No es el caso de BR, de hecho este limita los elementos de máscara mucho. Provocando el fallo en el clipping en muchas ocasiones y evidentes.
Implementación de XL2
XL2 utiliza parte del Framebuffer que queda fuera de la parte visible, para pintar con el VDP1 los elementos que son transparentes.
De manera similar al BR, después/o durante del/el dibujo en el VDP1 envia todo/parte del área del VDP1 al NBG1 del VDP2 via SCU DMA(Directo o Indirecto o SCU-DSP DMA).
Y después escala con la función del VDP2 la información del Screen para igualar el área final con el original.
Funcionamiento
XL2 hace una implementación basada en BR pero con importantes cambios. XL2 utiliza parte del Framebuffer que queda fuera de la parte visible, para pintar con el VDP1 los elementos que son transparentes. En vez de esperar a acabar de pintar la parte opaca o la transparente para pintar en un “nuevo FB”. Aprovecha el mismo FB para pintar en todo el área disponible. Primero pinta todo lo transparente. A continuación pinta lo opaco y a la vez de manera paralela va enviando las líneas pintadas de los pixeles “transparentes”. De manera similar al BR, enviá en su caso al NBG0 del VDP2 vía SCU DMA Directo utilizando la HRAM como pozo intermedio. Ya que no es posible usar otros DMA al esta ocupados por SGL. Y en principio no es posible enviar mediante DMA del B-Bus al B-Bus directamente.
Y después escala con la función del VDP2 la información del Screen para igualar el área final con el original.
XL2 dibuja las primitivas que serán transparentes en el espacio libre en el FB0 fuera de la zona visible. A la vez va mandando línea a línea en los huecos libres entre pintado y pintado de la parte opaca del VDP1. Mediante el SCU DMA Directo y usando el HRAM como pozo intermedio. Para finalmente almacenarlo en la VRAM del VDP2.
En su caso 160×112, es decir 160 líneas de 112 pixeles de 16bits. 224Bytes o 112 transferencias de 16bits. En el caso de B son 176 líneas, 16 líneas más. 1792 transferencias menos en el caso de XL2. 17.920 transferencias totales.
En ambos casos se enviá esta área de pixeles a una Screen/Pantalla del VDP2 y se escala a la resolución total en “X” y “Y”. Se activa el modo “as-is” de la función calculo de color del VDP2 y se pone en una prioridad superior a la Sprite Screen o pixeles opacos.
En el caso de XL2 activa y configura el ECC para poder usarlo junto a otras Screens/Pantallas con CC. En su caso él tiene el cielo en RGB1 transparente. Y consigue mezclar el cielo, con las transparencias de la capa BR y elementos del Sprite Screen detrás del cielo.
Clipping
XL2 usa la misma solución que Burning Rangers. Duplica los elementos opacos, usando uno igual pero negro total en el área “transparente” en el orden de profundidad adecuado. En su caso en zonas especificas del mapa y en todos los elementos de la mano/arma en primerísimo plano. Me consta que tiene idea de mejorarlos, usando las prioridades del VDP2 como hemos hablado al menos en la mano/arma, porque además quiere usar el efecto metálico del truco del Gouraud en el VDP2 como la demo de SGL de Akira.
Limitaciones
Prácticamente las mismas que BR. Con la gran mejora de usar el mismo FB para datos opacos y transparentes.
Alternativas las mismas que para BR.
Conclusión
XL2 no solo implemento la solución de BR. Además tuvo que lidiar con la realidad de implementarla. Y lo supero, además de mejorar el original aprovechando aún mejor la SS. Además a añadido elementos con Semi-Transparencia VDP1 en el área para transferir. Teniendo efectos de Lente espectaculares y NUNCA vistos en el sistema. Además de mezclar estos con efectos de agua. Espectacular es poco.
Grandia: Batallas
Funcionamiento
Grandia utiliza un método totalmente original. Hasta donde he podido ver en mi análisis del catálogo de SS.
Este envia los sprites solo cuando se actualizan a la capa NBG1, carácter a carácter. Presumiblemente como en el caso de XL2, o BR, mediante el SCU DMA(Directo o Indirecto o SCU-DSP DMA).
Por otra parte dibuja varios elementos en el VDP1 que esta por encima de esta capa como: Parte de la UI y efectos de partículas. Es curioso por que algunos elementos de la UI los dibuja como mesh, posiblemente como «segunda capa de transparencia», para que esta no cubra los elementos que son transparentes debajo.
Clipping
Problema de clipping, no existe porque solo pone encima todo o abajo. Al ser “2D” es más sencillo de resolver.
Limitaciones
Realmente las normales del VDP1 y VDP2. El programador de las batallas de Grandia simplifica la transferencia al máximo para enviar solo lo necesario al VDP2 desde el VDP1. Además deja la mayoría de los datos en el VDP1, lo cuales serán para los efectos de transparencia. Justa al revés que el efecto de Burning Rangers. También es cierto que el problema es más sencillo al ser gráficos “2D”.
Conclusión
El equipo de Game Arts de Grandia, y como el resto de títulos de Game Arts, demuestran su buen hacer en SS y su conocimiento extenso y profundo. Y así lo plasman en este truco para poder tener la mayor cantidad de transparencia al mínimo costo de proceso y con la máxima calidad del sistema, las del VDP2.
Arcana Strikes
Este juego hace algo parecido a Grandia. En las batallas cuando lanza una magia, transfiere los sprites a una Screen/Pantalla de VDP2, tiene un pequeño retardo que se nota. Y pinta las transparencias con una Screen superior. Tambien de finales del 1997 como Grandia. No llega al nivel de elaboración de los anteriores. Pero si es significativo el intento de los desarrolladores.
Limitaciones transparencias VDP1>transferencia>VDP2
Terminamos con un resumen de las limitaciones de estos trucos. Como vemos básicamente serian 2:
1) La cantidad de datos a transferir. Lo cual implicara más o menos resolución o elementos a enviar.
2) Como resolver los problemas de solapes o clipping. Más complicado en 3D, y más sencillo en 2D de resolver.
% Juegos con transparencias VDP1>transferencia>VDP2
Como vemos pocos, pocos locos o valientes se atrevieron a ir tan lejos en este tema en SS. 2 juegos en todo el sistema. No llega apenas a un 0,7% del total de juegos analizados.
Conclusiones transparencias VDP1>transferencia>VDP2
Bueno la conclusión es clara. Era la mejor forma de tener las mejores transparencias en el sistema. En cantidad, calidad y rendimiento. El problema, era el precio a pagar. SEGA no ayudó a proporcionar esta vía de forma rápida y sencilla. Y claro, para que complicarse así la vida. Supongo que el Sonic Team siendo fisrt party y Game Arts al tener una base en Japón tan grande vieron viable llegar tan lejos. Más vale tarde que nunca, como dice el refrán.
Para la comunidad homebrew es un camino muy atractivo para explorar. Porque todos los usuarios de SS anhelamos esta feature y muchos estábamos convencidos de que era posible hacer más. XL2 así lo ha demostrado, ahora esperamos que vengan más y lleguemos a rematar esta vía para hacer perfecta.
Por software:
VDP1
Seria posible renderizar elementos transparentes y/u opacos por software vía CPU y se enviá a un pattern/patrón en el VDP1 o al Framebuffer.
Soul Hackers Devil Summoner hace un pequeño truco en el mapa. @mrkiso lo comento durante mi redacción de este punto en Discord, y lo vi como otro caso de efecto para “transparencia” por software. Cuando el cursor del jugador está tapado por un elemento superior. Por código corta en la textura, haciendo un agujero, y en el siguiente comando utiliza la misma textura(sin recortar) junto a la Semi-Transparencia del VDP1. Creando un efecto muy interesante.
Sonic R lo que hace es renderizar elementos texturizados opacos por software vía CPU lo enviá a un pattern/patrón en el VDP1. En este caso para recrear el “environmental mapping” a nivel de coordenadas UV, para al final usar la Semi-Transparencia del VDP1 para mezclar con la base opaca. Esto se puede ver en la R 3D en los títulos de inicio.
Scorcher y Die Hard Trilogy(en el juego del coche solo) lo que hacen es renderizar elementos texturizados y modulando multiplicativamente más una mezcla aditiva final sobre el frame-buffer para crear semi-transparencias. Ahora mismo son los únicos conocidos, abriendo la posibilidad de que si se hiciera incluso más.
Die Hard Trilogy rasteriza la primitiva con el propio VDP1 en la zona libre del framebuffer justo al final de la lista de comandos, y después será leída y mezclada en las coordenadas finales sobre el framebuffer. Este no deja zonas negras, porque todo el juego 3D está siendo dibujado en el VDP1.
Mientas Scorcher rasteriza todo vía software. Este deja zonas con niveles de negros contra el Framebuffer vació, donde el VDP2 dibujara. Si estos negros se pudieran marcar con los bits de registro para el ratio y priority de CC del VDP2, seria posible mezclar con el VDP2 como lo hace Guardian Heroes o FIFA 98.
Die Hard Trilogy sin embargo no presenta estos halos negros. Posiblemente, y falta de poder investigar más, porque se dibuja todo el 3D con el VDP1, incluidos los fondos. Y la mezcla por software es completa. El resultado como en Scorcher es que cuando hay mucha área con el efecto en pantalla se produce una bajada muy grande de los FPS, incluso degradando la jugabilidad. Es el caso de cuando un coche enemigo está en llamas delante de ti, por debajo de 10FPS en este caso.
VDP2
Seria posible renderizar elementos transparentes y/u opacos por software vía CPU y se enviá una Screen del VDP2. Y lo más próximo que he visto es en Amok pero que usa un tipo mesh como el del VDP1 pero por software.
VDP1 Sprite Screen + VPD2 Screens
En principio, no seria posible mezclar por software transparencias entre el VDP1 y el VDP2 al ser sistemas que funcionan por algoritmos cerrados y diferentes. O dentro solo del VDP2, ya que este lo dibuja todo en tiempo real, “sin frame buffer”.
Se podría intentar marcar los pixeles que se dibujan sobre el “fondo del frame-buffer”. O incluso buscar correspondencias de color para resultados en las CC del VDP1 y pasarlas a la CRAM del VDP2 y a la vez dejar los datos en el framebuffer como Color Banks para el VDP2.
Clipping o Prioridad/”Z-Buffer”
Como ya he comentado antes, en varias ocasiones, seria posible mediante software conseguir hacer que valores RGB procesados en el VDP1 pasen al VDP2 como colores de la CRAM para poder ser procesados por su función de prioridad y así poder superponer las partes opacas y transparentes para conseguir un efecto de mejor calidad y precisión, con un coste de proceso bajo por parte del VDP2.
% Juegos con transparencias software
El % conocido de juegos que usan el camino de software es muy bajo. Solo conocemos a ciencia cierta 4 títulos que hagan uso de un pipeline lo más pura vía software. Eso significa un 1,24% de total de juegos analizados.
Limitaciones transparencias software
La principal obtener un código lo suficientemente optimo el cual tiene que leer datos de diferentes pozos y por diferentes buses. Además de por diferentes procesadores y memorias a distintas velocidades y tamaño de datos/palabras. Y por último integrarse en toda la tubería grafica, sobre todo en el timing y la dirección de los procesos, Léase:
SH2+RAM<->SCU<-> VRAM+VDP1+FB0-> FB1-> Sprite Screen VDP2+VDP2-> Salida TV
Si todo esto no esta dentro de un timing final entre 8 y 16ms, o incluso menos, la penalización será alta y difícilmente el juego se moverá a 25FPS o más.
Por supuesto si el algoritmo necesita RAM o VRAM, o ambas. Además de necesitar un % de procesos de los procesadores implicados. Esta cogerá un % de ancho de banda de los buses y por supuesto espacio de la VRAMo RAM que necesite usar.
Por último también puede usar algún DMA del sistema en % de tiempo lo cual será otro factor a tener en cuenta en toda está compleja ecuación.
Conclusiones transparencias software
Como vemos no es una tarea sencilla. Y las posibilidades de que no sea optimo son muy altas.
De hecho en los ejemplos encontrados, pocos, reales funciona muy justo. Y cuando sube la cantidad de información a procesar de forma media, el rendimiento cae. Es decir lo ms finales de los procesos suben mucho.
Como reto y objetivo es alentador. La SS tenia está gran “ventaja”. Daba mucha ventana a buscar formas de hacer “más” cosas.
Para acabar. Un camino único de software, en mi honesta opinión, me parece demasiado. Para elementos pequeños 2D puede ser muy útil y posiblemente optimo. Pero para grandes áreas o cantidades lo veo innecesario, pudiendo usar otros caminos híbridos sumando al propio hardware en algún punto de la tubería donde este sea mejor.
Resumen de las posibilidades de “transparencias” en SS:
1.Mesh
1.1 VDP1
1.1.1 Hardware
1.1.2 Software o en patrón/textura
1.2 VDP2
1.2.1 Mesh: Software o en patrón/textura
2. VDP1
2.1 Funciones de Calculo de color
2.1.1 Sombra
2.1.2 Semi-Transparencia
2.1.3 Semi-Transparencia+Gouraud
2.2 Clipping/Mascaras
3. VDP2
3.1 Funciones de Calculo de color Normal / Extendido (ECC)
3.1.1 VDP2 Screens/Pantallas
3.1.1.1 Ratios definidos
3.1.1.2 “as is = CCMD(1,1)”
3.1.2 VDP1 Sprite Screen + VPD2 Screens
3.1.2.1 Condición de Calculo de Color
3.1.2.1.1 Prioridad ≥ = ≤ Número de Condición para CC(Calculo de color)
3.1.2.1.2 MSB de Datos de Color
3.1.2.2 Función Sombra:
3.1.2.2.1 Sombra MSB
3.1.2.2.2 Sombra Normal
3.1.2.3 Ventana/Clipping/Máscaras y Prioridad/”Z-Buffer”
3.2 Calculo de Color por Offset
3.3 Inserción de la Pantalla de Color por Línea
4. Software+Hardware: VDP1>transferencia>VDP2
4.1 Burning Rangers
4.1.1 XL2 Engine
4.2 Grandia: Batallas
4.3 Clipping o Prioridad/”Z-Buffer”
5. Por software.
5.1 VDP1
5.2 VDP2
5.3 Clipping o Prioridad/”Z-Buffer”
¿Pero cuántas transparencias podemos tener activas por hardware y que se mezclen correctamente?
Esto va a depender principalmente en el orden en el que se procesan los datos. Desde su origen hasta el final de toda la tubería de los VDPs y entre ellos.
En segundo lugar, de las restricciones existentes habladas: color, tipo de dato, tipo de proceso… Pero primer vemos la cantidad de capas que permite cada posibilidad en VDP1 y VDP2 por separado:
OK=Funciona ; KO=No funciona
VDP1
- Mesh Hardware = 1 capa + OK con VDP2
- Mesh Software-Patrón/Textura = “Infinitas capas ” + OK con VDP2
- CC(H-T/Shadow) = Infinitas capas + KO con VDP2
- Software = “Infinitas” + KO con VDP2
- Variante no vista: Que marque los pixeles contra VDP2 como CRAM CC+Prioridad.
VDP2
- Mesh Software-Patrón/Textura = “Infinitas capas”
- CC Normal = 1 capa o CC Extendido = “4 Capas”
- VDP1+VDP2
- CC + Prioridades = 1 capa
- Sombra Normal = “ + 1 Capa”
- Sombra MSB = “Infinitas”
- VDP1+VDP2
- Color Offset = “ hasta 8 Capas + ”
- Line Color Screen Insertion/LCS = “ hasta 8 Capas + ”
Como podemos ver hay varias combinaciones posibles dentro de la pipeline normal, pero la más versátil seria:
VDP1[Mesh Hardware + Mesh Software-Patrón/Textura + CC(H-T/Shadow)] >> VDP2 CC Extendido[Mesh Software-Patrón/Textura + Sombra Normal+Color Offset+LCS] = “Infinitas” + Mesh
- La cual estaría limitada por los tipos de color usados en el VDP1 para la función de CC+Prioridad del VDP2 y los modos de dicha función.
- Y la Sombra normal debería ser procesada antes que el CC.
- Evitar degradado negros en segunda capa de ECC.
Ahora si sumamos el truco de BR a la tubería:
VDP1 + [VDP1+VDP2] + [VDP1>Transferencia>VDP2] + VDP2 = “Infinito – Mesh”
- Heredas:
- La casuística propia del VDP1 pero ahora OK con VDP2.
- Casuística anterior:
- La cual estaría limitada por los tipos de color usados en el VDP1 para la función de CC+Prioridad del VDP2 y los modos de dicha función.
- Y la Sombra normal debería ser procesada antes que el CC.
- Evitar degradado negros en segunda capa de ECC.
- Simplificamos los problemas de color en los datos de transparencia para el VDP2.
- Podemos tener separados datos transparentes de opacos en dos Screens del VDP2.
- Al menos con dos prioridades distintas.
- Aumentamos la calidad(aditiva real final) y velocidad de cálculo de la transparencia para grandes áreas.
- Evitamos el problema de redibujo en elementos 3D y podemos hacer transparencia con ellos.
- Quitamos por fin al mesh de en medio. Al menos para los primeros planos o cosas grandes.
- Menos resolución efectiva potencial. Si no usas un camino como Grandia: Transferir solo tiles/caracteres específicos.
- Tienes el problema del clipping el cual:
- En 3D lo tienes casi seguro. En juegos 2D menos o nada, según el diseño.
- Dibujas más elementos para máscara. Lo cual te penaliza en el VDP1 algo más.
- O buscas que lo haga el VDP2 como hemos hablado. Más fácil en 2D y 3D con colores CRAM. Más complicado y limitado con colores RGB.
Las “prohibiciones o limitaciones” que “no lo son”
Espacios de color sobre elementos origen en CC VDP1: En teoría los CC del VDP1 están restringidos en origen a datos RGB. Pero podemos ver en muchos juegos usar Color Bank, tanto para Semi-Transparencia como Gouraud o los dos combinados. Bien es cierto que en su mayoría sobre polígonos con un color plano. Lo cual puede tener sus ventajas en la calidad de los degradados que da el VDP2 hasta 24bits. Pero incluso he llegado a ver un caso de usar sobre un elemento de origen con patrón/textura, bien es cierto que es difícil apreciar si funciona o no. Pero plantea caminos para investigar.
Usar CC y prioridad con elementos que no son color bank desde el VDP1: He visto un ejemplo donde se usa Color LUT para después aplicar efectos de la unidad VDP2 de CC y prioridad sobre estos datos.
Estas situaciones no están documentadas, o usadas muy poco. Puede que sean motivo de investigación por sus ventajas a la hora de aprovechar mejor la conexión entre VDPs y simplificar el uso de ellos, con limitaciones seguro, pero por hoy desconocidas.
Posibles soluciones para las limitaciones:
Soluciones vía software:
Salvar limitación no transparencia entre VDP1 y “VDP2” con H-T de VDP1.
-
- El problema real es que el VDP1 no sabe cuando está dibujando contra el fondo del framebuffer o sobre un pixel ya pintado. De esta forma y análogamente el VDP2 tampoco. Si se pudiese marcar mediante un algoritmo en tiempo real que lea pixels o grupos de pixeles(8×8 por ejemplo) del framebuffer marcados con un color de máscara o característico. Y que este proceso cuando lo detecte marca, cambien los datos del pixel a un color bank(color bank+character data) con valores de CC y prioridad determinados en la CRAM del CRAM.
- Análogamente para poder usar aspectos de la unidad VDP2 de la pantalla de Sprites y su función de CC y prioridad para otras necesidades. Como desde pixeles origen RGB pero que queremos usar para CC o prioridad, una solución similar seria la posible.
Salvar problema de redibujado VDP1.
-
- Rasterizar vía software y volcar en una primitiva el resultado en forma de patron+colores resultado.
- Rasterizar vía VDP1 en la zona libre del framebuffer y volcar en una primitiva el resultado en forma de patron+colores resultado.
Salvar problema de falta de máscara y modulación multiplicativa más mezclado aditivo del VDP1.
-
- Rasterizar vía software y mezclar contra el framebuffer directamente. Muy lento, valido para areas patrones y area pequeñas. Si se necesita más grande utilizar el modo “capa BR avanzada” mediante VDP2
- Rasterizar vía VDP1 en la zona libre del framebuffer y mezclar contra el framebuffer directamente. Muy lento, valido para áreas patrones y área pequeñas. Si se necesita más grande utilizar el modo “capa BR avanzada” mediante VDP2
Más modos CLUT.
-
- Lo veo complicado. VDP1 almacena vía hardware lista de 4BPP. No se si se podrían enlazar de alguna manera, o alterar el boundary para tener 16x 4bit CLUT = 8bit CLUT. Y asi disponer de 256 colores sobre una paleta de 16bit o incluso poder enlazarla con su símil en el VDP2 como la de 4bits CLUT.
Cambios en el hardware:
Salvar limitación no transparencia entre VDP1 y “VDP2” con H-T de VDP1.
-
- Con dos MSB en vez de uno. MSB1 y MSB2. Para identificar “transparencia destino” de cada unidad. MSB1 para el VDP1 y MSB2 para la del VDP2. La parte no escrita del framebuffer del VDP1 seria igual al VDP2, es decir MSB2=1.
- Y un registro como el MSBon para pasar a 1, igual pero para pasar a 0(Color Bank) desde 1(RGB).
Salvar problema de redibujado VDP1.
-
- Añadir al algoritmo de pintado general del VDP1 que vaya marcando en 1 bit del pixel/texel cuando ha pintado ya en el proceso. Cuando vuelva a pasar por un pixel/texel marcado saltara al siguiente pixel/texel.
Salvar problema de falta de máscara y modulación multiplicativa más mezclado aditivo del VDP1.
-
- Copiar tecnología de CC de VDP2 en el VDP1. ¿Porque no se hizo?
Más modos CLUT.
-
- Añadir 8BPP y 11BPP CLUT como en VDP2 en el VDP1.
¿Al final se consiguió arreglar esta situación de desventaja?
A pesar de todos los grandes inconvenientes, en este caso más que en otros, SI, pero solo en parte. Siendo muy mejorable en general. Hagamos un breve resumen según parties:
Por las First parties de SEGA claramente. Sonic Team, Team Aquila y Team Andromeda. Llevaron la máquina al límite con diferentes resultados. Para mi los más notables y que ponían el listón al nivel de PSX o en algunos casos más: El Sonic Team con Burning Rangers, el Team Andromeda con Panzer Dragoon Saga y el Team Aquila con la saga SEGA World Wide Soccer.
Semi-Transparencias de múltiples formas, la mejor sin duda la de Burning Rangers.
Por las Second parties encontramos a Treasure con Guardian Heroes, Silhouette Mirage y Radian Silvergun. Sonic! Software Planning con Shining Force III y Shining the Holy Ark. Traveller’s Tales con Sonic R. Realtime Associates con la saga Bug!. Jumpin’ Jack Software con Ghen War, Congo y Pandemonium!
Finalmente las Third parties Gremlin con Loaded. Attention To Detail con Blast Chamber. Microcabin con Blazing Heroes / Mystaria: The Realms. Nextech con Battle Arena Toshinden Saga, D-Xhird, Resident Evil…y muchos más. Como Altron con Tadaima Wakusei Kaitakuchuu!, Robo-pit, Mighty Hits, y otros más.
Hay muchisimos ejemplos más de cada party. Solo trato de exponer los mejores a mi juicio y de forma resumida.
Ahora una lista por orden cronológico más detallada según los tipos de transparencias usados en una selección de títulos donde los he podido detectar, he omitido las que usaron mesh porque realmente no tienen mayor interés en este análisis:
VDP1
Funciones de Calculo de color
- VDP1 CC Sombra
1995
-
- Blazing Heroes (U) / Mystaria: The Realms (E)
- Ghen War
- Gex
- Devil Summoner: Shin Megami Tensei
1996
-
- Congo: The Movie – The Lost City of Zinj
- Return Fire
- Dark Savior
- Exhumed (E) / Powerslave (U)
- The Incredible Hulk – The Pantheon Saga
- Blast Chamber
- Grid runner
- Bug too!
- Black Dawn
1997
-
- J League – Go Go Goal!
- Duke Nukem 3D
- Nascar 98
- Quake
- Ninpen Manmaru
1998
-
- Sokko Seitokai Sonic Council
VDP1 CC Semi-Transparencia
1994
- BIOS
1995
- Panzer dragoon→ Weapon trails
- Robotica: Cybernation Revolt (1995)→explosiones y UI principalmente, no se ven tramas
- Blazing Heroes (U) / Mystaria: The Realms (E)
- Nekketsu Oyako
- Bug!
- From TV Animation Slam Dunk: I Love Basketball
- Victory Boxing
- Ghen War
- Tadaima Wakusei Kaitakuchuu!
- Battle Arena Toshinden Remix
- Highway 2000 (U)(E) / Wangan Dead Heat (J)
- Gex
- Titan Wars (E) / Solar Eclipse (U)
- Black Fire
- Devil Summoner: Shin Megami Tensei
1996
- Robo-Pit
- Wipeout
- Congo: The Movie – The Lost City of Zinj
- Criticom
- Magic Carpet
- Return Fire
- Virtual Golf
- Keio Flying Squadron 2 (1996) (2D)→En todos los destellos, explosiones y efectos de partículas, no se ve ni un mesh.
- Lifescape – Seimei 40 Okunen Haruka na Tabi Disc 1
- Lifescape – Seimei 40 Okunen Haruka na Tabi Disc 2
1996
- Loaded
- Impact Racing
- NiGHTS into Dreams
- Shockwave Assault
- Road Rash
- Destruction Derby
- Terry Pratchett’s Discworld
- Tokusou Kidoutai J SWAT
- Dark Savior
- Olympic Soccer
- Wangan Dead Heat + Real Arrange
- Actua Golf
- Casper
- Policenauts
- Exhumed (E) / Powerslave (U)
- Space Hulk: Vengeance of the Blood Angels
- Tunnel-B1
- Bottom of the 9th
- Mighty Hits
- Tomb Raider
- The Incredible Hulk – The Pantheon Saga
- Blast Chamber
- Grid runner
- PGA TOUR 97
- Fighting Force (Judgement Force)
- NBA Jam Extreme
- Bug too!
- NHL 97
- Black Dawn
- Andretti Racing
- Shining the Holy Ark
1997
- Amok
- Soviet Strike
- Pandemonium →Sombra, efectos especiales de brillos o partículas, no se ven tramas, si opacas)
- Scorcher→Humo verde o polvo. Casi seguro que es VDP1 H-T cuando estas en primera persona en la máquina real hay relentizaciones muy fuertes.
- HEXEN
- Battle Stations
- D-Xhird
- Welcome House
- Swagman
- Sonic Jam
- Ferox
- Terra Cresta 3D
- Discworld II – Missing, presumed…
- Assault Rigs
- G-Vector
- Layer Section II
- Nascar 98
- Sonic R
- Vandal Hearts
- Quake
- Shining Force III Scenario 1 / 2 / 3 / Premium
- FIFA 98→Campo indoor, cristales.
- Grandia →Sombras, agua, humo chimenea, destello cinemática
1998
- Jung Rhythm
- Solo Crisis
- Panzer dragoon Saga
- Burning Rangers
- Choro Q Park
- Akumajo Dracula X: Gekka no Yasokyoku (aka: Castlevania: Symphony of the Night)
- Lupin the 3rd Pyramid no Kenja
- Wachenröder
- Genso Suikoden
VDP2
Función Cálculo Color Normal
VDP2 Screens/Pantallas
Ratios definidos:
1994
- SEGA GAME SAMPLE 1 For SBL 1.1
- Magic carpet ; CC priority and ratio / Normal / MSB Shadow demo; Color Line Screen Demo ; Windows VDP2 and screens demo
1995
- Panzer Dragoon
- Cyber Speedway
- From TV Animation Slam Dunk: I Love Basketball
- Rayman
- Wing Arms
- Ghen War
- Double Switch
- Dragon Ball Z: Shin Butōden
- Battle Arena Toshinden Remix
1996
- Guardian Heroes
- Sea Bass Fishing
- Congo: The Movie – The Lost City of Zinj
- Linkle Liver Story
- Panzer Dragoon II Zwei
- Dragon Force
- Magic Carpet
- True Pinball
- Skeleton Warriors
- The Story of Thor 2 / The Legend of Oasis / Thor: Seireioukiden
- Keio Flying Squadron 2
- Dragon Ball Z: Idainaru Dragon Ball Densetsu
- Alien Trilogy
- NiGHTS into Dreams
- Decathlete / Athlete King
- Road Rash
- Albert Odyssey
- Tokusou Kidoutai J SWAT
- Blam Machinehead
- Dark Savior
- NBA Action 96
- Exhumed (E) / Powerslave (U)
- Lunar – Silver Star Story CPK / Lunar – Silver Star Story MPEG-ban o Complete
- Sexy Parodius
- 3D Baseball
- PriCla (Princess Clara) Daisakusen
- Street Racer (Extra)
- Fighting Force (Judgement Force)
- Cyber Troopers Virtual-On
- Sega WorldWide Soccer 97 / Victory Goal ’96
- NBA Jam Extreme
- Bug too!
- Vatlva
- Black Dawn
- Shining the Holy Ark
1997
- Amok
- Fighting Illusion K1 Grand Prix
- Sonic 3D Flickies’ Island
- Soviet Strike
- Assault Suit Leynos 2
- Gundam Side Story 3 / Kidou Senshi Gundam Gaiden III: Sabakareshi Mono
- Scud The Disposable Assassin
- Manx TT
- Tempest 2000
- Doom
- MechWarrior 2: 31st Century Combat
- NBA Live 97
- Touge King the Spirits 2
- D-Xhird
- Swagman
- Sonic Jam
- Samurai Shodown RPG
- Trash It
- Bulk Slash
- Thunder Force V
- Darklight Conflict
- Resident Evil
- Last Bronx
- Rockman X4 (Mega Man X4)
- Terra Cresta 3D
- Madden NFL 98
- Desire
- Silhouette Mirage
- Croc: Legend of the Gobbos
- WipEout 2097
- Söldnerschild / Soldnerschild
- The Lost World Jurassic Park
- Asuka 120 Burning Fest
- Sega Worldwide Soccer 98 / J. League Victory Goal ’97
- Steep Slope Sliders
- Nascar 98
- J.League Pro Soccer Club o Tsukurou! 2
- Mass destruction
- Sonic R
- Quake
- Princess Crown
- Shining Force III Scenario 1 / 2 / 3 / Premium
- FIFA 98
- NBA Live 98
- Grandia
- Ninpen Manmaru
1998
- Chill
- Sokko Seitokai Sonic Council
- Winter Heat
- Burning Rangers
- Sega Ages – Power Drift
- Stellar Assault SS
- My Fair Lady Virtual Maajan
- Dragon Force II
- Savaki
- Gungriffon II
- Baroque
- MeltyLancer Re-inforce
- World League Soccer 98
- Lunar 2 – Eternal Blue
- Pro Yakyuu Greatest Nine ’98 Summer Action
- Genso Suikoden
- Sorvice
- Cotton boomerang
2000
- Final Fight Revenge
Modo “as is” (difícil de detectar lista incompleta o inexacta)
- Grandia
- Burning Rangers
Ventana/Clipping/Mascaras y Prioridad/”Z-Buffer”
-
Window W0/1 Activada:
1995
-
- Virtua Fighter 2
- Titan Wars (E) / Solar Eclipse (U)
- Sega Rally Championship
1996
-
- Sea Bass Fishing
- Panzer Dragoon II Zwei
- Pro-Pinball: The Web
- Wangan Dead Heat + Real Arrange
- Casper
- Fighting Force (Judgement Force)
- Shining the Holy Ark
1997
-
- Assault Suit Leynos 2
- Gundam Side Story 3 Kidou Senshi Gundam Gaiden III: Sabakareshi Mono
- Independence Day
- Doom
- FIFA 97
- Formula Karts
- Moon Cradle
- Terra Cresta 3D
- Croc: Legend of the Gobbos
- DoDonPachi
1998
-
- BATTLE GAREGGA
- My Fair Lady Virtual Maajan
- MeltyLancer Re-inforce
- Initial D: Koudou Saisoku Densetsu
- Deep Fear
- Wachenröder
- Capcom Generations 1
- Cotton boomerang
- Capcom Generations 4
1999
-
- Street Fighter Zero 3
2000
-
- Final Fight Revenge
-
Special Priority Mode 1 por pixel Activado:
- Sega Rally Championship (1995-12-29)
- Guardian Heroes (1996-01-26)
- Wipeout (1996-02-29)
- The Story of Thor 2 / The Legend of Oasis / Thor: Seireioukiden (1996-04-26)
- Keio Flying Squadron 2 (1996-05-17)
- Rockman 8 (1997-01-17)
- Tempest 2000 (1997-03-20)
- Metal Slug (1997-04-04)
- Rockman X4 (Mega Man X4)
- Silhouette Mirage (1997-08-01)
- DoDonPachi (1997-09-18)
- Princess Crown (1997-12-11)
- Real Bout Fatal Fury Special (1997-12-23)
- Sokko Seitokai Sonic Council (1998-01-29)
- BATTLE GAREGGA (1998-02-26)
- Akumajo Dracula X: Gekka no Yasokyoku (aka: Castlevania: Symphony of the Night) (1998-06-25)
- Street Fighter Zero 3 (1999-08-06)
- Albert Odyssey (1996-08-09)
-
Special Priority Mode 2 por tile Activado:
- Lunar – Silver Star Story CPK / Lunar – Silver Star Story MPEG-ban o Complete (1996-10-25)
- Assault Suit Leynos 2 (1997-02-21)
- Grandia (1997-12-18)
VDP1 Sprite Screen + VPD2 Screens
Condicional y/o Prioridad + Ratio:
-
Cálculo de Color = Prioridad ><== CC Número Condición.
1994
-
- SEGA GAME SAMPLE 1 For SBL 1.1
- Magic carpet ; CC priority and ratio / Normal / MSB Shadow demo; Color Line Screen Demo ; Windows VDP2 and screens demo
- SEGA GAME SAMPLE 1 For SBL 1.1
1995
-
- Cyber Speedway
- From TV Animation Slam Dunk: I Love Basketball
- Rayman
1996
-
- Guardian Heroes
- Sea Bass Fishing
- Dragon Force
- True Pinball
- The Story of Thor 2 / The Legend of Oasis / Thor: Seireioukiden
- Keio Flying Squadron 2
- Dragon Ball Z: Idainaru Dragon Ball Densetsu
- Albert Odyssey
- Blam Machinehead
- Lunar – Silver Star Story CPK Lunar – Silver Star Story MPEG-ban o Complete
- Sexy Parodius
- PriCla (Princess Clara) Daisakusen
- Fighting Force (Judgement Force)
- Sega WorldWide Soccer 97 / Victory Goal ’96
- NBA Jam Extreme
- Vatlva
- Shining the Holy Ark
1997
-
- Fighting Illusion K1 Grand Prix
- Assault Suit Leynos 2
- Scud The Disposable Assassin
- Tempest 2000
- Doom
- Touge King the Spirits 2
- D-Xhird
- Swagman
- Samurai Shodown RPG
- Trash It
- Bulk Slash
- Thunder Force V
- Darklight Conflict
- Resident Evil
- Last Bronx
- Terra Cresta 3D
- Madden NFL 98
- Söldnerschild / Soldnerschild
- The Lost World Jurassic Park
- Asuka 120 Burning Fest
- Sega Worldwide Soccer 98 / J. League Victory Goal ’97
- Steep Slope Sliders
- Nascar 98
- Mass destruction
- Sonic R
- Princess Crown
- Shining Force III Scenario 1 / 2 / 3 / Premium
- FIFA 98
- Grandia
1998
-
- Chill
- Sokko Seitokai Sonic Council
- Sega Ages – Power Drift
- Stellar Assault SS
- Savaki
- Gungriffon II
- MeltyLancer Re-inforce
- Lunar 2 – Eternal Blue
- Pro Yakyuu Greatest Nine ’98 Summer Action
- Genso Suikoden
- Sorvice
- Cotton boomerang
2000
-
- Final Fight Revenge
-
Cálculo Color Condicional = Datos Color MSB
1995
-
- Ghen War
- Double Switch
- Dragon Ball Z: Shin Butōden
- Congo: The Movie – The Lost City of Zinj
1996
-
- Linkle Liver Story
- Magic Carpet
- NiGHTS into Dreams
- Decathlete / Athlete King
- Road Rash
- Tokusou Kidoutai J SWAT
- NBA Action 96
- 3D Baseball
- Street Racer (Extra)
1997
-
- Soviet Strike
- MechWarrior 2: 31st Century Combat
- Touge King the Spirits 2
- Sonic Jam
- Silhouette Mirage
- J.League Pro Soccer Club o Tsukurou! 2
- NBA Live 98
1998
-
- Winter Heat
- My Fair Lady Virtual Maajan
- Dragon Force II
- Baroque
- World League Soccer 98
-
Modo “as is” (difícil de detectar lista incompleta o inexacta)
-
- Guardian Heroes
-
Ventana/Clipping/Mascaras y Prioridad/”Z-Buffer”
-
- Ventana de Sprite: Activada en la inmensa mayoría de títulos.
Función Cálculo Color Extendido (ECC)
1995
- Battle Arena Toshinden Remix
1996
- Linkle Liver Story
- Alien Trilogy
- NiGHTS into Dreams
- Dark Savior
- PriCla (Princess Clara) Daisakusen
- Sega WorldWide Soccer 97 / Victory Goal ’96
- Bug too!
1997
- J.League Pro Soccer Club o Tsukurou! 2
- Sonic R
- Shining Force III Scenario 1 / 2 / 3 / Premium
- NBA Live 98
- Grandia
1998
- Savaki
- Cotton boomerang 2
- D-Xhird
- Wachenröder
Cálculo Offset Color
Para la Pantalla de Sprites, Pantallas de Capas, Línea de Color y Pantalla Trasera
- En la inmensa mayoría de juegos que he analizado. La lista seria demasiado grande.
Line Color Screen Insertion
1994
- SEGA AMx – GAME SAMPLE – SGL 1 (1994)
- Magic carpet ; CC priority and ratio / Normal / MSB Shadow demo; Color Line Screen Demo ; Windows VDP2 and screens demo
1995
- Panzer Dragoon 1→ Degradado horizonte planos infinitos.
- Wing Arms
1996
- Guardian Heroes
- GunGriffon
- Panzer Dragoon Zwei → Degradado horizonte planos infinitos.
- Dragon Ball Z: Idainaru Dragon Ball Densetsu
- NiGHTS into Dreams
- Decathlete / Athlete King
- Battle Arena Toshinden URA
- Sega WorldWide Soccer 97 / Victory Goal ’96→ Degradado horizonte campo.
- Street Racer (Extra)
- Shining the Holy Ark
1997
- Shinrei Jusatsushi Taroumaru
- Gundam Side Story 3 Kidou Senshi Gundam Gaiden III: Sabakareshi Mono
- Independence Day
- D-Xhird
- J League – Go Go Goal!
- Sonic Jam
- Bulk Slash
- Thunder Force V
- G-Vector
- Sega Worldwide Soccer 98 / J. League Victory Goal ’97
- J.League Pro Soccer Club o Tsukurou! 2
- Sonic R ← Ondas de agua con Pantalla de Líneas a color Animadas + ECC
- Ninpen Manmaru
1998
- Dragon Force II
- Savaki
- Gungriffon II
- World League Soccer 98
- Radiant Silvergun
- Grandia → Magias resplandor color a toda pantalla ← Podría ser Color Offset
- Pro Yakyuu Greatest Nine ’98 Summer Action
- J.League Pro Soccer Club o Tsukurou! 2
- Panzer Dragoon Saga→ Degradado horizonte planos infinitos.
- Akumajo Dracula X: Gekka no Yasokyoku (aka. Castlevania: Symphony of the Night) (1998) ← Nivel Agua primeras habitaciones castillo contra varios screens, o encima de todo
Función Sombra:
-
Sombra MSB
- SEGA GAME SAMPLE 1 For SBL 1.1
- CC+priorities + MSB / Normal Shadow demo
- Astal
- Sexy Parodius
- The Story of Thor 2
- Shinrei Jusatsushi Taroumaru
- J League – Go Go Goal!
- Asuka 120 Burning Fest
- Mass destruction
- SEGA GAME SAMPLE 1 For SBL 1.1
-
Sombra Normal
- SEGA GAME SAMPLE 1 For SBL 1.1
- CC+priorities + MSB / Normal Shadow demo
- Astal
- From TV Animation Slam Dunk: I Love Basketball (1995-08-11)
- Guardian Heroes (1996-01-26)
- Skeleton Warriors (1996-04-16)
- The Story of Thor 2 / The Legend of Oasis / Thor: Seireioukiden (1996-04-26)
- Three Dirty Dwarves (1996-09-27)
- Lunar – Silver Star Story CPK / Lunar – Silver Star Story MPEG-ban o Complete (1996-10-25)
- Sexy Parodius (1996-11-01)
- Fighting Illusion K1 Grand Prix (1997-01-31)
- Shinrei Jusatsushi Taroumaru (1997-01-17)
- Soukyugurentai (1997-02-07)
- Drift King Syutokoh Battle 97 / Shutokou Battle ’97: Tsuchiya Keiichi & Bandou Masaaki (1997-02-28)
- FIFA 97 (1997-04-04) → Sin CC y sin Transparent Shadow Enabled? ¿Como lo hará?
- J League – Go Go Goal! (1997-05-30)
- Moon Cradle (1997-06-27)
- Silhouette Mirage (1997-09-11)
- Asuka 120 Burning Fest (1997-10-09)
- Layer Section II (1997-10-30)
- Mass destruction (1997-11-20)
- FIFA 98 (1997-12-17)
- Courier Crisis (1997-12-20)
- SEGA GAME SAMPLE 1 For SBL 1.1
Transparencias Software+Hardware: VDP1>transferencia>VDP2
- Arcana Strikes (1997-12-11)
- Grandia (1997)
- Burning Ranger (1998)
- XL engine (2019)
Transparencias Software render
- Scorcher (1997) →Halos. Cuando estas en primera persona en la máquina real hay relentizaciones muy fuertes con cámara lejana y media buena velocidad.
- Die Hard Trilogy (1997) → Halos/destellos y fuego/explosiones. Cuando estas en primera persona y tienes grande áreas ocupadas con transparencias en la máquina real hay ralentizaciones muy fuertes.
- Soul Hackers Devil Summoner (1997)→ Efecto de ocultación con transparencia VDP1.
- Sonic R (1997) → Reflejo ambiental renderizado por CPU más transparencia con VDP1.
Uso de varias opciones de Transparencia SS(VDP1, VDP2 u otros) Una selección:
1995
- From TV Animation Slam Dunk: I Love Basketball
1996
- Congo: The Movie – The Lost City of Zinj
- Magic Carpet
- Keio Flying Squadron 2
- NiGHTS into Dreams
- Road Rash
- Tokusou Kidoutai J SWAT
- Dark Savior
- Policenauts
- Street Racer (1996) → Sombras redondas y UI VDP1>VDP2 / Sombras+nubes VDP2 RBG color ratio over VDP2 RBG / VDP1+VDP2 3D Near Clipping 3 Level Fade to VDP2
- Bottom of the 9th
- Mighty Hits
- Fighting Force (Judgement Force)
- NBA Jam Extreme
- Shining the Holy Ark
1997
- Shinrei Jusatsushi Taroumaru
- Soviet Strike
- D-Xhird (1997) → VDP1>VDP2 CC+Ratio, Extended y Normal CC VDP2, Line Color Screen y/o Función Gradiente. Adaptado a cada escenario y efecto buscado. Y en menús.
- J League – Go Go Goal!
- Darklight Conflict
- Mass Destruction (1997) → CC+Ratio, MSB ON, Transparent Shadow Enabled, Normal CC VDP2
- Nascar 98
- Sonic R (1997) → CC+Ratio, Color Line Insertion Animado, VDP1 CC Half-transparent, Sprite Window Enabled, Extended, Normal CC VDP2 y Mesh.
- Shining Force III (1997)→ VDP1>VDP2 CC+Ratio, Color Line Insertion?, VDP1 CC Half-transparent, Normal CC VDP2.
- FIFA 98
- Grandia (1997)→ VDP1>VDP2 CC+Ratio, Color Line Insertion?, VDP1 CC Half-transparent, VDP1 transfer to VDP2 trick.
1998
- Jung Rhythm
- Panzer Dragoon Saga (1998)→ VDP1>VDP2 CC+Ratio, Color Line Insertion?, VDP1 CC Half-transparent
- Sokko Seitokai Sonic Council
- Burning Rangers (1998)→ Burning Rangers Transparency Trick, VDP1 CC Half-transparent
- Akumajo Dracula X: Gekka no Yasokyoku (aka. Castlevania: Symphony of the Night) (1998)→ VDP1>VDP2 CC+Ratio, Color Line Insertion, VDP1 CC Half-transparent y Mesh.
Antes de terminar este punto me gustaría hacer una reflexión final sobre este tema. El tema de las transparencias en las máquinas domesticas de SEGA han sido un problema casi constante. Desde la Megadrive / Genesis contra la SNES y después con la Sega Saturn. Es curioso como incluso, en las máquinas Arcade, al menos hasta la Model 3. No parecía tampoco haber un interés claro por estas dentro de SEGA. Es cierto que de una manera u otra se pueden hacer tanto en SMD / Genesis o SS, más incluso en esta ultima como hemos visto. Pero que funcionaran bien y fácil como en la competencia, no. Incluso los mismos equipos internos de SEGA tampoco mostraban mucho interés en ellas. Viendo como en la mayoría de juegos se optaba por la solución fácil de “mesh” o “tramado”.
Como colofón después de todo el drama que le supuso. SEGA finalmente se desquito del “tema de las transparencias” a nivel domestico he incluso en los Arcades con el PowerVR2 para DC/Naomi1-2. Este le dio a SEGA el algoritmo por hardware para transparencias más preciso que ha existido durante mucho tiempo. Hablando en consolas domesticas o chips de PC, claro.
Para terminar la sección, como de costumbre. Vamos a mirar más en detalle tres juegos que para mi destacan en este punto de manera especial:
-
Loaded
1996-06-01. Lanzados a mediados de la 3ª ola. Ya se podía ver como los desarrolladores Europeos ya empezaban a dominar SS con más soltura. También gracias a la llegada del nuevo SDK de SEGA, SGL en parte, que ayudo a los desarrolladores a sacar mejor partido a la máquina, según podemos leer en una cita de la Wikipedia.
Con todo, podemos ver como en este juego la tónica habitual fue, no dedicar suficientes recursos a la versión de SS e incluso retrasar los lanzamientos mucho, en este caso un año en USA y casi medio año en Europa. Esto como podemos entender hace mucho daño a una plataforma ante la fuerte competencia que había. Pero es lo que fue.
Solo podemos ver a un programador asignado a este port. El resto de acreditados aparecen como de la versión original de PS1, hasta que punto ayudaron en este port, no lo sabemos. Gremlin en general no tiene malos ports o juegos para SS. De hecho en su momento, hicieron juegos que están muy arriba en la tecnología 3D. Usando desde muy pronto efectos de Gouraud, niebla, iluminación dinámica a color, Grandes mundos 3D y con muchos elementos. Loaded es uno de ellos.
Estamos ante un juego realmente espectacular. Tanto hoy día, imaginad en su momento. Recuerdo nitidamente ver en “Legends”, la tienda de videojuegos de mi pueblo, este juego en la PS1 y explotarme literalmente la cabeza. La luces dinámicas a color, la cantidad de objetos y cosas que pasaban en la pantalla. Y como no: ¡La cantidad de transparencias! Recuerdo, antes de que saliera la versión de SS, hablar con mis amigos de la tienda, mi primo Nono sobre todo y Carlos. Sobre las características más importante del juego que en SS costaría verlas o no estarían. La iluminación a color y las transparencias era una de ellas.
Haciendo justicia al tiempo, tenemos que decir que el port esta muy cerca del original. Muy cerca. Las diferencias son mínimas. Diferentes resoluciones para el menú. Extrañamente en SS la resolución final es 352×224 mientras que la del VDP1 es 320×240. Por otra parte el resto del juego corre a 352×240, a algo más de resolución total que en PS1. Mientras que en PS1 los menús están a 512×256 y el resto a 320×256. Y claro, las transparencias. Pero en este caso las diferencias son mínimas, el único elemento que no tiene transparencia con respecto al original, son las explosiones. Es cierto que es un elemento muy vistoso e importante. Y puede que las razones de ello fuesen que son Distorted Sprites con rotación y además es un elemento que está usando color bank. No son un billboard como en el resto de casos, donde se puede garantizar que la transparencia del VDP1 funcione correctamente. El resto como digo esta, en este juego donde todo está siendo dibujado con el VDP1, fue bastante directo hacer usar las transparencias, además en mucha cantidad y tamaño. Este fue uno de los juegos que más me han impresionado en esta investigación que he hecho, me impacto ver tanta features “prohibidas” en un mismo juego XD.
Todo lo demás está intacto. La resolución y profundidad de color en las texturas era idéntica. Como todo es idéntico pero con las comprensibles diferencias de hardware. La iluminación dinámica con Gouraud a color es idéntica en ambas máquinas. La única diferencia es que en SS tienden más al negro que en PS1 que tiende a tener zonas oscuras con más brillo. Es por la diferencia en el Gouraud entre máquinas. Se podría decir que la versión SS es más oscura. Pero era algo que se podía corregir, con un poco más de trabajo. El único problema es que algunas zonas muy oscuras en PS1 en SS, realmente son demasiado oscuras.
Sobre el rendimiento, estaríamos casi a la par. En SS se mantienen los 30/25FPS casi todo el tiempo. Pero donde ya había caídas en PS1 en SS son algo más pronunciadas, sobre unos 20FPS. Este juego quizás tenga un problema de optimización en la parte de la CPU, porque con lo que se ve en pantalla, sobre 400 quads el VDP1 podía manejarlo sin problema. La cantidad de geometría en pantalla es igual, o muy similar, a la PS1. Y puede que el fruto del bajo rendimiento sea que en parte el código de PS1 haya sido trasladado a SS. Pues podemos ver el típico flickering en las texturas de PS1 en esta versión. El uso del VDP2 es nulo, absolutamente nada.
Aunque es curioso, podemos encontrar algunos detalles interesantes muy avanzados, además de los propios de la iluminación dinámica a color y el uso de transparencias, dos grandes features para la máquina y la época. Uno de estos detalles, es la presencia de uso de “Render-to-Texture”. Algo complicado para SS, fácil en PS1. Pero en Loaded podemos verlo hasta en tres escenarios diferentes:
-
- En el menú de pausa en el juego. Cuando pausamos se usa para hacer la textura de fondo. Realmente lo veo algo excesivo, pero así es. Ese pequeño lag que hay cuando le das a la pausa es para pasar la información desde el framebuffer a unas cuantas texturas en el VRAM del VDP1. En este caso es 352×128. No toda la pantalla, aproximadamente ⅓ del total superior.
-
- En la UI y mapa de la esquina superior izquierda. Los gráficos que se ven hay son texturas que son pintadas, presumible mente por la CPU, y mandadas a la UI cada vez que se refrescan. También lo veo excesivo. Porque se podría a ver echo con el VDP1 perfectamente, o incluso con el VDP2, una parte al menos.
-
- Por último, y no lo tengo claro al 100%. Son las pantallas de carga. Cuando pedimos al debugger de Yabause que nos diga que hay no nos muestra nada en ningún VDPs. Pero si desactivamos la capa del VDP1/Sprites, este se va. Podemos deducir que está siendo pintado directamente en el FrameBuffer en la parte del VDP1. Podríamos estar ante un Render desde la CPU al Framebuffer directamente. Otra sobrecomplicación, en principio.
Podemos encontrar unos FMV con una calidad muy buena. A toda pantalla y con una gran compresión, a una calidad cercana a PS1.
Finalmente el uso de la máquina es notable. Usan los 2xSH2 en todo el juego FMV y el juego 3D. Podemos observar un uso del SCSP-DSP, posiblemente para el sonido CD-DA. El uso de la RAM principal es de un 95% el HRAM y 75% de la LRAM. El uso de la VRAM del VDP1 está en un 90%. Finalmente la VRAM del VDP2 está siendo usada a nivel de memoria un 50% en la parte de pattern/patrones y un 60% en la CRAM. Los únicos signos de uso es en algunos elementos con color bank como: Polígonos planos con transparencia, algunas texturas como las explosiones… El resto de este uso es desconocido.
-
Pandemonium!
1997-02-28. Siendo un desarrollo de la 4ª ola de desarrollos, en este caso desde USA. Por Jumpin’ Jack Software equipo second party de SEGA en aquel momento. No deja de sorprenderme como en mi investigación tope con el, porque siempre me pareció ver que tenia transparencias. Y así fue, pero si tengo que definir este port de alguna manera, es como un port osado e irregular.
Jumpin’ Jack Software cierra su vida con este port. Que incluso no fue acreditado oficialmente. Fueron osados, porque pasaron a programar sobre un tipo de motor y juego completamente diferente a lo que habían estado haciendo hasta el momento. Pasaron de FPS a un plataformas en 3ª persona con cámara fija. Además de hacer un port, no un juego original de ellos. Así pues dejaron atrás su Engine 3D y portaron el famoso y exitoso juego de PS1 para SS, la maquina que conocían muy bien. Es cierto que ninguno de sus anteriores juegos fueron excelentes, pero en lo referente a los FMV si que lo fueron. Extrañamente en este juego, conociendo Duck de sobra, más que Cristal Dynamics también lo conocía y lo usaba con maestría. Tiene unos FMV malos. Pequeños 256×160 y mal comprimidos. Es totalmente, incomprensible más cuando el logo de Crystal Dynamics se ve muy bien a 320×200. Primeras dos señales de osadía por una parte e irregularidad manifiesta por otra.
Ahora pasemos al juego propiamente dicho. Menús, mapas, modelos, animaciones, niveles, secretos… todo está clavado al original. Para este juego tuvieron que lidiar con la iluminación dinámica a color por Gouraud que tenia el original y lo consiguieron. Pero además tuvieron que lidiar con gran cantidad de transparencias y lo consiguieron, a medias. A medias porque aún faltan algunas, es cierto que muy pocas, transparencias(como en la UI, la catarata de agua del primer nivel o los cristales del enemigo final). Y sin usar en ningún momento el modo mesh. Y en esto fueron osados. Pero irregulares, porque usan las transparencias en elementos 3D no billboard mostrando errores de VDP1 en la transparencia y slowdowns realmente importantes a causa de ello. O usándolas contra los fondos VDP2 que pueden llegar a ocupar grandes áreas de la pantalla, anulando por completo las transparencias usadas por ellos, totalmente las del VDP1. Porque no hay rastro de uso de las transparencias del VDP2 en ninguna de sus formas. Si esto le sumamos una conversión de modelos a quads en algunos casos deficientes, con demasiados triángulos, ocasionando también estos slowdowns. Y en general una optimización de rendimiento muy irregular con bajadas de frames en bastantes puntos perjudicando incluso a la jugabilidad, por ejemplo en el jefe final. El juego corre justo a 25FPS en muchos tramos del juego y en el global en su mayoría. Pero en momentos muy concretos cae por debajo de 15FPS o menos. No visto más de 450 quads en pantalla, puede que 500. No es una cantidad que para el VDP1 sea un problema, solo si no está usando como se debe o incluso la parte de la CPUs no está lo suficientemente optimizada.
Tengo varias teorías. Este prácticamente fue, estoy casi seguro, un “regalo” de SEGA. Intuían que iba a ser el último. Posiblemente con un budget muy ajustado. Todo ello junto a una cantidad de retos nuevos que tenia que afrontar. Todo ello no creo que ayudara a llegar a la máxima meta. Hay que decir que podemos ver un uso de SCU-DSP en este juego, que no he visto en sus anteriores títulos, y que puede significar que quisieran llegar más lejos y mejor con el hardware de la SS. Pero tristemente no lo consiguieron, se quedaron a medio camino.
El uso del hardware por otra parte es muy bueno. Usando los 2xSH2 + SCU-DSP tanto en 3D como en las FMV. Llegando a un uso de la memoria del SCU-DSP de un 60% y de un uso de sus registros de un 39,13%. Aunque tiene música MIDI, no observamos un uso claro del SCSP-DSP, algo curioso. Pero si señales en Yabause de hasta un 35% en la memoria del DSP de sonido.
El uso de la RAM principal está en un 65% de LRAM y un 90% de la HRAM. Para la VRAM del VDP1 en un 80%. Finalmente la VRAM del VDP2 principal en 35% y la CRAM en un 30%.
-
Burning Rangers
Estamos hablando de posiblemente uno de los mejores 3 juegos de la SS. Sin duda, a nivel técnico es sobresaliente. Es cierto que ya fue uno de los últimos, perteneciente a la 5ª y ultima ola de desarrollos Japoneses first party. Publicado a principios del 1998-02-26. Pero resultando ser un plataformas 3D con cámara en 3ª persona que esta plenamente a la altura de muchos títulos similares en PSX.
En el 1998-12 se publica Sonic Adventure para DC. Trabajaron a la vez en ambos. Todos los programadores. Algunos trabajaron en Nights otros en Sega Rally o Metal Head de 32X.
Burning Rangers se presenta en HD en todos sus logos iniciales y menús a 704×224 en modo entrelazado de Doble densidad, dándonos unos 704×448 puntos en pantalla, insuperable en la época. En el resto del juego va a una resolución SD de 352×224(NTSC). Siempre a 16bit de color. Exceptuando los FMV a 24bit de color.
El Motor 3D es espectacular para el momento pero en los detalles finales es un tanto irregular.
Es posible que el Sonic Team usara alguna versión SGL 3.x. Ya que ya dos años antes para Nights fue uno de los primeros equipos de SEGA en usar el SGL1.x. Más las modificaciones arrastradas de Nights y nuevas, y únicas, features desarrolladas internamente por el Sonic Team para este Burning Rangers.
Pero la feature por excelencia y que se define con el mismo título del juego es la capa de transparencia que tiene Burning Rangers. Una genialidad de truco, que fue una autentica pena que apareciese al final de su vida. Renderiza de forma alterna el mismo fotograma en dos tandas. La primera los elementos opacos a la resolución total 352×244. Después renderiza a la mitad de la resolucion total, es decir a 160×122, los elementos transparentes más los elementos de máscaras.Donde estos últimos no dejan de ser la misma geometría anterior pero en color negro.
He llegado a ver 1200 quads totales aproximadamente. Todos con Gouraud, su inmensa mayoría texturizados. Donde los cuales eran entre:
200/855 elementos opacos + 100/150 elementos transparentes + 50/150 elementos de máscara
Podemos ver que los elementos de máscara son muy bajos, puede que este sea una de las causas de Z-fighting de los elementos transparentes en este Burnign Rangers.
Todo esto debe estar limitado, porque en algunas ocasiones la mismas partículas transparentes son dibujadas en la capa opaca. Quizás hasta un limite de quads están permitidos en la capa de transparencia y partir de ahí o no se dibujan o pasan al VDP1.
Incluso en algunas contadas ocasiones se llega a usar el modo mesh en algunos elementos como: Humo, sombras, teletransporte… Una pena, porque bajo mi punto de vista se podría a ver usado la capa de transparencia para ellos. Quizás había algún problema puntal con las sombras al pasar por encima del agua o cristales. Pero creo que usando correctamente el VDP1 todos estos elementos podrían a ver sido transparentes sin problemas. Para el humo igual, o intercalando la capa VDP2 con la transparencia VDP1…. En fin, solo son posibles alternativas.
Lo que esta CLARISIMO. Y es INMENSO. Es que este equipo hizo el fuego, y los efectos de partículas más bonitos y espectaculares en el sistema. El agua y los haces de luz de la segunda misión son INCREÍBLES para la SS. Cristaleras gigantes con brillo. Recuerdo explotarme literalmente la cabeza cuando lo vi. Y seguir alucinando muchísimo cada vez que lo veo.
Como apunte. Esta cantidad de transparencias en pantalla, sobre todo el área y la cantidad de elementos, incluso valorando el coste de transferir los datos del VDP1 al VDP2. Hacen que esta cantidad y calidad de transparencia rivalicen muy seriamente con la PS1.
Para acabar con las transparencias. Señalar que también se usan las del VDP1. En este caso solo en la UI. Con varios problemas. El primero que la capa de transparencia del VDP2 cubre los elementos de la UI que están dibujados en el VDP1. Al estar esta por encima en la prioridad de dibujo. Se podría haber evitado este solape, transfiriendo los elementos del la UI en negro de igual forma que los del escenario. O usando color back con prioridades y ratios para los elementos opacos y posicionarlos encima de la capa de transparencia. El segundo es que la transparencia del VDP1 cuando esta sobre el fondo en VDP2 no funciona. Podrían haber usado su propio truco de capa de transparencia para hacer estos elementos transparentes más la transparencia del VDP1 para que funcionase correctamente con todo.
Es cierto que la distancia de dibujo es relativamente corta, resultando brusca en demasiadas ocasiones. El sistema de culling es muy básico o posiblemente inexistente. Ya que con el wirerame activado podemos ver gran cantidad de geometría tras las paredes o puertas. El culling que está implantando seguro es el Back culling. Se ven uso de quads convexos para escalones, algo muy atrevido, pero posible para el VDP1. No usan LODs, tampoco mip-mapping. Ni Depth cueing, curioso poruqe tampoco lo usaron en Nights y aún más curioso porque este último ya estaba implementado en el SGL 3.x. Se puede ver como en el cálculo de trasformación polígonos hay un claro fliquering(en vértices) como Tomb Raider o Loaded. Puede por que se uso una baja precisión en la transformación y proyección de vértices. También observamos, más a menudo de lo que nos gustaría, un Z-figthing muy pronunciado y también una unión de esquinas con solapes.
Hay iluminación Gouraud en todo el juego. Estática(animada también) precalculada a color en escenarios espectacular que afecta a entidades 3D de forma total sin fuente. Puede que esta simplificación de la iluminación fuese cara a la optimización. Aunque aún tiene detalles de luz puntual dinámica en explosiones. Finalmente hay una luz puntual totalmente dinámica a color(Como la linterna de Silent Hill) en las secciones a oscuras.
Con todo lo dicho, he increíblemente Burning Rangers es estable. Muy estable. También es cierto que lo es corriendo a 20FPS. Siendo justos pone bastante al límite la maquina. Quizás les falto optimizar algo más para poder a ver llegado a los 25/30FPS. Con una subdivisión dinámica o LOD, tanto para aumentar la distancia de dibujo como un mejor culling. Haber añadido un Depth Cueing de alguna manera también hubiese suavizado la distancia de dibujo. Más un mip-mapping para bajar la exigencia al VDP1. Quizás con todos estos podrían haber rebajado la exigencia casi duplicada que tenia al renderizar las dos capas. Incluso a ver mejorado el aspecto, reduciendo el Z-figthing.
Aunque al final lo que realmente hace que todo se vea también es la originalidad, cantidad y la calidad del arte. Es un juego que aun hoy día se disfruta y se ve fresco y único.
Por último con grandes FMV, eso si con el Codec Cinepak en su variante final .CAK, pero muy bien usado en este caso para el tipo de contenido. El Anime al Cinepak le va muy bien la verdad. Junto a un stream de audio ADX, llevan al límite el codec y la máxima calidad para este gran titulo de SEGA. Quizás le falta bajo mi punto de vista un poco de resolución, quedándose los 296×216 un pelin cortos para la calidad de la animación hecha.
Con una música magnifica, usando sonido multistream .acx de ADX ADPCM para la misma y los diálogos(continuos durante todo el juego ya que es una mecánica del mismo). Reproduciendo hasta tres(música Estéreo y dos diálogos mono a la vez) stream a la vez a un sampleado y calidad excelentes. Esta fue otra feature que ponía la calidad de sonido a la par con PSX. Además con unos efectos de eco y reverberación, casi seguro vía SCSP-DSP, que se notan perfectamente. Quizás uno de los juegos donde más y mejor se usan estos efectos que tanto me gustan. El uso del SCSP-DSP llega al 95% de uso de la memoria. Y el M68x a un 60% en los registros.
Como venimos exponiendo el uso de la máquina es absoluto. Llegando a usar un 70 de LRAM y un 80% del HRAM. Por otra parte hasta un 85% de la VRAM del VDP1y un 60% de la VRAM VDP2 para pattern/patróns y un 100% de CRAM del VDP2.
El uso de los procesadores es altísimo, como no podía ser de otra forma. Usando los 2xSH2+SCU-DSP durante todo el juego. Un usuario en Segaextreme cuantifico el uso del SH2 esclavo en un 60% Esclavo. En FMV, menús y durante el juego 3D. He tenido muchas duda sobre el uso de SCU-DSP en este juego. Finalmente lo más posible es que este uso sea por parte del codec ADX, y también para la transferencia de la capa de transparencia al VDP2. Puede que se usara para la iluminación también, pero lo veo menos probable. Llegando a un 13% delos registros y un 70% de la memoria tanto en FMV como en partes 3D.
Great article, you’re ready to write a thesis about Sega Saturn !
I have a few observations :
– VDP1 half transparency is not doing anything weird in term of blending : it is exactly alpha blending two RBG 555 colors with an alpha of 0.5 (which can indeed be computed with a shift, a classic optimization) over an opaque background. The fact that it operates on RGB 555 colors makes it less precise than what VDP2 can do with its RGB 888 colors calculation. And the shift means that the multiplication by 0.5, or division by 2, always rounds down which ends up slightly darkening resulting colors.
– VDP1 shadow is exactly the same result than half transparency using a black texture. VDP1 Shadow is useful because you don’t have to actually provide a black texture, it automatically uses a black texture pixel for of any opaque texture pixel, whatever its actual color. Another key difference of VDP1 shadow is that it doesn’t modify palette framebuffer pixels, contrary to half transparency which would overwrite them with black. This makes it possible to combine a normal shadow written before everything else and a VDP1 shadow to draw a complete shadow over an area composed of RGB sprite pixels and VDP2 background.
– «So when adding a dark value in the source pixel over a light value over a destination pixel, the resulting color will be even lighter.» : this is only the case for additive blending formulas where the ratio of the destination pixel is 1.
– VDP1 mesh can have several layers of mix if combined with half transparency. But doing so cancels the performance advantage of mesh, and displays the potential redraw artifacts of half transparency.
– VDP1 mesh looks much closer to half transparency when the sprites are in horizontal high res.
– «I will try to give some examples with possible default values similar to those of the Gouraud» : I disagree with you on that, VDP1 half transparency calculation has nothing to do with VDP1 Gouraud calculation. As I said, VDP1 half transparency lacks precision due to a full RGB 555 process and tends to darken due to the rounding down of the shift operation.
– «Most likely, in the case of the VDP1 in SS, the Color Calculation is done first and then the Gouraud» : it’s the reverse. When both effects are cumulated, Gouraud is calculated first, then half transparency.
– «In general VDP1 cannot read the CRAM at runtime of its pipeline.» : VDP1 has never access to VDP2 CRAM. When it does color calculation over palette textures, it operates on color indices that refer to CRAM adresses, not on the actual colors contained by CRAM at those adresses.
– «if we also want to take advantage of VDP2 for those written in VDP1, we have the limitation that if we start from a texture with CRAM data, if they are processed in VDP1 in color calculation processes, they remain in the Framebuffer as RGB» : resulting framebuffer pixels drawn by VDP1 color calculation over a palette texture are of palette type. This includes RGB framebuffer pixels modified by VDP1 half transparency, their type switches to palette, as shown by paul_met’s mod of SOTN dialog box.
– «if “Color bank / CRAM VDP2” is used, it will only work with the primitive Polygon even next to the CC VDP1 Gouraud (which theoretically could not be done either). How does the VDP1 read the color or colors at this time from the pipeline?» : like I said, VDP1 never reads colors from VDP2 CRAM, it doesn’t know about it. In the Destruction derby screenshot, the color mode «4BPP(16 color bank)» is meaningless for a polygon command. The hexadecimal color «415A8» is actually an RGB color : due to a bug of Yabause/Yaba Shanshiro, it has to be shifted by 3 to the right to get the actual 16BPP color, whose MSB is set to 1 indicating an RGB color.
– «It is true that the second “blend” of ECC adds extra limitations(…) the number of colors in the palette on the sprite screen is halved, from 2,048 to 1,024 colors if we use the color and priority calculation function. And if we only use it in its MSB mode, this RGB being from 32,768 to 16,384 colors, theoretically.» : the number of VDP2 CRAM colors have to be halved to be mixed by ECC because CRAM must be mirrored (mode 0) to double its throughput. RGB pixels are unaffected by ECC limitations because VDP2 doesn’t need to access CRAM to get their RGB data. So sprites RGB pixels still have 32,768 possible colors.
– «We ended up talking about the “as is” mode.(…) I don’t know if this can also be used in the ECC, in a second layer, but I would say not because of the fixed nature of the ECC mode.» : correct, ECC always uses blending formulas with ratios.
– «In 8BPP mode the maximum will be 6 bits and the minimum 7 bits to define the color.» : it’s actually between 6 and 8 bits for the color, when using 8 bits, one or two color bits are shared with priority or CC.
– «Shadow MSB(…) Main problem, it can only be used in 8BPP mode.» : MSB shadow is limited to 16BPP framebuffer.
– «We would have to add one last limitation to the shadow function in VDP2.(…) if before applying the effect on the pixels marked as shadow, the VDP2 has to apply Color Calculations, it will cancel the possibility of interpreting this data. However if the color calculations are done after the shadow calculation, it will work.» : shadow is always applied after CC (it’s the last step of VDP2 rendering pipeline). The limitation is that it can only be processed if the sprite pixel has the top priority. So if the sprite pixel is visible through a semi-transparent layer which has a higher priority, no shadow is performed.
– «Limitations Offset Color Calculation(…) when the Color Screen per Line is being used inserted in some Screen / Screen. It seems that this is affected less and not in the same way as the rest of the data by the color change of the function.» : this is an old Yabause bug corrected recently in Kronos, see https://github.com/FCare/Kronos/issues/690
– Color offset can be varied for each line by changing VDP2 registers during display, for example the white haze at the title screen of Albert odyssey.
– Nights has a nice window effect on the vortex when Nights loops. The vortex graphics has every other column transparent to make it look semi transparent.
Correction about the color offset bug : it was only in Kronos from version 1.7.0, and was corrected in v2.1.1.