Vuelvo a reflotar el tema con una duda de compresión.
Tengo una duda, no tanto de la adaptación ZX7+RCS que hicistes para los mapas de la churrera (que buen uso le estoy dando ^_^) sino al tema de las rutinas de descompresión y la viabilidad o no de una idea que a continuación te expongo. Todo esto viene porque ya sueño con bits, bytes y tiles y una cifra constante de fondo: 36,5K. Entre todo ese batiburrillo de pensamientos cruzados me vino una idea de imposible ejecución por mi total ignorancia en algoritmos de compresion y ensamblador
Por ahora tanto con aapack como con ZX7 descomprimimos el binario entero a una zona de la memoria. Bueno, realmente en la función C le pasamos la dirección de memoria donde está el binario y la dirección de destino (lo que ocurre en la trastienda con asm y tal ni idea, a cada página del hilo en WOS sobre ZX7 menos me enteraba XD, algo he pillado pero no mucho). En fin, la cuestión es poder descomprimir el binario pero OBVIANDO parte de los datos según le indiquemos a la rutina de alguna forma.
¿Para que? pues, en mi caso concreto, para tener todos mi 'sets' de tiles en sólo 2 ficheros: 1 para los gráficos y el otro para los atributos (ahora tengo 20 ficheros binarios, 10 y 10)
¿Por qué? pues porque no es lo mismo lo que ocuparian los 10 binarios en un sólo fichero y comprimirlos que individualmente tal como lo tengo ahora (en mi caso ahorro más de 500 bytes)
¿y como me gustaría (de poderse) que funcionara? ¿qué es eso de OBVIAR XD? Centrándonos en los gráficos en si y siguiendo mi caso; una vez generado el binario con todos los tiles (+80) y comprirlo está claro que sólo voy a poder usar 48 de ellos. Como gestionar esto...
Si cada tile lo forman (descomprimidos) 32 bytes quizás sería posible en el proceso que ciertos conjuntos de 32 bytes descomprimidos no machaquen el tileset[], quizás esto no sea siquiera posible por la rutina en si misma (la manera de leer y descomprimir no sea ordenada o vaya usted a saber.... yo estoy pez). De ser esto viable ya "sólo" quedaria decirle a la rutina que conjuntos de 32 bytes queremos descomprimir y cuales no. Y digo descomprimir por llamarlo de alguna manera, a mi me daría igual que se procese todo el fichero pero los datos los vaya depreciando o no según otra estructura o lo que haga falta.
Más que nada me gustaría saber si esto es posible o no. De ser posible yo no tengo los conocimientos para hacerlo y por ello quiero dejar claro que no estoy pidiendo que lo hagais cualquiera de vosotros; dependerá de la complejidad, las ganas, y por supuesto si creeis, en definitiva, que merece la pena. Yo lo único que puedo hacer es de conejillo de indias xD.
Ejemplo explicativo final
:
- Por un lado tengo un fichero binario de 82 tiles (por poner) = 2624 bytes
- Compririamos con aapack o zx7 = tamaño variable
- Dentro del código del juego tendria una estructura (es lo primero que se me ha ocurido y seguramente sea la peor idea de todas ya que quizás lo que ahorro en compresión lo pierdo con estas estructuras), con la información de que tiles tengo que extraer en tileset[]; por ejemplo: el 0,1,3,5,7,12,34,36,37,58,59,60,61 ....... 80 (48 tiles).
De alguna manera la rutina descompresora tendría que ir recorriendo esa estructura (llamemosla "quetiles" a la vez que va descomprimiendo)
En definitiva,una aproximación cutre de la rutina descompresora en pseudocodigo sería:
$this->bbcode_second_pass_code('', '
quetiles = 0,1,3,5,7,12,34,36,37,58,59,60,61 ....... 80, //set 1
3,5,7,9,11,14,15 ......................................., //set 2
etc....
posicion_en_quetiles= n // 48*set
dirección_descomprimir = tileset+512 // tile 0
numero_tile = quetiles[posicion_en_quetiles]
MIENTRAS {
DESCOMPRIMIR 32 BYTES DEL BINARIO EN dirección_descomprimir // En esta aproximación los datos siempre van a parar a direccion_descomprimir, pero como esta no se actualiza si no es el tile requerido se machacará por el correcto cuando toque
SI (dirección_descomprimir == numero_tile) ENTONCES
direccion_descomprimir+=32
posicion_en_quetiles++
numero_tile = quetiles[posicion_en_quetiles]
FINAL SI
} no_hayamos_acabado_de_descomprimir')
Esta claro que esto sólo sería posible si la descompresión es ordenada, supongo. Además habría que ver como pasar los datos de que tiles usar o no, ya que una estructura pelada como la que planteo ocuparía más de lo que ahorramos por otro lado. Quizás a nivel bit donde con cada byte podriamos representar que tiles entre 8 estan activos o no. (podriamos representar cada set con 8-9 bytes) Aparte habría que hacer lo mismo pero con los atributos, es decir en lugar de ir de 32 bytes en 32 sería de 4 en 4.
Ahí lo dejo....