Sin querer decir nada de Hermes empezaré desde el principio pq creo que hay gente que no ha entendido muy bien los conceptos de Rendering básicos. Hablaré de PS2 porque es la que básicamente me he dedicado a programar estos años y pq basé my PFC en ella.
La mayoría de soluciones gráficas modernas cuentan con un framebuffer dedicado, que básicamente es una zona de memoria sobre la que se realizan los apuntes finales de gráficos. Esta memoria suele ser eDRAM (embedded RAM) cosa que le da mucha velocidad.
De las 3 consolas existentes, la que tiene más y mejor eDRAM es PS2. Es simplemente un hecho. Desgraciadamente PS2 no puede direccionar texturas virtualmente como GC o XBOX hacen, con lo que tienes que tener tus texturas de esa frame en memoria eDRAM.
Igualmente todo proceso de renderizado con cara y ojos requiere de 3 zonas de memoria dedicas: Front Framebuffer, Rear Framebuffer y Zbuffer.
Front y Rear Framebuffer van alternando segun va cambiando la frame y zbuffer se mantiene intacto (dirección de memoria).
Ok, dicho esto, pasemos a explicar un poco como se particionan estas zonas de memoria en PS2. (caso NTSC)
Para Framerrates superiores a 60 FPS ( es lo que se llama fieldRendering, permite ganar espacio para texturas pero te fuerza a tener 60 FPS por huevos)
Para Framerrates inferiores a 60 FPS
Dicho esto, ya se ve que espacio para texturas hay...Lo que es necesario saberlo usar sabiamente. En esto entran varias técnicas. La PS2 no soporta que las texturas en la eDRAM del GS estén comprimidas, con lo que hay varias estrategias para superar eso:
1) Usar CLUTs. Con esto lo que conseguimos es reducir mucho espacio. Pensad en los gifs. Básicamente elegimos los colores que queremos para esa textura y nos los guardamos. La paleta de elección es inmensa !!!! 24 bits de color (8 se guardan para alpha), pero solo podemos guardar 256/16 colores por imagen con lo que es necesario saber convertir bien las texturas...(cosa que la mayor parte de artistas no saben hacer bien jejeje).
2) Descomprimir las texuras on the fly en el IPU. Básicamente las texturas en formato JPEG son descomprimidas cuando son transferidas via PATH2 al GS...
Hablando con desarrolladores pues el problema principal no acaba siendo el espacio del que disponemos en la eDRAM del GS pues es muy rápido el bus/memoria...sino la cantidad de memoria de la que disponemos en la memoria principal.
Eso acaba siendo el principal problema a la hora de afrontar temas de texturas en PS2.
Pero claro, el bus tb sirve para transferir geometría con lo que si...realmente al final debemos ser muy inteligentes a la hora de calcular el espacio para texturas.
A todo esto salto al tema framebuffers. Sigo sin saber si el RE4 de PS2 funciona a 24 bits de color PARA FRAMEBUFFERS o a 16 bits...Pero lo que es seguro es que el de GC funciona a 16 bits. La mayoría de artefactos/banding que uno presencia en el juego son la prueba directa.
En el de PS2 estos son mucho menos visibles, pero la calidad de las texturas es, como muchos habeis dicho, inferior. Así mismo la geometría/iluminación ha sido rebajada. No estoy en contra de esto, es verdad.
Pero no hay tanto banding/artefactos. Por lo que formulo la teoría siguiente.
Estamos pues trabajando con texturas de 8 bits de CLUT, pero que en definitiva representan colores de 24 bits con alpha de 8 bits!!! Esto en que influirá respecto usar texturas de 16/24 bits ? Básicamente perderemos colores, si hay más de 256 colores distintos, pero no tendremos artefactos ni banding. Simplemente uniformidades brutales.
Estas además es dificil que se crean en un framebuffer de 24 bits de color, aunque si sería posible que se crearan en uno de 16...Sobretodo al jugar con la iluminación.