The decompression routine is very slow, but it compress better than exomizer. That converts to the perfect compressor for 4K demos. The original code is from here:
http://www.cpcwiki.eu/forum/programming ... h-routine/
Shrinkler, LZ77+arithmetic coding compressor
-
- Drutt
- Posts: 17
- Joined: Sat Dec 09, 2017 9:07 pm
Re: Shrinkler, LZ77+arithmetic coding compressor
Wow, that's very, very awesome news. Massive props to roudoudou for pulling this off, and thanks to you and Hicks for optimizing the decruncher.
Now what's next, a z80 decruncher for brotli? paq8?
Now what's next, a z80 decruncher for brotli? paq8?
Re: Shrinkler, LZ77+arithmetic coding compressor
This looks interesting, although being slower for decompress might be a concern for use in games.
Re: Shrinkler, LZ77+arithmetic coding compressor
There are undoubtedly various use cases where this compression speed would be acceptable. What I'm more concerned about is the need to reserve a large buffer. A situation like this is not a problem for 4K intros, but it could be an issue if you've stuffed all the available RAM.
Nevertheless, I think this is a very exiting achievement
[mention]antoniovillena[/mention] Is it by any means possible to overwrite the packed data and/or the buffer during decrunching?
Nevertheless, I think this is a very exiting achievement
[mention]antoniovillena[/mention] Is it by any means possible to overwrite the packed data and/or the buffer during decrunching?
Re: Shrinkler, LZ77+arithmetic coding compressor
Since the content enlarges on decompression, it must work in reverse, so that the buffer is filled from the end to start, so that it can coexist with the compressed buffer, that should also be processed from front to back, so that enough area is released at the end of the decoding.
But from what I read, you need at least an external table, that can't be included in this buffer.