Sexy MotherFucker escribió:Y sin necesidad de truquitos baratos ajustando brillo y color en menús ojo, sino
literalmente mayor número real in game o pantallas estáticas (estas sí a base de Shadows & highlights):
https://www.youtube.com/watch?v=Z9rjwECf2wQVectorman: 88 colores en su pico máximo, in-game.
Toy Story: 105 colores en su pico máximo, in-game.
¿Una mariconada al lado de lo que potencialmente te brinda una SNES?. Totalmente, pero no veo porqué interesarte en el potencial máximo de un sistema implica que seas un seguero cerrado que insinúa que la Megadrive es tanto o mejor que la SNES en un asunto tan perogrullesco como la paleta.
Vamo a calmarno, yo el primero.
NO. Eso que dices está mal, en Toy Story sólo se alcanzan esos colores (y más) cuando se está en las escenas de imágenes estáticas contando la historia (de hecho es el ejemplo que ponen al final de "muchos colores"). En in game lo que se ve es que pasa marginalmente de 64, 66.
En realidad la mayoría de veces los juegos están usando muchos menos colores en pantalla, como mención Vectorman dado que de media debe estar rondando los 40 colores a lo sumo, menos que otros juegos que no se saltan el límite.
Verás, me he dado cuenta de un detalle, tanto Vectorman como Toy Story tienen algo en común para lograr saltarse ese límite:
Tienen HUDs muy grandes y horizontales, por bloque y no integrados e impresionados sobre el área del juego (cajas negras o de colores, pero sin nada "móvil" por detrás del juego en sí).
Puedes pensar que Toy Story no es así, pero fíjate dónde pasa que supera lo 64 colores, en las fases de juego 3D, donde sí hay este tipo de HUD. Y por supuesto en las imágenes estáticas de introducción, fin, etc. En vectorman en la presentación se supera también de largo el límite, donde existe en común que hay muchísimos elementos estáticos.
El truco es "fácil", es tener en cuenta el hsync de la pantalla y hacer cambios en los valores de color de tal o cual paleta de colores para así usando la "misma paleta" que en el área de juego obtener referencias a colores no usados en éste, y así superar el límite. En la presentación de Vectorman hay objetos móviles que estarán asociados a una paleta que no se toca, pero todo lo que se ve de la "carta de ajuste" estará asociado a otras paletas, estas paletas sufrirán cambios de valores una vez se alcanza el valor de hsync que defina un cambio de elementos (por ejemplo, la mitad de la pantalla justo cuando cambia la carta de ajuste a otros colores, etc).
En juego en Vectorman se supera este valor sólo en la fase de nubes y alguna área muy concreta, y sospecho que fuera del hud (que seguramente usa valores de grises distintos a los usados en esa misma fase), lo que se hace es cambiar sólo ciertos matices de algunos colores para evitar artefactos visibles (cambios de tonalidad de los verdes o azules usados tanto en personaje como fondos u enemigos, de tal forma que si se produce un "error" y se altera en un hsync la paleta en dos sprites que deberían tener colores distintos, pero ha cuadrado que están en el mismo lugar, se produce un ligero parpardeo, de hecho veo que el juego "juega" a mostrar mucho esos parpadeos de tonalidades, posiblemente en parte para enmascarar esos potenciales problemas de rotado/cambio de valores de paletas).
Eso se puede hacer también en SNES, por cierto. El cambio o rotado de paleta es un efecto muy viejo que se usa para hacer cosas como fundidos de color, en el caso de paletas de sprites puede ser útil para hacer efectos como "sombras", fundidos a color de personajes, y otros efectos variopintos).
Pero... ¿para qué hacerlo? Tampoco es que la SNES fuera a tener ni 200 colores en pantalla casi nunca (quizás algún título, ¿los de RARE debido al uso de la técnica de prerrendering en 3D?), en ese caso tiene más sentido usar técnicas de rotado/cambio de color para los efectos que he mencionado.
Si te fijas Virtua Racing no supera ni se acerca a dicho límite, y tiene un HUD integrado con el área de juego. Eternal Champions otro tanto, tiene HUD integrado en el área de juego y no supera el límite de colores (y está relativamente bien explotado como juego en cuanto a colores y uso pleno de las palets, con pocas redundancias entre las 4 existentes).
@kusfo79Pues seguramente tengas razón, la PPU parece bastante liosa de programar por lo que he visto hasta ahora, y el SPC700, bueno, en principio es un caso "similar" al Z80 y otras cpus usadas como coprocesador de sonido, es una cpu más o menos generalista (muy parecida al 6502, sobre todo arquitectónicamente hablando, aunque eso no le guste a magno, es lo que hay), con instrucciones multimedia más el DSP de apoyo. Posiblemente en este caso el problema venga de la novedad de cómo funciona la SNES con su formato compreso de wavetable y samples, más que nada.
@Dany ROD Si te fijas en la cita que pones se ve que se puede definir más áreas de memoria VRAM para almacenar sprites que el mencionado límite de 16 KB, página anterior.
En el registro 2101H se pasan valores del "base address" y del "name select" que configuran el mapeo de la región de 16KB donde se guardarán (y leerán cuando haga falta, supongo, o igual no hay esa limitación) los sprites (OBJ NAME). Se usa un sistema de banderas por bits para seleccionar básicamente las regiones de memoria (BASE ADDRESS NO está suficientemente bien explicada, dado que no dicen qué pasa si se eligen otros valores de BA0 y BA1, supongo que en otro lado del documento sí, pero sí nos dice que NA0 y NA1 mapean a 4 regiones distintas de 8 KB de tamaño, eso nos da un mínimo de 32 KB + 8 KB de BASE ADDRESS, y digo mínimo porque nada hace pensar que no mapeen también todas las demás combinaciones de BA0 y BA1 a otras regiones de la VRAM, sumando los 24 KB que faltarían por mapear).
Esto es, que teóricamente con el uso de estas banderas del registro puedes configurar cualquier área de la VRAM para ser donde se trabaja con los sprites, nada hace pensar que no se pueda cambiar al vuelo (para eso estaría el registro 2101H, entre otras), y así usar toda la VRAM que se quiera incluso para renderizar una misma pantalla (evidentemente, si se tiene que trabajar con timings de hsync y cambios de mapeo de todo esto, se complica demasiado la programación y es un puto lío, pero si lo pensamos da un poco "igual" dada la limitación de sprites en pantalla que presenta la arquitectura, sólo hay que asegurarse de tener "visibles" en forma de area activa de uso los sprites necesarios). Tendría que mirar si en la región de memoria donde se guardan los índices de los sprites a renderizar se pueden hacer referencias a sólo esa memoria activa o a regiones distintas también para acabar de dibujar la forma de funcionamiento de la VRAM y cómo leen los PPUs los sprites, pero vamos... me ha quedado claro que sí se puede (y se debe) usar toda la VRAM para almacenar datos, ¿que tiene sus peculiaridades?, nos ha jodido, yo por preferir prefiero trabajar "tradicionalmente" con un framebuffer y si tengo que elegir modos paletizados, prefiero mil veces paletas generales para toda la pantalla que paletas para sprites...
Vamos, es lo que entiendo a simple vistazo nada más fijarme en el documento y esas dos páginas.
he_man_mx escribió:no estoy de acuerdo.
y antes de decir porque, me parecio curiosa esta entrevista de nick jones por lo que cometaban de la dificultad de programar en el super nes, ya que el mismo dice que hay que ser un "japenglish"
Eso precisamente apunta a lo que yo dije antes sobre la dificultad en la época para documentarse. Se tenía que usar documentos en papel venidos de fuentes concretas (Nintendo), y ya señalé que podría haber grandes problemas por esto y las malas traducciones (japenglish).
Es curioso lo que cuenta (pena de captura que recorte partes de la conversación muy interesantes) porque precisamente Nick Jones por su background es el tipo idóneo para hacer los ports a NES/SNES de los juegos de Shiny, me gusta que hable de su época con Perry en los microordenadores, él con los ports a C64 (6502) y Perry haciendo esos magníficos títulos para Spectrum (Z80).
Hizo un gran trabajo con los juegos de Shiny, de hecho supo explotar bien y sacar algo de partido extra a la SNES (teniendo en cuenta que sus títulos parecían diseñados pensando primero en la MD, o quizás en su resolución más estandar), consiguiendo darles a los títulos un sabor peculiar según cada plataforma.
PD:
Bueno, se me olvidaba poner algunas de las maravillas que se sacó de la mano de Perry para Spectrum:
https://www.youtube.com/watch?v=yWBRaa7aXqchttps://www.youtube.com/watch?v=HvV2KzG2Vuohttps://www.youtube.com/watch?v=MMuDrQ5SUbE&t=259shttps://www.youtube.com/watch?v=gxMvIUf_rPUhttps://www.youtube.com/watch?v=8gyQ07WN_lshttps://www.youtube.com/watch?v=JLcrTNKwKfsHay algo especial y muy típico en los juegos donde Perry trabajó, que es un tipo de fases muy recurrentes de "relleno" entre las principales de los juegos:
https://youtu.be/JLcrTNKwKfs?t=97Este tipo de fases es muy típico que aparecieran en los juegos no ya de 16 bits de Shiny, sino incluso en una forma glorificada en sus primeros juegos 3D, en MDK las fases de caída libre a las nave-bases enemigas consiste en una glorificación/homenaje a ese ya sello de identidad de Perry&friends:
https://youtu.be/RIFsF0RgESk?t=16Y por supuesto la variante de 16 bits de este tipo de fases, más "cercano" a la versión de las fases en juegos de 8 bits:
https://www.youtube.com/watch?v=dCwNOiLVbKsQue conste que MDK también tiene una versión más parecida de las fases, ahora que recuerdo:
https://youtu.be/yFvlAuX65K8?t=1103