| |
Bitbreaker
Registered: Oct 2002
Posts: 504 |
Doynamite 1.x
Hi Folx,
after doynamite was used in some recent productions and people often stumbled over the .prg/.bin pitfall i decided to make some improvements to the packer, it can now spit out a sfx, level-packed data including a valid load-address and depack-address, as well as forward literals to keep the safety margin low. Raw data can still be loaded and output without any bytes added. Also the optimal bitlengths can be iterated now and the optimal table be glued to the output file.
I also happend to make a leaner version that lets the files get slightly bigger, but shrinks the depacker to $e0 bytes and makes depacking 5-10% faster. This might be of good use for demo systems where size matters a lot.
Any more things one could wish? |
|
... 31 posts hidden. Click here to view all posts....
|
| |
ruk
Registered: Jan 2012
Posts: 43 |
Quote: Hmm.. are you guys saying that byte-boozer decrunching is slow? Perhaps i could do something about it. I assume these values are already using the "optimized" version of the decruncher that has inlined getter of the code-bytes..
Apart from that, i think you guys should spend a minute or two on linking instead. It's quite easy to make 5-10 seconds of black empty screen feel like nothing if you just have something on the screen moving or doing some kind of easy effect.
Yes, what HCL says. "Dead air" is really boring, but easily remedied. And while a fast depacker surely helps, it is not the only way.
We've successfully used the "oh-no-so-dawg-slow" Exomizer for all our parts in Revolved, Solaris and Continuum without any noticeable pauses. In those cases where we couldn't load and unpack while a part was running, some small rasterbar effect or similar filler-part was inserted. |
| |
algorithm
Registered: May 2002
Posts: 705 |
Yes, even if exomizer is a lot slower, usually, it only requires a few extra seconds of 'demo' effect before its done its job. Main use for the faster depacking would probably be if requiring fast load and depack (some type of chunk based streaming) that is compressed finally with a packed that depacks fast |
| |
Bitbreaker
Registered: Oct 2002
Posts: 504 |
It is also useful if you want to achieve a higher pace than offence :-) But one could of course say it is art and intended to be slow :-) |
| |
Urban Space Cowboy
Registered: Nov 2004
Posts: 45 |
Quoting ChristopherJamIs the Pearls for Pigs corpus downloadable anywhere? It's included in LZWVL, the file "bin.rar". |
| |
Oswald
Registered: Apr 2002
Posts: 5086 |
its easy to talk about it, but in reality a fast paced demo needs blood,tears, sweat and a human sacrifice |
| |
WVL
Registered: Mar 2002
Posts: 896 |
Quote: Quoting ChristopherJamIs the Pearls for Pigs corpus downloadable anywhere? It's included in LZWVL, the file "bin.rar".
W00t! I totally forgot that :-D
Those files are nice collection of 'real' data. Some music, some code, some graphics, tables, etc etc :-) |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1408 |
Thank you. And yes, it sounds like a pretty representative dataset for what packers face in practice. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1408 |
..and as for things to do while performing a slow decrunch, loader games anyone? ;) |
| |
WVL
Registered: Mar 2002
Posts: 896 |
So.. how did your packed perform then? :-) |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1408 |
Not quite as good as WVL-S! Here are the results with tinycrunch added:
filesizes
# bin rle wvl-f wvl-s tc bb pu doyna
- ----- ----- ----- ----- ----- ----- ----- -----
1 11008 8020 4529 4151 4329 3383 3410 3265
2 4973 4314 3532 3309 3423 2648 2687 2512
3 3949 3498 2991 2617 2972 2187 2226 2108
4 7016 6456 4242 4085 4225 3681 3595 3617
5 34760 27647 25781 24895 25210 21306 20887 20405
6 31605 12511 11283 10923 11614 9194 8877 8904
7 20392 17295 12108 11285 11445 9627 9460 9289
8 5713 5407 4179 3916 3936 3251 3314 3132
9 8960 7986 6914 6896 6572 5586 5651 5430
filesize in %
# bin rle wvl-f wvl-s tc bb pu doyna
- ----- ----- ----- ----- --- ----- ----- -----
1 100% 73% 41% 38% 39% 31% 31% 30%
2 100% 87% 71% 67% 69% 53% 54% 51%
3 100% 89% 76% 66% 75% 55% 56% 53%
4 100% 92% 60% 58% 60% 52% 51% 52%
5 100% 80% 74% 72% 73% 61% 60% 59%
6 100% 40% 36% 35% 37% 29% 28% 28%
7 100% 85% 59% 55% 56% 47% 46% 46%
8 100% 95% 73% 69% 69% 57% 58% 55%
9 100% 89% 77% 77% 73% 62% 63% 61%
number of frames to depack
# bin rle wvl-f wvl-s tc bb pu doyna
- ----- ----- ----- ----- ----- ----- ----- -----
1 11 13 14 15 58 27
2 5 7 7 9 38 17
3 4 6 6 7 28 12
4 8 9 9 10 43 20
5 36 39 42 59 300 119
6 20 25 25 37 126 49
7 22 25 26 32 138 60
8 6 8 8 10 43 18
9 9 12 12 16 73 32
As you can see, my sizes are always bracketed by WVL-F and WVL-S, and my decompression speed is two thirds of yours for 6.bin.
(crunching the entire corpus took 7 seconds on a single core of a 3GHz i7. It's a fairly slack python script, I put all recent substrings in a dict. The parameters are tuned for the lower entropy components of JamBall2, I might be able to improve the ratio if I play with it a bit). |
| Previous - 1 | 2 | 3 | 4 | 5 - Next |
