naxeras escribió:@cirote3 Si, al final el secreto de KI al parecer es que es un juego de 30fps y de ahí la ausencia de bandas que caracterizan tanto este genero en SNES
Lo que da la impresión tras tu análisis @M68K es que si parece es que al ser un juego de 30fps se podria haber achuchado un poco más y haber puesto los personajes mas grandes pero supongo que es dificil estar seguros.
cirote3 escribió:naxeras escribió:@cirote3 Si, al final el secreto de KI al parecer es que es un juego de 30fps y de ahí la ausencia de bandas que caracterizan tanto este genero en SNES
Lo que da la impresión tras tu análisis @M68K es que si parece es que al ser un juego de 30fps se podria haber achuchado un poco más y haber puesto los personajes mas grandes pero supongo que es dificil estar seguros.
Ojo que el Killer Instinct de la SNES va a 60FPS, no a 30.
Los personajes, el scroll del fondo, etc. se mueven a 60FPS. La única limitación es que los dos personajes no pueden cambiar de animación en el mismo frame, aunque sí puedan cambiar de posición. Si el juego funcionara a 30FPS se vería mucho peor, sería un poco infumable





Señor Ventura escribió:entre cuadro de animación y cuadro de animación pueden pasar unos 3 frames, luego, cada frame necesita transferir 1500 Bytes antes de tener listo el cuadro de animación completo

cirote3 escribió:Señor Ventura escribió:entre cuadro de animación y cuadro de animación pueden pasar unos 3 frames, luego, cada frame necesita transferir 1500 Bytes antes de tener listo el cuadro de animación completo
Supongo que como no lees los mensajes de los demás no leíste lo que ya se explicó en este hilo, pero bueno, volvemos a intentarlo
En cualquier juego de lucha el tiempo que pasa entre que por ejemplo pulsas el botón de andar y el personaje se pone a andar es mínimo, un frame o como mucho dos a veces, como pasa en el Killer Instinct. Lo mismo pasa con cualquier botón de ataque, si el personaje se agacha o salta, etc. Meter tres frames de lag en cualquiera de esas acciones es infumable, te cargas el juego.
Incluso si el juego llevara un personaje secreto no controlable por el jugador para esconder el lag con él y hacerlo gigante, no se podría actualizar cada tres frames porque en los juegos de lucha las animaciones son cancelables: en cualquier frame un personaje puede recibir un golpe y hay que mostrar en ese momento la pose de daño, no tres fotogramas después.
Incluso si todo lo anterior no importara o no fuera cierto, actualizar los personajes durante varios frames implica tener dos copias de cada personaje en VRAM, la que se muestra en pantalla y la que se está escribiendo. Como solo hay 16KB de VRAM para sprites, cada personaje tendría que tener menos de 4KB, ya que también hay que meter las bolas de fuego, los flashes de los impactos, etc. Si cada personaje tiene que tener menos de 4KB, actualizarlo durante varios frames sería estúpido, ya que con ese tamaño debería ser posible actualizarlo en un solo frame.
Si has llegado hasta aquí y no me crees porque crees que cuando respondo a tus mensajes te estoy vetando, te estoy faltando al respeto, estoy convirtiendo este hilo en un estercolero y estoy buscando bronca continuamente, te animo a que busques un juego de lucha que actualice animaciones cada tres frames y hables de él en este hilo, con pruebas y tal. Puede que tardes un poco en encontrarlo
naxeras escribió:En cuanto a neogeo precisamente es dónde no esta apretado porque si mal no me equivoco no tiene que ir copiando los frames de animacion a ninguna memoria intermedia, lo lee directamente del cartucho lo que le permite animar y de hecho anima los luchadores gigantes cada frame sobrando ancho de banda para meter tropeciantas animaciones automaticas en los fondos a cascoporro que ni siquiera usan la CPU y que las otras consolas de 16bits no tienen, pero vamos no es que sea experto en el sistema aún asi es algo que siempre he leido y una de las muchas cosas que diferencia la NeoGeo de las otras 16bits.

naxeras escribió:¿En otro orden de cosas, como se anima un fondo por HDMA? entiendo que esta limitado porque serian como efectos sobre el plano existente.

SuperPadLand escribió:
Tiene pinta de que necesitará esperar al SFX4
Bimmy Lee escribió:Ventura suelta una de las suyas, el resto pasa a contestarle en lugar de ignorarle y ya tenemos de nuevo el bucle.
Qué pereza de hilo.

naxeras escribió:SuperPadLand escribió:
Tiene pinta de que necesitará esperar al SFX4
Yo no le veo sentido a esto, es como el Doom que hay de megadrive para el everdrive que va fino fino pero al final lo que hace la consola es un pass through que el chip le dibuja en la VRAM. Claro si nos ponemos quisquillos lo mismo pasa con el SFX original, la consola procesa el sonido y poco más y si encima usaramos MCU ademas del SFX pues ya ni eso. Luego puedes "enmascararlo" por ejemplo ejecutas el UI en un plano y ya está haciendo algo la consola en si, pero claro aqui toco hueso y da miedo comentarlo.
Es como el supergameboy, la consola no está moviendo el juego de gameboy lo hace el chip del cartucho. (Que basicamente es una GB). Por mucho que tengas un plano que dibuja un borde o incluso que el juego en concreto del SGB use en parte el chip de sonido de la SNES.
No se, tengo el corazon dividido con los chips de mejora sobre todo cuando son muy burros.
Un Saludo.
Bimmy Lee escribió:Ventura suelta una de las suyas, el resto pasa a contestarle en lugar de ignorarle y ya tenemos de nuevo el bucle.
Qué pereza de hilo.
Señor Ventura escribió:-Dos chang koehan en esa demo son algo mas de 9000 Bytes (aunque se puede optimizar ligeramente). Atribuir que hacer doble buffer supera los 16KB de límite es atribuirme un argumento que yo no he dicho por ningún lado en ningún momento, por no hablar de que es afirmar erróneamente que el programa funciona así. Sin embargo, lo correcto se invalida, y lo incorrecto se valida.
Señor Ventura escribió:-Sobre el lag, son rarísimos los ejemplos, si es que existen, que consten de únicamente un frame desde que pulsas un botón, hasta que se sucede la animación. Hace ya tiempo se estuvo debatiendo sobre esto en este foro, y entre todos los juegos analizados habían ejemplos que alcanzan incluso los 7 u 8 frames de retraso (como el B.O.B, aunque este ya es otra anomalía, pero en el otro extremo), y de media el dato se estableció entre los 2 y los 3 frames de media. Es decir, existe una base para realizar esta afirmación.
Señor Ventura escribió:Estos dos puntos son correctos, o al menos están orientados hacia lo correcto.

Señor Ventura escribió:El resto también tiene una explicación, pero cuando esta consiste en tener que quitarle todas esas capas, es que el debate no va por donde tiene que ir. No contesteis.