Estamos en BASIC, creo que todas estas cosas de mapeado por tiles son demasiado costosas para un intérprete tan lento. Si introduces además un algoritmo de compresión las pantallas van a tardar un rataco en dibujarse.
Sea lo que sea lo que elijas, las pantallas van a tardar un rato en pintarse. Dependiendo del tipo de juego que estés programando te vendrá mejor una cosa u otra.
Yo he usado mapeado por tiles (de 3x3, o de 2x2, por ejemplo) y las pantallas, incluso en mi primera prueba, que usaba 5x5 tiles de 3x3 caracteres por pantalla, tardaban varios segundos en dibujarse. Tenía mi bucle principal, y luego un IF que veía qué tile tocaba pintar (leyéndolo con PEEK de una dirección de memoria), y luego tres PRINT con las tres filas de cada tile de 3x3... Todo muy poco eficiente.
Lo más rápido es intentar tirar de la potencia del PRINT todo lo que puedas.
En mis primeros juegos, que solían ser de plataformas, no mapeaba por tiles, sino que en cada pantalla pintaba las plataformas que necesitaba con PRINTs. Era lo más rápido. Pero esto no nos vale para otro tipo de juegos.
Lo más rápido, sin serlo realmente, para mapear por tiles, implica manejar muy bien los códigos de control de PRINT, cadenas, y toneladas de string slicing (se refiere a acceder para lectura o escritura a posiciones concretas de las cadenas). En BASIC, lo más rápido para copiar datos es la asignación de cadenas. Incluso, aplicando técnicas que rozan el hacking, pueden copiarse incluso pantallas enteras con un simple LET s$=a$... pero eso es otro tema que puedes investigar mirando en el foro de BASIC del WOS... Ya buscaré el enlace.
Lo que quiero decir es que lo más rápido es almacenar las pantallas en cadenas. Si, además, quieres tener un mapeado extenso, es mejor que los "tiles" que manejes sean mayores de un caracter: agrupaciones de, por ejemplo, 3x3 caracteres, formando un cuadro.
Puedes almacenar cada tile en una posición de un array de cadenas. Puedes usar incluso colores para cada carácter que los forma empleando los códigos de control de PRINT. Además, usaremos los códigos de los movimientos de control, para que con un simple PRINT AT imprimamos todo el tile. De este modo los cálculos se reducen al mínimo, ya que hay más tiempo de ejecución de la rutina de ROM que de nuestro programa interpretado.
Sirviendo como ejemplo, y sin usar colores, así crearíamos por ejemplo un tile de 3x3:
Código: Seleccionar todo
LET t$(4) = "ABC"+chr$(10)+chr$(8)+chr$(8)+chr$(8)+"DEF"+chr$(10)+chr$(8)+chr$(8)+chr$(8)+"GHI"
Eso definiría nuestro tile número 4. Los códigos que usamos son 10 (cursor abajo) y 8 (cursor izquierda). De este modo, un simple:
Imprimiría de un plumazo todo el tile 4, de 3x3, a partir de la posición y, x. Para pintar una pantalla de 5x4 tiles almacenada linealmente a partir de "addr", haríamos:
Código: Seleccionar todo
100 FOR y=0 TO 9 STEP 3: FOR x = 0 TO 12 STEP 3: PRINT AT y, x; t$(PEEK(addr)):LET addr=addr+1:NEXT x: NEXT y
Los tiles puedes definirlos, dejarlos en memoria, y luego eliminar las lineas que los asignan, para ahorrar espacio. Recuerda que, una vez creadas las variables, a menos que hagas CLEAR o RUN no se borran, y además se guardan junto con el programa con un SAVE.
).
Se me había ocurrido mientras escribía el post, y pensaba haber dado con algo interesante 
