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: