Pletter (or other compression tools) performance

Página 2/3
1 | | 3

Por albs_br

Champion (473)

Imagen del albs_br

17-01-2023, 15:55

Also, on my tests, only standard decompressor is working, the other three aren't.

Check code here: https://github.com/albs-br/msx-tests/blob/master/zx0_compres...

Am I doing something wrong?

Por Arjan

Paladin (787)

Imagen del Arjan

17-01-2023, 16:26

albs_br wrote:

What's the command to compress the first 256 bytes (0-255), and the commando to the next 256 bytes (256-511) and so on? The docs aren't clear about this.

There is no way to specify how many bytes should be compressed, only how many bytes to use as a prefix.

albs_br wrote:

Also, on my tests, only standard decompressor is working, the other three aren't.

Check code here: https://github.com/albs-br/msx-tests/blob/master/zx0_compres...

Am I doing something wrong?

The non-standard decompressors use selfmodifying code.

Por santiontanon

Paragon (1805)

Imagen del santiontanon

17-01-2023, 16:52

why do we want to compress each chunk separately? Can't the decompression routine not just be run until it decompresses X bytes, and then stop (saving the state to some memory location), to then resume it later to decompress another chunk?

Por albs_br

Champion (473)

Imagen del albs_br

17-01-2023, 17:51

Arjan wrote:

There is no way to specify how many bytes should be compressed, only how many bytes to use as a prefix.

That's sad, as my need is to read and spit 256 bytes to VRAM. Background image for just one level of msx-wings is taking 256kb, compressed it will be under 80kb, but I need to decompress in steps of 256 bytes, one at each 3 frames. I have some spare cpu left. No way to decompress all before level starts as it would need lots of RAM. Target is standard 64kb of RAM.

That's not a very unusual need. Many people should have had this need before. Or am I the first?

Por GhostwriterP

Paladin (683)

Imagen del GhostwriterP

17-01-2023, 18:19

I suppose you need to write your own decompressor then. One that uses a circular lookback buffer of certain size (maybe 1, 2 or 4 kb whatever you can spare or give decent results) and use the compressor with a maximum/fixed lookback offset setting.

Por albs_br

Champion (473)

Imagen del albs_br

18-01-2023, 18:51

Does that mean that from the dozens of packars available (for example, one list: https://github.com/uniabis/z80depacker), none of them are able to do partial depackings as I need?

Por Arjan

Paladin (787)

Imagen del Arjan

18-01-2023, 23:43

As far as I know none of them have built-in support for partial depacking, but it's possible to adapt the code to implement such a feature.

Por acet

Supporter (12)

Imagen del acet

19-01-2023, 00:20

lz4stream and lzsa2stream for Z80 with 256bytes buffer
http://mydocuments.g2.xrea.com/html/p6/randd.html

Por Uninteresting

Champion (352)

Imagen del Uninteresting

19-01-2023, 07:26

Step and Jäästä used a custom static Huffman decoder to unpack each string shown on the screen separately (so even single words). The encoder is implemented in Python. However:
- this uses a fixed decompression tree, which takes a lot of space in case of several compressed different bytes. This structure should be included in the source code (maybe 2KB of data at most?).
- it allows compressing at most 254 different values (no escape characters)
- not all cases can be compressed with this, because I use only one byte to signify jumps in the code tree.

FWIW, the source codes are at github; the compressor in /python and decompressor is /src/main.asm:Decompress

Por thegeps

Paragon (1187)

Imagen del thegeps

19-01-2023, 08:15

Levels are tile-based or bitmap-based?

Página 2/3
1 | | 3