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...
![[qmparto]](/images/smilies/net_quemeparto.gif "Que me parto!")
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 
![[+risas]](/images/smilies/nuevos/risa_ani3.gif "más risas")
), por eso le doy el beneficio de la duda. Pero vamos que lo suyo es poder guisárselo uno mismo y comprobarlo. Yo no tengo las herramientas desgraciadamente.![[sonrisa]](/images/smilies/nuevos/risa_ani1.gif "sonrisa")
![[carcajad]](/images/smilies/nuevos/risa_ani2.gif "carcajada")
![[oki]](/images/smilies/net_thumbsup.gif "Ok!")
![[poraki]](/images/smilies/nuevos/dedos.gif "por aquí!")
![[hallow]](/images/smilies/nuevos/hallowen.gif "calabaza")
![[burla2]](/images/smilies/nuevos/burla_ani1.gif "burla2")
