nhp y cain

[dogdark]

ese compresor se puede ver con que????? en assambler o ????

[Fékero]

Si.Ese es...
Saludos.

Parche podrías dar mas detalle de la funcion o que mision cumplia este compresor/descompresor.

[parche]

La misma que hoy cumple el WinZip. Comprimir código para empaquetar. Por ejemplo, el Beach Head cargaba varias pantallas. Una solución fue tomar las pantallas, meterlas en este compresor, guardarlas bajo la rom o en algunas ocaciones también guardamos pantallas bajo los bancos de memoria del 130 XE, para después simular que la carga de etapas en vez de hacerla desde un disco o cassette, lo hiciera descomprimiendo esas pantallas en el área de memoria que le correspondía al juego y pasarle el control al juego nuevamente una vez descomprimidas las etapas.

[ZZT]

La misma que hoy cumple el WinZip. Comprimir código para empaquetar. Por ejemplo, el Beach Head cargaba varias pantallas. Una solución fue tomar las pantallas, meterlas en este compresor, guardarlas bajo la rom o en algunas ocaciones también guardamos pantallas bajo los bancos de memoria del 130 XE, para después simular que la carga de etapas en vez de hacerla desde un disco o cassette, lo hiciera descomprimiendo esas pantallas en el área de memoria que le correspondía al juego y pasarle el control al juego nuevamente una vez descomprimidas las etapas.

¿Y que algoritmo ocupaban?

[parche]

Era bastante simple. Buscaba patrones. Por ejemplo, si el código ascii era " " esto se traducía a algo como sp20 o 20 espacios. Recién se estaban publicando en teoría como achicar los archivos demasiado extensos. De tiempo en tiempo aparecía una revista que traía algún artículo sobre algorítmos de compresión. Pero las primeras versiones del dcrunch era solo buscar patrones.

[miltonshows]

y cuanto era el % de comprension peladin?????

[vitoco]

y cuanto era el % de comprension peladin?????

También me estoy quedando pelado, pero no es por eso que respondo...

La tasa de compresión es variable, y depende de lo que quieras comprimir. Si por ejemplo se trata de pantallas de un juego, el algoritmo del crunch es bastante efectivo y podría comprimir más del 50%, pero en un trozo de programa (puro código assembler), lo más probable es que no comprima nada... es más, puede crecer!!! Es en la data gráfica donde vale la pena aplicarlo.

Yo también hice un compresor en mi época basado en el algoritmo crunch para caracteres repetidos, con algunas optimizaciones básicas y encriptación de por medio (para dificultar el re-pirateo), pero nada tan elaborado como reconocer patrones de varios bytes consecutivos o palabras repetidas, ya que eso requiere de memoria para manejar tablas y en el Atari eso es un recurso escaso.

Por si alguien recuerda, había un programa para dibujar y pintar llamado Koala o algo así. Uno podía guardar las imágenes en archivos, pero el formato de ellos era distinto al habitual de los Atari, es decir, no guardaba los bytes secuenciales de la pantalla tal como se almacenan en memoria, sino que lo hacía verticalmente, es decir tomaba el primer byte y después no tomaba el segundo (a su derecha), sino que uno de abajo, pero no el de la segunda línea sino que el de la tercera, luego pasaba a la quinta y así... después retomaba el de la segunda y recorría las líneas pares de esa columna (por byte). Cuando terminaba con la columna, repetía para la siguiente, y así hasta completar todo el mono. ¿Qué lograba con eso? Pues ese programa permitía dibujar contornos y rellenar con patrones, pero como la paleta de colores es reducida, lo normal era usar los pixeles como tablero de ajedrez y lograr mezcla de colores. Por lo tanto, había más probabilidades de encontrar bytes repetidos en líneas saltadas que consecutivas, y si aplicaba a eso un crunch, podía almacenar un dibujo en harto menos de 8K (lo que ocupa un dibujo en GR.15).

++Vitoco

[parche]

Ojo que estamos hablando de los precursores de los compresores. En gráfica también hoy hay compresión. JPG, GIF y otras extensiones que hoy usamos son ni más ni menos que métodos de compresión de imágenes o en el caso particular de los GIF secuencias de imágenes. Por eso que hablan de GIF animados que no es ni más ni menos que una secuencia de imagenes que se reproducen infinitamente como este

Hay harta literatura sobre compresiones. En música por ejemplo mp3 es un compresor de ondas. Sería interezante documentar estos temas.

Aquí hay un buen resúmen por extensión de los formatos de compresión que existen

[vitoco]

Métodos de compresión de imágenes hay muchas, y la mejor a usar depende del tipo de imagen. Para fotos conviene JPG (las distorsiones no se notan), para capturas de pantalla lo mejor es PNG (compresión sin distorsiones). Los GIF soportan animaciones, pero también tienen compresión, pues por lo bajo permite usar una misma paleta para todos los cuadros, y no necesita cuadros completos en una animación, ya que almacena sólo la porción del cuadro que cambia respecto del anterior (por ejemplo, en mi avatar del momento, sólo el cuadradito donde está el logo Atari en modo rainbow está almacenado varias veces, el resto del QR-code permanece estático).

Mi comentario respecto del formato Koala es que usa un vulgar crunch en imágenes, pero ordenando los bytes de una forma en que existe mayor posibilidad de encontrar bytes consecutivos repetidos, lo que implica una mayor compresión.

Aquí hay un buen resúmen por extensión de los formatos de compresión que existen

Esa es una lista de extensiones cualesquiera, no de formatos de compresión. Además no aparece .ATR, XEX, .M65, etc... O sea, no es un buen resumen

[miltonshows]

Gracias por las aclaraciones vitoco