Bubu escribió:OK, centrémonos entonces en el caso que propongo: el Frogger. Como ves, hay una carretera y un río. Unos coches van de izquierda a derecha y otros de derecha a izquierda, y cada fila a diferente velocidad. Al río le pasa lo mismo. Además, depende de la fase, salen más o menos coches y más o menos troncos. Pero eso sí, dada una fase, nunca cambian estos parámetros.
Dentro de una fase no cambian los enemigos, pero cada X segundos se oye un sonido como de espita de gas, y los coches y el cocodrilo de la última fila aumentan súbitamente de velocidad. Yo creo que incluso alguna fila multiplica su velocidad por dos.
Hay personajes que solo aparecen de vez en cuando, como la nutria que te muerde si estás en el extremo del tronco. Generalmente, parece que los objetos que desaparecen por un lado, luego aparecen por el otro, pero... a medida que aumenta la fase suelen tardar más en aparecer.
Todos los objetos de una fila se mueven a la misma velocidad, exceptuando la nutria, que a veces da un acelerón. La serpiente aparece sobre un tronco de las primeras filas o en descansillo de la mitad.
Es lo que he visto hasta ahora. Es un juego cuya versión arcade funciona en z80 a 3 Mhz, por lo que, en teoría, sería posible llevarlo al Spectrum. La pantalla tiene una resolución de 224×768.
Bubu escribió:Así las cosas, ¿cuál crees que sería el método más óptimo? ¿Imprimir una sola vez en pantalla la carretera y río, y entóns a scrollear píxel a píxel? Se me ocurre otra manera, creo que es la que más velocidad coge:
Tengo los sprites almacenados por un lado. Ahora, pinto en RAM (no en VRAM) cada fila del río predesplazada en todas sus posibilidades (uséase, 8 veces) tomando como gráficos los sprites almacenados y haciendo los desplazamientos en tiempo de ejecución, antes de empezar a jugar la fase. Ahora, tomo de ese buffer la fila con DESPL=0 y la pinto en VRAM. Pasado un tiempo determinado, tomo de ese buffer esa fila pero con DESPL=1 y la pinto en VRAM, encima de la que tenía DESPL=0.
Hay que borrar lo pintado, claro. Un truco sería definir un borde negro a los sprites de un ancho igual a la máxima velocidad que puede alcanzar. O usar un método de borrado tan sencillo como pintar 8 bytes 0 siempre.
El método que describes es lo que se conoce como doble búfer. Se puede hacer, desde luego, pero luego hay que ver cuánto tarda el micro en volcarlo todo a pantalla. ¿Y eso implica que también debe volcar las zonas vacías? Quizás perdemos las ventajas.
Los sistemas de doble búfer más inteligentes solo borran las diferencias entre cuadros y pintan solo lo que hay de nuevo. No es algo.... sencillo.
Bubu escribió:Así que lo único que voy haciendo aquí es LD A, (DE) + LD (HL), A todo el rato. Eso sí, el buffer ocuparía los 10 x 32 x 8 x 8 bytes, es decir, se necesita un buffer de 20KB. Téngase en cuén que el método anterior de hacer scroll de la VRAM de píxel en píxel haría que la propia rana hiciera scroll en la carretera
Con el buffer no, porque pinto la carretera, pinto la rana, pinto la carretera desplazada, pinto la rana, pinto la carretera más desplazada, pinto la rana, etc, etc.
Un LDIR podría servir para mover una línea entera del sprite, de (HL)++ a (DE)++.
El que haya una rana (y si luego pones a la rana macho, también) ya implica que no puedes hacer scroll en la parte de abajo. Sí en la de arriba, ya que todo se mueve. De todas maneras, yo creo que lo mejor es no desplazar toda la fila y pensar más en términos de Sprites.
Bueno... si el juego se hace sencillo, podría valer un desplazamiento de toda la fila, claro.