Veamos, pido sugerencias, pero si alguien me quiere hacer el código en plan Andrea, por mi parte encantado 

Ejem, dejemos el espinoso tema y al grano 

Resulta que ya tenía ultimada una rutina de mapeado que usa tiles de 4x4 y un editor de pantallas y sprites customizable (que dicen los guiris) Por supuesto al alcance de cualquiera que los quiera examinar/usar (contactar con moi, no problemo).

El caso es que para plataformas está bien (explotando la circunstancia los estoy haciendo como churros), pero desde tiempos remotos los juegos con scroll (en plan Gauntlet, Jet bomber o más horizontal tipo Universe Unknown o Nemesis) me han planteado el reto de cómo afrontarlo.

Así que armado de asmsx al uso, escribí una rutina y un editor que muestra una zona de ram en pantalla (definiendo el tamaño del mapa, p.e. 100x80 caracteres) y te puedes mover por él enb todas direcciones, moviéndose la pantalla en scroll y el personaje quieto).

Mu gonito todo, pero claro, memoria chupa que ríete tú de Jeanna Fine. Al ir los caracteres almacenados en ram a lo burro, no te permite usar grandes mapeados.

Si uso la técnica de los tiles 4x4, p.e. (por eso del reciclado ) tendría que hacer el scroll de 4 en 4 caracteres, y es un poco bestia. ¿Qué técnica me aconsejáis? ¿Cómo están hechos esos juegos comerciales? Con una guía me basta, pero me abriría las puertas a un nuevo mundo de sensaciones (ottia, qué mal suena eso )

Como siempre (pidiendo mucho) gracias por anticipado y besitos 

O una variante de lo que comenta Sapphire y que para scroll multidireccional es el que suele dar más velocidad:


De manera que tienes un area de 64*48 caracteres (3072 bytes), que no es poco la verdad; pero puedes conseguir un scroll  bastante rápido. Vuelcas los tiles 4x4 como caracteres en la esquina adecuada (el juego tiene que comenzar la fase sólo con dos posibles direcciones de movimiento para simplificar algo), si al principio sólo se puede ir hacia la derecha o hacia arriba (clásico Megaman por ejemplo) vuelcas en la inferior izquierda y una fila o columna extra de tiles en funcion de la direccion en la que estés moviendo, por encima o por debajo y ya tienes datos para volcar a VRAM 768 bytes, vas deplazando la ventana y cuando acabes el margen que te has concedido con esos tiles extras, pues vuelcas más tiles en la misma direccion, o si vas en diagonal en ambas. El problema lo tienes cuando se te acabe el ancho/alto de la ventana virtual, en ese momento tendrás que hacer un LDIR (1536 bytes), así a ojo, de las dos pantallas vituales que están en tu mitad a las opuestas, cambias la ventana de mitad y empiezas otra vez repitiendo todo el algoritmo.

No se si ha quedado muy claro....¿más ideas? 

Recomendación para un tipo Gauntlet? Usar nibbles en lugar de bytes y después compresión en RLE o incluso BitBuster. Y después, lo vuelcas en un mega buffer en RAM y de ahí a cada posición de pantalla. Te ahorrarás muchos problemas, palabrita.

No te creas, Darth. Te pongo dos ejemplos:

1. En el Saimazoom el mapa está definido por nibbles (cada tile, un nibble). Pero si cuentas las tiles distintas que hay, no te saldrán las cuentas, ya que las tiles decorado + los items + las tiles del rio, en total suman unas 28 tiles distintas o así. ¿Donde está el truco?. En que nunca salen las 28 tiles en la pantalla a la vez , así que puedo definir de las 16 tiles que 4 de ellas sean cambiantes dependiendo de la localización en la que esté. Luego guardo un pequeño index que ocupa pocos bytes que indica cuales son esas 4 tiles en cada pantallita y listo. Redefinición al poder.

2. Mapas a nivel de bit. Si, si, unos y ceros y a tomar vientos. Lo importante es la rutina que renderizará el tema.
Imagínate una pantalla definida así.


(The Legend of Zelda, NES)

Cómo ves, las tiles son distintas, pero solo en apariencia al ser renderizadas, no en el buffer. Es decir, esta pantalla está definida con unos (pared) y ceros (hueco "pasable"). ¿Que ocurre?. Que el programa, al pintar cada tile, COMPRUEBA CUALES SON LAS TILES QUE LA RODEAN... así, un "1" rodeado de "0"s por todas partes se renderiza con la tile de la roquita independiente, un "1" rodeado de "1"s resulta ser una pared y un "1" con un "0" debajo y a la derecha y un "1" arriba y a la izquierda se convierte en una tile de "esquina". Es decir, que controla gráficamente 10 tiles distintas (las 8 direcciones + la del medio + mas un "1" rodeado de ceros), tan solo con bits!. Así, esta pantalla de 16x11 tiles (bits) ocupa 176 bits, osea ¡¡¡22 BYTES!!! (y todo esto sin comprimirlo después con RLE!!!!). Claro, así te puedes cascar un mapeado acojonantemente gigante. Ahora tu me dirás... y los enemigos de pantalla?, y las puertas?... pues los enemigos de cada pantalla puede ser un byte más en la cabecera de cada pantalla (ese byte indicaría el tipo de "party" de enemigos). Podríamos usar otro byte para definir el set de tiles a utilizar para que muestre difierentes tiles (podemos tener varias de esas 10 tiles, por ejemplo decorado montañoso, de playa, un bosque).Y las puertas, cofres y demás, formaría parte de un index de excepciones que llevaría un buffer aparte. ¡Y ya está!.
CÁLCULO: Así tenemos que cada pantalla=24 bytes (party monstruos(1 byte), tileset(1 byte), map data (22bytes)) > 4800 bytes=200 pantallas!!! (y esto, sin una compresión posterior). ¡Y mostrando mogollón de tiles distintas!.

Lo único es que esto es válido para un juego pantalla a pantalla, aunque también podría valer para tu scroller si renderizas todo el tema en RAM y luego lo vas volcando como apuntaba jltursan.