| |
ChristopherJam
Registered: Aug 2004
Posts: 1381 |
On the relative pros and cons of various RLE schemes
So over in Native crunch/decrunch code. I just suggested encoding
abbcdddeffffg as
abb{0}cdd{1}eff{2}g
Raistlin kindly liked the idea, Krill quite sensibly didn't want us to hijack the post and suggested a new post for the new topic. so... Have at it! |
|
... 26 posts hidden. Click here to view all posts....
|
| |
tlr
Registered: Sep 2003
Posts: 1724 |
Quoting RaistlinIsn’t it more common to use a bit to define “constant or not”?
$00-7F .. count of non-repeats ($01-$80)
$80-FF .. count of repeats ($04-$83) Do you have any other examples of packers implementing this? I haven't seen that many.
I think the reason it's uncommon (on the C64) because it doesn't pack as well, and size was probably the main driver for the development of packers/crunchers. Decompression speed came much later. |
| |
Krill
Registered: Apr 2002
Posts: 2854 |
Quoting tlrI think the reason it's uncommon (on the C64) because it doesn't pack as well, and size was probably the main driver for the development of packers/crunchers. Decompression speed came much later. I think it's uncommon because everybody just copied everybody else's approach. :)
RLE used to be LZ-crunched anyways, so RLE compression ratio wasn't much of a concern.
How are you so sure this approach (generally?) packs worse than the escape-byte approach? |
| |
tlr
Registered: Sep 2003
Posts: 1724 |
Quoting KrillRLE used to be LZ-crunched anyways, so RLE compression ratio wasn't much of a concern. Initially RLE seemed to have been used by itself.
Quoting KrillHow are you so sure this approach (generally?) packs worse than the escape-byte approach? I'm thinking because only 128-ish runs are allowed + only 128-ish literal blocks. For a typical C64 program (demo?) there would be longish runs of empty space, interweaved with longish runs of code and data.
But maybe I'm assuming too much? Would be interesting to seem some practical measurements. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11146 |
Quote:For a typical C64 program (demo?) there would be longish runs of empty space, interweaved with longish runs of code and data.
Thats why people used "linkers" before packing :) But even if not so, the difference shouldn't be more than a couple bytes on a typical program - and those bytes would form a nice sequence that can be crunched later. |
| |
Fungus
Registered: Sep 2002
Posts: 629 |
Probably the most interesting Super-Zipper V8 |
| |
WVL
Registered: Mar 2002
Posts: 886 |
Quote: Quoting RaistlinIsn’t it more common to use a bit to define “constant or not”?
$00-7F .. count of non-repeats ($01-$80)
$80-FF .. count of repeats ($04-$83) Do you have any other examples of packers implementing this? I haven't seen that many.
I think the reason it's uncommon (on the C64) because it doesn't pack as well, and size was probably the main driver for the development of packers/crunchers. Decompression speed came much later.
Here is an example : https://csdb.dk/release/?id=34685. |
| |
JackAsser
Registered: Jun 2002
Posts: 1990 |
Quote: Quoting JackAsserLike Dinosours? Dinasours? Which magical infinite cruncher are you referring to? =)
Check any Dinosours release and you'll get the point. :D |
| |
Bitbreaker
Registered: Oct 2002
Posts: 501 |
Quoting Krill
RLE used to be LZ-crunched anyways, so RLE compression ratio wasn't much of a concern.
What is kind of hard to understand, as LZ includes RLE by design (match with offset 1) |
| |
Krill
Registered: Apr 2002
Posts: 2854 |
Quoting JackAsserCheck any Dinosours release and you'll get the point. :D I was aware that Dinasours pack everything 10 times for comedic effect,
but i thought maybe they've released the Airwolf Fixer of crunchers or something and i've missed that. :) |
| |
Krill
Registered: Apr 2002
Posts: 2854 |
Quoting BitbreakerQuoting Krill
RLE used to be LZ-crunched anyways, so RLE compression ratio wasn't much of a concern.
What is kind of hard to understand, as LZ includes RLE by design (match with offset 1) Native LZ crunchers used to require quite a bit of working memory, so the maximum size of input programs was often smaller than entirely uncompressed programs.
Thus RLE first, then LZ. Also this two-pass approach can make for better overall compression ratio. |
| Previous - 1 | 2 | 3 | 4 | 5 - Next |
