Mensajepor na_th_an » Jue, 27 Feb 2014, 14:52
EDITO: Había escrito lo de abajo pero caigo en la cuenta que es posible que necesites todos los bytes que vas descomprimiendo para obtener los siguientes dependiendo del tipo de descompresión, así que lo que se pide es imposible.
-----------------
$this->bbcode_second_pass_quote('antoniovillena', 'Q')ue sí, que lo he entendido bien. Si el stream descomprimido es de 2048 bytes (ventana de 2048 bytes) necesitas 2048 bytes de RAM sí o sí, independientemente de que sólo necesites la mitad. Imaginate que sólo quieres los tiles impares (cadena 101010101...).
Tendrías que descomprimirlo todo en un buffer de 2048 bytes, luego ya si quieres reordenas y te quedas con los 1024bytes de los tiles impares (desechando los otros 1024 bytes). Para la forma que el quiere de descomprimir habría que reducir la ventana al tamaño de 1 tile, es decir a 36 bytes. Sería más o menos como está el descompresor de mapas, existen tantos streams descomprimidos como pantallas, con un tamaño de ventana pequeño (150 bytes), con lo que se pueden descomprimir pantallas sueltas. Sólo que en el caso de los tiles la reducción de ventana a 36 bytes limita mucho más el ratio.
Es que por lo que me pones creo que lo que pretende elborra no es lo que tú dices
Claro que necesitas los 2048 bytes de RAM sí o sí: es el destino de la descompresión. Lo único que digo es que la parte de la rutina descompresora que escribe los bytes en esos 2048 bytes de RAM escriba sí o no dependiendo de una condición.
Es eso: descomprimir como siempre, se podría hacer con aplib incluso, no hace falta nada raro. Sólo que a la hora de escribir el byte que acabas de obtener en el destino, lo haces o no lo haces dependiendo de una condición.
Sólo tenemos un stream comprimido, sólo que la escritura en "la salida" es condicional. Se descomprime el stream completo, pero no se escriben todos los bytes.
Él lo que pretende con esto es descomprimir un tileset sobre el que ya hay y que se respeten los tiles que coincidan con los huecos de la máscara.
Tengo claro que tal y como funcionan los descompresores, que no obtienen los datos secuencialmente, la lógica para implementar esto podría ser bestial. Por eso dije al principio que al final lo que se ahorraría con la compresión a lo mejor se lo gastaba en un descompresor complejísimo
Es como cuando pintas un sprite con máscara, que dependiendo de la máscara pinta los pixels o no - pero los lees de todos modos, incrementas los punteros de todos modos, etcétera. Aunque al final sólo pintes 100 pixels, has leído 256, pero algunos de ellos no los has pintado porque coincidían con la máscara.
Siguiendo tu ejemplo de los tiles impares, sería poner a descomprimir el archivo comprimido. Si los bytes que descomprimes caen en las posiciones correspondientes a los tiles impares, los escribes. Si no, los desechas.