kusfo79 escribió:Me acabo de dar cuenta que como la resolución de la SNES es 256 (estaba pensando en los 320 de la mega), lo del límite horizontal no es tan importante, ya que justo te cabe para llenar la pantalla). Pero igualmente, sigue siendo mejor usar un plano, en Super tienes otros 3, y puedes usar los sprites para efectos móviles, etc, o para HUDs. Al revés, si usas los sprites de la manera que dices, no puedes hacer ninguna cosa de estas más que "pintando" en el lienzo.
Un plano viene bien si tienes pensado por diseño usar tiles de 2BPP, que te permitiría transferir el doble de gráficos, porque pesan menos que los tiles de sprites. en megadrive no te podrías aprovechar de esa ventaja, pero en snes si.
Usar sprites tiene la ventaja de que no va a influir jamás en la suavidad del scroll. Fíjate en el wolfenstein 3D, me juego el huevo izquierdo a que si el plano en el que se desarrolla la acción fuese a 2BPP, podrías aumentar la resolución, porque cabría mas material gráfico por frame (actualmente un pantallazo entero necesitaría casi 29KB, así que tuvieron que reducir el área de la pantalla muchísimo, pero a 2BPP con 14KB es mas que de sobra, y con desactivar solo unos pocos scanlines podrías aumentar mas del doble la resolución, y su nitidez).
kusfo79 escribió:Eso si, no entiendo a que te refieres con lo de desplazar el escenario al final de tu frase.
Si metes en el plano no solo el streaming de tiles para los objetos, sino también del propio plano, cada vez que se desplace este tendrías que actualizar toda la pantalla.
kusfo79 escribió:BTW, igualmente, habríamos de ver cuantos tiles puedes actualizar en este lienzo cargandolos desde la ROM/FX, el DMA es el límite ahí.
A 256x200 tienes un ancho de banda de 10.259 bytes, que son 641 tiles de 2BPP. Muy importante que los scanlines desactivados vayan en grupos de 8, por ejemplo una franja negra de 16 pixels de ancho abajo, y una de 8 pixels de ancho arriba.
Tenemos en el modo 0 cuatro planos de scroll, y usamos uno únicamente para representar los objetos, siendo todo lo demás transparente... y los otros tres planos conforman el escenario con tiles ya preinstaladas en 45KB de vram (creo que es la cantidad destinada a planos en memoria), por lo que no habría que estremear nada para los escenarios.
¿Cuanta área de pantalla pueden ocupar los personajes, teniendo en cuenta que saltan, etc, etc, etc?, 641 tiles de 896 significa que puedes actualizar el 71% del área de la pantalla de los objetos a cada frame, y si los personajes nunca van a sobrepasar el 60% del área de la pantalla (por ejemplo), ya lo tienes hecho.
Otra opción, si los objetos pueden deambular por toda la pantalla, es bajar el frame rate a los 30fps, o depurar el streaming para solo actualizar las tiles solo de las zonas en las que se detecte un cambio. La diferencia es que con el primer método no tienes que ponerte a ver que tiles cambian, y eso tal vez alivie algo a la cpu.
Sea como sea, es viable. Con un chip de apoyo que ofrezca mucho tiempo de proceso, puedes hacer cosas realmente bestias teniendo en cuenta que te saltas dos límites muy importantes (¿Cuanto ancho de banda, y cuanto fill rate requiere un allien vs predator?, pues sería posible igualarlo, e incluso superarlo).