Haplo escribió:No sé exactamente qué significa ese término ¿datos de sprites organizados de cierta manera para optimizar su lectura?
No: es una técnica para dibujar sprites que consiste en que la rutina que dibuja los sprites, en lugar de dibujarlos, lo que hace es crear una ristra de secuencias de código máquina, por ejemplo del tipo:
Y así con cada byte que haya que dibujar en pantalla (o bien cualquier otra secuencia más optimizada si procede). Este "sprite compilado" se genera mientras la pantalla está siendo actualizada, con lo que tienes unos 68000 estados para hacerlo para todos los sprites. Luego, cuando has terminado y se inicia el refresco vertical lo que haces es llamar a la rutina que tú mismo has creado, para que ésta pinte los sprites.
Mejor lo ves en esta pequeña demo que hice. Muestra 60 pequeñas bolitas de 2x2 píxeles en pantalla a full frame rate. Mira el código fuente y te harás una mejor idea, espero. Ensambla con PASMO.
http://www.atc.us.es/~rodriguj/demo_sim ... ilados.zip-- Actualizado 10 Jun 2015, 22:28 --
mcleod_ideafix escribió:Poder se puede, pero no es trivial. Como apunta scooter, manejar un color transparente para sprites implica que el pintado completo del sprite lo haga el hardware.
Hay otra opción. Acabo de acordarme de una cosa que hacen las tarjetas VGA y es el poder enmascarar las escrituras a memoria de pantalla. La idea, aplicada al ZX Spectrum sería la siguiente: tener un puerto de E/S que permita o no el enmascaramiento.
Si no se permite, todas las escrituras al rango de memoria de pantalla funcionan como siempre.
Si se permite, entonces el enmascaramiento funciona de la siguiente forma: el dato en binario a escribir se puede representar como ABCD EFGH donde cada letra es un bit. El mecanismo de máscara comprueba qué grupos de bits son 0000, y los que tengan ese valor no se escriben a memoria, sino que se deja el valor de los cuatro bits que ya hubiera en memoria.
Para implementar esto en hardware sin necesidad de tener que realizar dos operaciones de memoria, se puede hacer usando como backbuffer memoria interna de la FPGA (sólo harían falta 6144 bytes). Cada vez que se haga una escritura, se hace también en ese backbuffer, y cuando haya que leer el valor actual de una posición de memoria para aplicar o no la máscara, se lee de ese backbuffer, que es muy rápido.
Los implementadores de juegos: ¿creeis que merece la pena añadir esto al modo radastaniano? Como está aún en fase de definición, podemos quitar y poner lo que nos dé la gana, y esta es una característica que puede ser completamente ignorada si alguien quiere usar "CPUpower" para su juego. Yo particularmente no le veo mucho beneficio, pero tampoco soy el más indicado para opinar en este aspecto.