|
Shrinkler by Loonies [web]
[nfo]
|
||||||||
|---|---|---|---|---|---|---|---|---|
|
|
|||||||
|
popularity : 69% |
|||||||
alltime top: #1383 |
|
|||||||
|
||||||||
added on the 2015-01-05 23:45:06 by Blueberry  |
||||||||
popularity helper
comments
woop woop :D
yeah
thumb up!
Thx for all the hard work and sharing it. I will surely try/use it with my future OCS prods. I hope it will replace the legendary Titanics Cruncher (depacking while loading rulez on OCS :). HNY 2k15!
A great improvement over execruncher2.
This is the best cruncher by far. Always lose enough kilobytes away.
It has lots of options to scratch a little bit more.
Thank you very much, Blueberry, for this amazing tool.
This is the best cruncher by far. Always lose enough kilobytes away.
It has lots of options to scratch a little bit more.
Thank you very much, Blueberry, for this amazing tool.
Excellent, thanks for awesome tools! :)
Moar Amiga intros!
Super tool indeed! The crunching time IS long, but it sure is worth the wait. I crunch via my Amiga Forever setup on my laptop and for "How to skin a dwarf" it took 45 minutes. Not sure how long that would have taken on realHW....LONG!....but then you can just have a beer or two during the crunchingtime (quote: Bstrr)!
.
Dunno if i personally have use for it but thumbs up!
This is da shit! Start coding now, guys. The last excuse to not make an Amiga 4K intro is gone...
Compression ratio is compared to other crunchers phenomenal. Will use it for future OCS prods. Great work!
OMG you RULEZ! \:D/
thx for sharing.
Awesome! Important question: does it support a custom decrunching message?
Quote:
Important question: does it support a custom decrunching message?
It does. You can give it either as an argument or in a text file.
Quote:
depacking while loading rulez on OCS :)
Shrinkler does not decrunch while loading, but the loading time is typically quite short compared to the decrunch time anyway. For example, when running a 64k intro from floppy on 68000, it will likely load for 3-4 seconds, then print the decrunch text, and then decrunch for 20-25 seconds.
Also, if you use the overlap option, the memory overhead will be very small, typically less than 1k, similarly to what you get with decrunching-while-loading packers.
\:D\ Blueberry codes awesome stuff while packing and depacking while you crunch while decrunching!
Awesome stuff! Finally something that can reasonably surpass Titanics :)
gr8 m8 i r8 8/8 (sorry ;p )
tool thumbs!
wow!
yes, this is so great!
Thumb beacuse Blueberry is cool.
So now we are waiting for some cool Amiga Demomaker developed by Blueberry :)
no c=64 version? :)
/me bows for Blueberry
/me bows for Blueberry
Who would have thought 25 years ago that this kind of stuff would be released in 2015? Amazing.
nice :)
i wonder if this could be adopted for other 68k platforms like atari?
i wonder if this could be adopted for other 68k platforms like atari?
Totally awesome. I'm currently testing how much smaller http://www.pouet.net/prod.php?which=57630 could be if it used Shrinkler rather than Exomizer2.
Quote:
i wonder if this could be adopted for other 68k platforms like atari?
I have looked a bit into the possibility of Atari support, and run some comparisons to PackFire, which seems to be the state of the art in that space. Shrinkler beats it comfortably for small files, but PackFire has the edge for larger files, due to its LZMA-derived "large" depacker. This is definitely something I will look more into.
Any other 68k platforms apart from Atari that could be relevant?
awesome work blueberry
Amazing!
Quite the opposite of my Nibbler, which was made for extremely fast decrunch speeds. Knowing you I also think Shrinkler will excel at smashing down 4Ks and 64Ks compared to any other cruncher! And Titanics-cruncher is still with us as crap-ratio, medium-slow, small overhead quickie execruncher to get partyprods out in a pinch. A choice for every situation :)
pre-test-thumb!
Great to have Shrinkler around!
@Photon: Regarding an allround exe-cruncher you could check Cru, which was far better than Titanics!
@Photon: Regarding an allround exe-cruncher you could check Cru, which was far better than Titanics!
Looks very interesting, I am big fan of upx on Atari ST for prg files and any file by adding fake prg headers, it is very fast to depack, has a good compress ratio and can compress from many plateform also.
Could be an interesting challenger :-)
Also I help the compressor by trying several way to organise the data with interesting % reduction: zigzag path for pics, splitted red,green,blue for numerous palettes as in hicolor, low/high bytes splitted&grouped together, etc.
Could be an interesting challenger :-)
Also I help the compressor by trying several way to organise the data with interesting % reduction: zigzag path for pics, splitted red,green,blue for numerous palettes as in hicolor, low/high bytes splitted&grouped together, etc.
Heja Aske!
Well shit! Where do I get an high end amiga now? :)
And with that crunchmania was dropped from my workflow. :)
las: You emulate it.
las: You emulate it.
outta sight, again :D
thanks for that great share! What about the depacking speed compare with packfire "lzma"? You have only one MUL per "getbit", packfire implementation has two.
I'll use it in my ATARI demo system to depack my kernel loader (your depacker is less than 200 bytes, I love that :))
I'll use it in my ATARI demo system to depack my kernel loader (your depacker is less than 200 bytes, I love that :))
There is one mul instead of two, yes, and there are also a lot of other things going on in the PackFire depacker. But the only way to know for sure it to try it. :)
I ran a comparison against PackFire to test the decrunch speed of a raw binary file on 68000.
Original: 265660 bytes (Spitz by Focus Design).
Shrinkler: 56056 bytes, 23 seconds.
PackFire: 53944 bytes, 47 seconds.
So yes, it appears Shrinkler decrunches about twice as fast as PackFire's "large" depacker. PackFire's "tiny" depacker is unquestionably much faster than Shrinkler (but this file is too big for it).
I ran a comparison against PackFire to test the decrunch speed of a raw binary file on 68000.
Original: 265660 bytes (Spitz by Focus Design).
Shrinkler: 56056 bytes, 23 seconds.
PackFire: 53944 bytes, 47 seconds.
So yes, it appears Shrinkler decrunches about twice as fast as PackFire's "large" depacker. PackFire's "tiny" depacker is unquestionably much faster than Shrinkler (but this file is too big for it).
And for those of you not reading ADA: There is a new version out (4.4) which is much, much faster (and a bit better at default settings) than 4.3. It should also use somewhat less memory.
The new version also supports raw data crunching and comes with ready-to-use decompression source code.
The new version also supports raw data crunching and comes with ready-to-use decompression source code.
Amazing. Hope i'll find use for it sometime.
Would it be possible to add a less aggressive mode that wouldn't necessarily compress quite as well but work faster on 68000? So it could be used even for small demos for example.
Would it be possible to add a less aggressive mode that wouldn't necessarily compress quite as well but work faster on 68000? So it could be used even for small demos for example.
Hi blueberry: when you say the new v4.4 is "much, much faster", do you mean the compressor, or the decompressor? ( or maybe both? )
The compressor is faster; the decompressor is the same.
It is not possible to make the decompressor significantly faster without completely changing the format, unfortunately. Basically, the compression format is designed for very good compression ratio and very small decompression code, at the expense of decompression speed. Other crunchers have other tradeoffs.
It is not possible to make the decompressor significantly faster without completely changing the format, unfortunately. Basically, the compression format is designed for very good compression ratio and very small decompression code, at the expense of decompression speed. Other crunchers have other tradeoffs.
For releasing a new Amiga intro cruncher in 2015.
For supporting good old 68k amiga :)
For ruling on Amiga!
A great packer, thanks so much
This packer clearly doesn't have enough thumbs. So here, have one more.
Just tried this out. Works like a charm and is really easy
Happy New Year! :-D
Shrinkler 4.5 has now been released! It contains various fixes and enhancements, based on discussions and suggestions here and in other places:
The decrunch header code no longer depends on A3 pointing to the loaded segment list. This makes shrinkled programs able to launch from a Workbench icon (provided the program correctly handles the Workbench message). It also makes it more straightforward to launch shrinkled programs from a custom loader.
For those who prefer not to delve into arcane compression options, there are now a set of numeric options to select an overall compression level, ranging from -1 (fastest) to -9 (slowest). These set all of the compression options to values proportional to the level. Since these options also set the number of iterations, the compression time is approximately quadratic in the compression level. The default compression level is -2.
Each of the compression options can be set in addition to the level, overriding the preset values. In particular, it can be useful to reduce the number of iterations to save some time on the highest levels.
The new --no-crunch option skips crunching and does only hunk processing, including hunk merging if enabled. Thanks to Todi for suggesting the feature.
Completely empty hunks would cause Shrinkler to report a verify error during crunching. These are now padded to 4 bytes.
When crunching a data file, Shrinkler now prints the minimum safety margin to use if the decompressed data overlaps the compressed data when decompressing. If the value is zero or negative, no margin is needed, which means that the compressed data can simply be placed at the end of the decompressed data. If the value is positive, the end of the compressed data must extend at least this many bytes beyond the end of the decompressed data. Note that even though the value may be odd, the compressed data must always be placed on an even address if it is to be decompressed on less than a 68020.
Shrinkler 4.5 has now been released! It contains various fixes and enhancements, based on discussions and suggestions here and in other places:
The decrunch header code no longer depends on A3 pointing to the loaded segment list. This makes shrinkled programs able to launch from a Workbench icon (provided the program correctly handles the Workbench message). It also makes it more straightforward to launch shrinkled programs from a custom loader.
For those who prefer not to delve into arcane compression options, there are now a set of numeric options to select an overall compression level, ranging from -1 (fastest) to -9 (slowest). These set all of the compression options to values proportional to the level. Since these options also set the number of iterations, the compression time is approximately quadratic in the compression level. The default compression level is -2.
Each of the compression options can be set in addition to the level, overriding the preset values. In particular, it can be useful to reduce the number of iterations to save some time on the highest levels.
The new --no-crunch option skips crunching and does only hunk processing, including hunk merging if enabled. Thanks to Todi for suggesting the feature.
Completely empty hunks would cause Shrinkler to report a verify error during crunching. These are now padded to 4 bytes.
When crunching a data file, Shrinkler now prints the minimum safety margin to use if the decompressed data overlaps the compressed data when decompressing. If the value is zero or negative, no margin is needed, which means that the compressed data can simply be placed at the end of the decompressed data. If the value is positive, the end of the compressed data must extend at least this many bytes beyond the end of the decompressed data. Note that even though the value may be odd, the compressed data must always be placed on an even address if it is to be decompressed on less than a 68020.
Superb. Thanks for your efforts.
Amazing.
And can be used on Amstrad CPC now =)
And can be used on Amstrad CPC now =)
It is already used in a more Serious! 8 bit production by Moods Plateau, shown at this year's Revision. ;)))
Thanx a lot for this! It saved my ass by crunching the final version of the soundtrack so heavily that the entire demo did fit into the available memory again. :o)
Thanx a lot for this! It saved my ass by crunching the final version of the soundtrack so heavily that the entire demo did fit into the available memory again. :o)
simply fantastic for 4k intros on 8 bit computers!
Unsurpassed for pack ratio AND convenience.
thanx aloads mate, it crunches and worx like a charm
Shrinkler 4.6 is released!
The features and fixes in this release are mainly relevant for people working with large files. This is what is new:
- The suffix array construction, which runs in the slight pause before each hunk is compressed, has been reimplemented using the very fast SA-IS algorithm, which means that these pauses are now almost gone.
- Shrinkler would give a verify error if a data file, or a single hunk, compressed to more than about 2MB (1953125 bytes to be exact - try to guess where that number comes from). This is now fixed. Thanks to Phibrizzo for reporting the bug.
- Increased max number of reference edges (-r option) to 100000000, which can come in handy when compressing very large files.
- The HUNK_RELOC32SHORT and HUNK_DREL32 relocation hunks are now supported. Thus, Shrinkler can be used together with tools which emit such hunks. Thanks to Todi for suggesting the feature.
The features and fixes in this release are mainly relevant for people working with large files. This is what is new:
- The suffix array construction, which runs in the slight pause before each hunk is compressed, has been reimplemented using the very fast SA-IS algorithm, which means that these pauses are now almost gone.
- Shrinkler would give a verify error if a data file, or a single hunk, compressed to more than about 2MB (1953125 bytes to be exact - try to guess where that number comes from). This is now fixed. Thanks to Phibrizzo for reporting the bug.
- Increased max number of reference edges (-r option) to 100000000, which can come in handy when compressing very large files.
- The HUNK_RELOC32SHORT and HUNK_DREL32 relocation hunks are now supported. Thus, Shrinkler can be used together with tools which emit such hunks. Thanks to Todi for suggesting the feature.
Congrats for the tool and new release, it is supper effective.
One issue I think I am having is that my exe after compression is not accepting command parameters, I don't know if I am doing something wrong
One issue I think I am having is that my exe after compression is not accepting command parameters, I don't know if I am doing something wrong
It seems it happened only when using the overlap option, great tool!
What!! I've not given this a thumb!! Guess I'll be taking this for another drive soon 😉
Zener: Indeed the parameter handling in the overlap header is broken. I carefully avoided using A0 and D0 in the decrunch code and made sure to save them when text printing is used, but I overlooked the cache flushing, which may also mess up these registers.
The normal header always saves the registers, as it needs to do a memory deallocation at the end. So for that one it always works.
It could actually be nice to have commandline support as an option to Shrinkler, since the need for such support is probably relatively independent of the appropriate choice of header (normal, overlap or mini). It would blow up the number of different header combinations required, but this this is mainly a build management issue.
The normal header always saves the registers, as it needs to do a memory deallocation at the end. So for that one it always works.
It could actually be nice to have commandline support as an option to Shrinkler, since the need for such support is probably relatively independent of the appropriate choice of header (normal, overlap or mini). It would blow up the number of different header combinations required, but this this is mainly a build management issue.
Code:
but I overlooked the cache flushing, which may also mess up these registers.CacheClearU() definitely trashes d0/a0 (and d1 too). :)
Unpacked thumb up!!
Among other things, it allows you to create intros 64k in Amos :
the "Yes!" intro is an Amos exe of more then 130kb that has been compressed to 60kb by this awesome tool. Wow !
Thanks Blueberry.
the "Yes!" intro is an Amos exe of more then 130kb that has been compressed to 60kb by this awesome tool. Wow !
Thanks Blueberry.
There's a bug in your depacking routine: you forgot to initialize d5.
D5 contains the current reference offset. It is written at all non-repeated-offset references and used as the copy offset at all references (repeated offset and not).
The only way you can get to the code using D5 without it being initialized first is if the input contains a repeated-offset reference before the first non-repeated-offset reference. But Shrinkler should never emit such data. If you encounter this situation, your crunched data is corrupt.
Did you hit the D5-using code with D5 uninitialized with data coming directly from Shrinkler? If so, I would like to hear more. :)
The only way you can get to the code using D5 without it being initialized first is if the input contains a repeated-offset reference before the first non-repeated-offset reference. But Shrinkler should never emit such data. If you encounter this situation, your crunched data is corrupt.
Did you hit the D5-using code with D5 uninitialized with data coming directly from Shrinkler? If so, I would like to hear more. :)
Superb!
it's the most efficient compressor so far :-) I converted the decompression routine to 6502, it works great! Thanks.
https://www.youtube.com/watch?v=uA0wZtktWv8
https://www.youtube.com/watch?v=uA0wZtktWv8
Exactly two years after the last release (because it's such a nice date today): Shrinkler 4.7!
Various new features and improvements this time:
- The Amiga Shrinkler executable is now built using Amiga-GCC. This makes it compress about 15% faster, and it longer needs ixemul.library.
- A new option (--commandline, -c) to support commandline parameters. This was always supposed to work, but only actually worked with the default header. It now works with all headers when you specify the option, and the header is a few bytes smaller if you don't.
- A new option (--bytes, -b) to disable the parity context for data compression. This usually gives better results for data that is not word-oriented. The 6502 decruncher already supports this format and points to a special Shrinkler build for this. Now you can use the standard Shrinkler.
- The output size for data crunching is no longer rounded up to a multiple of 4 bytes, as the decompressor now reads the data one byte at a time. This also means that the data no longer has to be word-aligned on 68000.
- A new option (--header, -w) to write a header before the crunched data. This header contains imformation about compressed and uncompressed size, safety margin and whether parity context were enabled for the compression. To accompany this, the decompressor source code is extended with some utility code to load a Shrinkler-compressed file from disk, automatically allocating the right amount of memory for overlapped decompression.
Finally, the default compression preset was upped from -2 to -3, since this is usually a more suitable sweet spot between size and speed, and it's the maximum number of iterations that can be printed in an Amiga console with a width of 77 characters. :)
Various new features and improvements this time:
- The Amiga Shrinkler executable is now built using Amiga-GCC. This makes it compress about 15% faster, and it longer needs ixemul.library.
- A new option (--commandline, -c) to support commandline parameters. This was always supposed to work, but only actually worked with the default header. It now works with all headers when you specify the option, and the header is a few bytes smaller if you don't.
- A new option (--bytes, -b) to disable the parity context for data compression. This usually gives better results for data that is not word-oriented. The 6502 decruncher already supports this format and points to a special Shrinkler build for this. Now you can use the standard Shrinkler.
- The output size for data crunching is no longer rounded up to a multiple of 4 bytes, as the decompressor now reads the data one byte at a time. This also means that the data no longer has to be word-aligned on 68000.
- A new option (--header, -w) to write a header before the crunched data. This header contains imformation about compressed and uncompressed size, safety margin and whether parity context were enabled for the compression. To accompany this, the decompressor source code is extended with some utility code to load a Shrinkler-compressed file from disk, automatically allocating the right amount of memory for overlapped decompression.
Finally, the default compression preset was upped from -2 to -3, since this is usually a more suitable sweet spot between size and speed, and it's the maximum number of iterations that can be printed in an Amiga console with a width of 77 characters. :)
Quote:
Exactly two years after the last release (because it's such a nice date today): Shrinkler 4.7!
Thank you, Blueberry!
Thanks for the tool (and for open-sourcing it) !
submit changes
if this prod is a fake, some info is false or the download link is broken,
do not post about it in the comments, it will get lost.
instead, click here !
About the platforms: The singular platform field available for Pouet prods falls short when it comes to cross-development demo tools that (can) have separate host and target platforms. Shrinkler reads and writes executables for all Amigas and runs on Windows, Linux, MacOSX Intel and high-end Amigas.
It was developed primarily with cross-development in mind, and the current version is quite time and memory hungry. Hopefully this fits how people would like to use it. Let me know what you think.
But most importantly: Enjoy, and make some kick-ass Amiga intros! :-D