Página 21 de 22
Re: Compresor de mapas
Publicado: Jue, 27 Feb 2014, 10:15
por elborra
$this->bbcode_second_pass_quote('na_th_an', 'S')egún yo he entendido, lo que dice el_borra es que haya trozos del binario descomprimido que no se escriban. Por ejemplo, podría hacerse un descompresor que fuera sacando bytes y sólo escribiese cuando el byte que ha sacado es distinto de cero, o está en un rango, pero que siempre fuese incrementando el puntero de escritura. Sería descomprimir el binario entero, pero sólo escribir en el buffer de salida los bytes descomprimidos según cierta máscara, dejando los demás bytes sin tocar.
Más o menos, aunque precisamente lo que necesitaría es que el puntero de salida pudiera a cada 32 bytes (para tiles) o 4bytes (para atributos) decrementarse esos mismos bytes dependiendo de la máscara
Re: Compresor de mapas
Publicado: Jue, 27 Feb 2014, 11:04
por na_th_an
Creo que lo que pides es tan complejo que al final el código para gestionarlo ocuparía más que lo que ahorras con la compresión.
Re: Compresor de mapas
Publicado: Jue, 27 Feb 2014, 13:25
por antoniovillena
Si yo lo había entendido bien antes. No existe a día de hoy ningún método de compresión que te permita extraer datos del stream comprimido con una ventana de RAM menor con la que se ha comprimido. En resumen:
- O usas una ventana de 36 bytes con lo cual el ratio de compresión se reduce muchísimo pero puedes descomprimir los tiles que quieras.
- O usas una ventana mayor que te dé unos ratios de compresión decentes, pero con un buffer de descompresión grande, con lo que al final tampoco ganas mucho con la descompresión.
Por experiencia yo creo que lo que podría dar algunos resultados (aunque pobres) es tener 3 sets de tiles o más, que todos tengan el mismo número o parecido de tiles y no comprimir los tiles comunes a los 3 sets. Por ejemplo si tenemos 16 tiles comunes estaríamos hablando de almacenar 3 sets de 32 tiles cada uno, en total 96 tiles. Seria un buffer de descompresión de 1152 bytes, y suponiendo un ratio del 50% los 3 streams comprimidos ocuparían 1728 bytes, que añadidos a 150 bytes de una posible rutina descompresora nos da: 1152+1728+150= 3030 bytes. ¿Cuánta RAM ahorramos con esto? Pues esos 96 tiles sin comprimir nos ocuparían 96*36= 3456 bytes, vamos que serían poco más de 400 bytes. Ojo, esto sería suponiendo un 50% de ratio, si se comprime peor nos ahorraríamos menos bytes (o incluso podemos perder bytes con la compresión).
Re: Compresor de mapas
Publicado: Jue, 27 Feb 2014, 13:43
por na_th_an
Es que yo creo que eso no es lo que él dice.
A ver, imaginate que comprimes un tileset completo de 2048 bytes. Él quiere una forma de descomprimir ese tileset completo pero que sólo se sobrescriban unos datos sí, y otros no. O sea, tú estás descomprimiendo los 2048 bytes normalmente, pero en el trozo de memoria de destino sólo escribe los datos si se cumple cierta condición.
Por ejemplo, imaginate (en plan penco) que tenemos esos 2048 bytes divididos en cuatro trozos, y tenemos cuatro banderas que indican si cada trozo se va a escribir o no en el destino.
Tú empiezas a descomprimir. Si la bandera correspondiente al trozo actual está activa, los bytes que descomprimes los escribes en destino. Si no está activa, los bytes que descomprimes simplemente "los olvidas" (pero sigues incrementando el puntero de destino para que cuando llegue una bandera activa los datos se escriban en su sitio)
Algo así, creo que es.
Básicamente es como almacenar comprimidos los tilesets completos (vaya, está almacenando los tilesets completos), pero esos tiles que luego no se van a escribir en el destino podría tenerlos perfectamente todos a 0, con lo que la compresión sería mayor que tener los tilesets completos con los tiles repetidos.
*creo* que se refiere a eso
Re: Compresor de mapas
Publicado: Jue, 27 Feb 2014, 14:06
por elborra
Ok, explicado queda, muchas gracias a los 2
Ya he terminado con la lógica del juego, 572 líneas puras de scripting XD y se me ha quedado el binario del juego en 36.435 bytes
a falta como dije de meterle la pantalla de titulo y la de ending que las puse negras.
Voy a darle una última oportunidad a los 48K cambiando código y posiblemente buscando coincidencias en el scripting y pasarlas a extern (aunque no voy a conseguir mucho rascando de allí) y a ver que pasa.
Re: Compresor de mapas
Publicado: Jue, 27 Feb 2014, 14:09
por antoniovillena
Que 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.
Re: Compresor de mapas
Publicado: Jue, 27 Feb 2014, 14:52
por na_th_an
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.
