Sobre el tema del hilo, un KOF solo hubiese sido posible en una ROM de como mínimo 64 megas, y cuando digo como mínimo, es que con 64 megas también se hubiese quedado corto.
Argumento nº1: Ancho de banda para las animaciones. Si en snes hemos visto animaciones a una altísima tasa de frames perfectamente soportada por su DMA, entonces las animaciones del KOF 94 son posibles en una super nintendo teniendo en cuenta que el tamaño de los personajes del juego original es perféctamente análogo al del killer instinct.
Argumento nº2: Escenarios. Por número de planos, animaciones del decorado durante el combate, y complejidad de sus introducciones, los siguientes escenarios quedan dentro de las posibilidades de la super nintendo de forma directa dadas sus características y espacio de memoria dedicada a planos en la VRAM, y tan solo podrían haber algunas irrisorias discrepancias con el color, y casi imperceptible repetición de tiles:
-Inglaterra. Sin problema, la animación sucede arriba, y para cuando baja solo hay dos planos representados. El número de animaciones necesarias para el escenario es aceptable.
-China. Sin problema. La puerta no se abre mediante una animación, sino mediante un raster effect perfectamente realizable por HDMA, y mientras eso sucede aparecen visibles 2 planos mas, y eso entra dentro del límite porque el marcador solo aparece cuando desaparece la puerta, aunque la propia puerta quedaría forzada a tener una profundidad de color mas baja porque el tercer plano impone 4 colores por tile. Las animaciones para el plano van sobradas.
-Korea. Sin problema. Primero sucede un plano para las nubes y otro con la lluvia. Acto seguido sucede un plano para el rayo, y justo después sale otro rayo mientras ya se visualizan los dos planos del escenario. Con uno de los dos planos del escenario ya precargado antes de la escena, el dinamismo de la escena está garantizado. Sin problema también para la animación de los árboles, etc.
-EEUU. Sin problema. La reja se ve junto con los 2 planos del escenario, y esto entra dentro de los límites. Cuando se termina de retirar la verja es cuando se visualiza el marcador, así que siempre hay 3 planos, y la verja puede representarse con 4 colores sin notar diferencias. Sin problema para las animaciones.
-Portaaviones de rugal. Sin problema. El único efecto que abarca mucho área en realidad es un cambio en el patrón de los colores que puedes ejecutar mediante HDMA. Chupado. Y sin problema para las... ¿que animaciones?, ¿el globito terráqueo ese?.
-Italia. Toda la intro aparece arriba, y no se usan mas de dos plano, luego baja abajo, y siguen habiendo solo dos planos para el escenario, mas un tercero para el marcador en cuanto aparece. La animación de las banderas, dada su cadencia, es posible.
A falta de un análisis exhaustivo, los siguientes escenarios podrían suponer alguna pega debido a la extensión del plano que requiere de animación. Pero por otro lado, dado que cada frame de animación sucede cada (mas o menos) 20 tics, y sucede todo en bloque, en un principio el DMA va mas que sobrado para cargar las tiles necesarias para actualizar la animación a tiempo con incluso mucha antelación. En caso contrario exigiría algunos reajustes simplificando el dibujo, o repitiendo tiles ya animadas en lugar de cargar mas para otros detalles.
-Japón. La animación del suelo y los 2 planos del escenario entran dentro del límite, y el marcador solo aparece cuando el suelo ya ni está. Habría que vigilar la animación de la gente del fondo mientras se anima el suelo, aunque por suerte hay mucha repetición de tiles ahí, así que pinta a factible. En cuarentena. Entra dentro de los 45 KB de VRAM.
-Mexico. La columna y los 2 planos del fondo están dentro del límite, y solo cuando la columna desaparece es cuando aparece el marcador. La animación de todo el área dedicada al escenario parece factible, pero habría que analizarlo bien. Entra dentro de los 45KB de VRAM.
En ambos casos, en caso de saturación del DMA (que eso habría que verlo), se solucionaria reduciendo la velocidad a la que sucede cada frame de animación, y con eso solucionas el problema de un plumazo consiguiendo el mismo resultado visual con una mínima pega.
Argumento nº3: Acumulación de personajes. El máximo número de personajes que pueden llegar a exijir al límite de dibujado de sprites por scanline no supera en ningún caso los 5 personajes en pantalla, el cual por si solo entra muy dentro de las posibilidades de de dibujado de una snes, y solo en algunos casos muy puntuales una acumulación de magias muy grandes podría causar fllckering. La solución pasa por incluir a los personajes de cada equipo como parte del plano, y al "árbitro" de cada escenario mantenerlo como sprites. Perfectamente factible.
Argumento nº4 Calidad de los samples/tamaño de rom. Para mantener la espectacularidad del juego original, es necesario que los efectos de sonido suenen sin recortes, ni de duración del sample, ni de acortación mediante la aceleración de la reproducción del bit rate, ni de la reducción de lo que ocupa rebajando la frecuencia. Y para esto es vital que la rom sea grande. Es perfectamente factible para el spc700.
Argumento nº5 El sistema de sonido de la snes da mucho de si para tener grandes efectos de sonido, y samples para las músicas:
https://www.youtube.com/watch?v=LDvKwSVuUGAEso si, en todo caso yo centraria todos los recursos del spc700 para efectos de sonido a full 32khz 16 bits (sobradísimo solo para efectos), y el msu1 para músicas que no comprometan el resultado final.
![[pos eso]](/images/smilies/nuevos2/pimp.gif "pescador?")
![[+risas]](/images/smilies/nuevos/risa_ani3.gif "más risas")
