| |
Bitbreaker
Registered: Oct 2002
Posts: 508 |
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....
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
just remove the zeros! |
| |
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: 508 |
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: 5094 |
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: 902 |
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: 1409 |
Thank you. And yes, it sounds like a pretty representative dataset for what packers face in practice. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
..and as for things to do while performing a slow decrunch, loader games anyone? ;) |
| |
WVL
Registered: Mar 2002
Posts: 902 |
So.. how did your packed perform then? :-) |
| Previous - 1 | 2 | 3 | 4 | 5 - Next |
