Señor Ventura escribió:Sexy MotherFucker escribió:@Dany ROD te dejas que la vram de MD es 100% flexible (y rápida cara al VDP) puediendo administrar los tiles de fondo y sprites como le de la gana, mientras que la de SNES está castrada con un espacio fijo para fondos, y otro para sprites, permitiendo a la consola de SEGA poner más variedad de elementos diferenciados en el campo de los sprites si se quiere.
Si, transfiere bastantes mas tiles a la VRAM que la snes, pero esto es así a menos que sean tiles de 2BPP, en cuyo caso las tornas se cambian, y además a lo bestia.
Tampoco creas que el tener un espacio prefefinido para tiles de sprites y de planos limita tanto. Que sea una cagada no significa que se haya planificado mal, de hecho el hyper pensado paprium haciendo gala de este tipo de virtudes de la megadrive, sigue estando dentro de los márgenes de la snes. Sin ir mas lejos, los sprites de esta imagen ni siquiera llegan a los 13KB:
Sexy MotherFucker escribió:Ejemplo: Gunstar Heroes, muy chungo de emular en SNES a nivel de variedad de enemigos/elementos en la escena.
Efectivamente, parece ser que es bastante común encontrarse con mas de 15KB de sprites en un frame, y por lo tanto no hablamos de que sea mas chungo de emular en snes, sino que es físicamente imposible.
Sexy MotherFucker escribió:Todo esto dejando a un lado que la MD tiene una tabla de atributos para sprites más solvente, y de que la definición de contornos de estos en muchas ocasiones es superior por motivos de resolución
Ni idea de que tipo de información anexa la megadrive a los sprites en su tabla OAM, pero en snes defines lo siguiente:
-Coordenada X
-Coordenada Y
-Posición
-Numeración (identificación)
-Atributos (flip horizontal, flip vertical, cambio de paleta y/o orden de colores, prioridad de plano, y no se que mas).
-Tamaño de tile, agrandando o empequeñeciendo (sin "animación" de escalado, pero puedes variar su tamaño).
Ignoro de que manera la megadrive pueda tener una tabla de atributos mas solvente y útil que esta, pero de por si no es manca tampoco.
Y sobre la definición de contornos, es cierto, a mas resolución, mejores contornos, especialmente a tamaños menores (aunque es paliable simplemente cropeando la imagen: es decir, obtienes lo mismo, pero con menor campo de visión).
Pero la otra cara de la moneda es lo que está dentro de los contornos, y aquí la snes dispone de una clara ventaja al poder "rellenar" las tiles con mas información, o en su defecto con colores que favorezcan un mejor degradado, y por lo tanto una mejor definición.
Del modo 512x224 ni hablemos xD
Sexy MotherFucker escribió: @Dany ROD a 3,58 Mhz lo tendrás cuando no le toque acceder a la wram, ya que ahí penaliza un ciclo de reloj aproximadamente siempre.
Un pequeño inciso. La snes no penaliza con un ciclo de reloj adicional, ya que siempre accede a memoria cada ciclo, lo que ocurre es que a menos mhz tienes menos ciclos.
Ahora, dentro de un frame no es mas que una pequeña fracción de ese tiempo en la que la cpu baja de 3,58 a 2,68. Lo necesario para leer/escribir, y volver a su frecuencia.
De hecho la megadrive a pesar de tener una memoria a mas frecuencia y con menos lag, accede a ella cada 4 ciclos, y tanto en parcial como en global, la snes es un 139% mas rápida accediendo a memoria (accediendo, no leyendo/escribiendo, que en estos casos sigue siendo superior, pero ya baja algo).
Gammenon escribió:El tema de los sprites de Mega Drive y SNES se ha comentado muchas veces en el foro, la Mega Drive es más flexible a la hora de gestionarlos por lo que en muchas ocasiones el resultado final que hay en pantalla es superior que a la de SNES.
Se toma esto como una norma fija, y todo dependerá de lo bien que se hagan las cosas. Estamos demasiado acostumbrados a ver como se derrochan sprites en snes, ocasionando muchas veces incluso parpadeos cuando de una forma mejor planificada podría evitarse, y por culpa de eso se ha extendido la creencia de que la megadrive pone mas sprites, mueve mas, e historias varias.
Paprium de megadrive:
SNES usando
78 sprites, y nunca sobrepasando su límite por scanline: