| |
ChristopherJam
Registered: Aug 2004
Posts: 1378 |
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....
|
| |
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: 1989 |
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: 500 |
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: 2845 |
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: 2845 |
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. |
| |
Jetboy
Registered: Jul 2006
Posts: 214 |
Quoting KrillThus RLE first, then LZ. Also this two-pass approach can make for better overall compression ratio.
Puls LZ ones were rather slow, so prepacking with RLE first could save substantial amounts of time. As shorter file to pack tends to pack quicker. |
| |
enthusi
Registered: May 2004
Posts: 675 |
Just to add an alternative which is a bit special but cute:
Maniac Mansion and ZMK use some RLE depacker that resides in ZP and encodes most-common bytes, which I felt works rather well for graphics. I wrote something about that here:
https://www.pagetable.com/?p=603
A byte of < $40 = count of raw bytes following
$3f to < $80 represents the length of the run of the byte to follow (+$3f of course).
$7f to < $a0 is the number of runs of most common byte 1,
$9f to < $c0 and $bf to <$e0 and $df-$ff for common byte 2, 3 and 4 respectively. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1378 |
ooh, I like that one enthusi.
Really interesting the historical divide between packers and crunchers, especially the way intros tended to be displayed between one and the other. It does indeed reduce the impact on runlength limits considerably. Not sure why I ever bothered trying to improve the ratio of my higher ratio crunchers for empty spaces now :P |
| |
Martin Piper
Registered: Nov 2007
Posts: 634 |
In the old days, dictionary based compression would be quite slow and memory hungry. The usual way of speeding it up would be to limit the distance searched and limit the dictionary.
Using a RLE compression pass before a dictionary compression stage would reduce the total input data, it would reduce the strain on the dictionary, and would pass some benefit along to the dictionary based compression.
As dictionary algorithms improve, and also as time and memory becomes less of an issue, the dictionary size can be increased and this means there is less benefit to shrinking the input data with a RLE pre-pass. |
| |
Fungus
Registered: Sep 2002
Posts: 618 |
Main reason for packing first was before crunchers had REU versions with 2mhz or 8mhz support they were slow as hell and took many hours. So smaller input files crunched way faster. Also crunching large files tended to bug out. They generally were smaller too, so it became the norm. |
| Previous - 1 | 2 | 3 | 4 - Next |
