Shrinkler by Loonies [web]
screenshot added by Blueberry on 2015-01-05 23:45:06
platform :
type :
release date : january 2014
  • 56
  • 3
  • 0
popularity : 67%
  • 0.95
alltime top: #1374
added on the 2015-01-05 23:45:06 by Blueberry Blueberry

popularity helper

increase the popularity of this prod by spreading this URL:

or via: facebook twitter pinterest tumblr


One year ago today, I announced a brand new, open source version of my Amiga cruncher on ADA. Today it is ready for Pouet.

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
added on the 2015-01-05 23:45:59 by Blueberry Blueberry
woop woop :D
rulez added on the 2015-01-06 00:00:29 by ferris ferris
rulez added on the 2015-01-06 00:14:56 by wullon wullon
thumb up!
rulez added on the 2015-01-06 00:36:00 by bonefish bonefish
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!
rulez added on the 2015-01-06 00:40:12 by sachy sachy
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.
rulez added on the 2015-01-06 00:46:57 by ham ham
Excellent, thanks for awesome tools! :)
rulez added on the 2015-01-06 06:49:31 by StingRay StingRay
Moar Amiga intros!
rulez added on the 2015-01-06 07:50:16 by Saga Musix Saga Musix
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)!
rulez added on the 2015-01-06 07:59:45 by Corial Corial
rulez added on the 2015-01-06 08:03:06 by SiR SiR
Dunno if i personally have use for it but thumbs up!
rulez added on the 2015-01-06 09:01:53 by Serpent Serpent
This is da shit! Start coding now, guys. The last excuse to not make an Amiga 4K intro is gone...
rulez added on the 2015-01-06 09:17:46 by axis^oxy axis^oxy
Compression ratio is compared to other crunchers phenomenal. Will use it for future OCS prods. Great work!
rulez added on the 2015-01-06 09:30:42 by neoman neoman
OMG you RULEZ! \:D/
rulez added on the 2015-01-06 13:58:02 by rez rez
thx for sharing.
rulez added on the 2015-01-06 14:16:36 by FOSTER FOSTER
Awesome! Important question: does it support a custom decrunching message?
rulez added on the 2015-01-06 14:24:27 by visy visy
Important question: does it support a custom decrunching message?

It does. You can give it either as an argument or in a text file.

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.
added on the 2015-01-06 14:36:12 by Blueberry Blueberry
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.
added on the 2015-01-06 14:41:00 by Blueberry Blueberry
\:D\ Blueberry codes awesome stuff while packing and depacking while you crunch while decrunching!
rulez added on the 2015-01-06 16:22:11 by ccr ccr
Awesome stuff! Finally something that can reasonably surpass Titanics :)
added on the 2015-01-06 19:00:41 by visy visy
gr8 m8 i r8 8/8 (sorry ;p )
rulez added on the 2015-01-06 19:16:04 by Intrinsic Intrinsic
tool thumbs!
rulez added on the 2015-01-06 19:25:05 by sensenstahl sensenstahl
rulez added on the 2015-01-06 21:10:51 by gentleman gentleman
yes, this is so great!
rulez added on the 2015-01-06 21:27:51 by britelite britelite
Thumb beacuse Blueberry is cool.
rulez added on the 2015-01-06 22:08:18 by Emod Emod
So now we are waiting for some cool Amiga Demomaker developed by Blueberry :)
rulez added on the 2015-01-06 22:16:03 by slayer slayer
no c=64 version? :)

/me bows for Blueberry
rulez added on the 2015-01-06 22:50:01 by magic magic
Who would have thought 25 years ago that this kind of stuff would be released in 2015? Amazing.
rulez added on the 2015-01-06 23:49:42 by keops keops
nice :)
i wonder if this could be adopted for other 68k platforms like atari?
rulez added on the 2015-01-07 00:16:29 by wysiwtf wysiwtf
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.
rulez added on the 2015-01-07 10:13:34 by Moerder Moerder
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?
added on the 2015-01-07 17:20:12 by Blueberry Blueberry
awesome work blueberry
rulez added on the 2015-01-08 11:54:06 by psenough psenough
rulez added on the 2015-01-08 22:23:06 by xeron xeron
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 :)
rulez added on the 2015-01-09 00:34:17 by Photon Photon
rulez added on the 2015-01-09 12:42:49 by rloaderro rloaderro
Great to have Shrinkler around!

@Photon: Regarding an allround exe-cruncher you could check Cru, which was far better than Titanics!
rulez added on the 2015-01-09 13:01:30 by noname noname
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.
rulez added on the 2015-01-09 22:07:07 by Cyg_BLaBla Cyg_BLaBla
Heja Aske!
rulez added on the 2015-01-09 22:10:38 by farfar farfar
Well shit! Where do I get an high end amiga now? :)
rulez added on the 2015-01-18 16:18:05 by las las
And with that crunchmania was dropped from my workflow. :)

las: You emulate it.
rulez added on the 2015-01-18 16:33:15 by Korvkiosken Korvkiosken
outta sight, again :D
rulez added on the 2015-01-20 13:33:54 by d0DgE d0DgE
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 :))
rulez added on the 2015-01-21 18:39:11 by leonard leonard
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).
added on the 2015-02-03 17:44:26 by Blueberry Blueberry
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.
added on the 2015-02-04 10:42:52 by Blueberry Blueberry
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.
rulez added on the 2015-02-04 10:50:43 by dodke dodke
Hi blueberry: when you say the new v4.4 is "much, much faster", do you mean the compressor, or the decompressor? ( or maybe both? )
added on the 2015-02-04 11:44:51 by leonard leonard
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.
added on the 2015-02-04 16:37:11 by Blueberry Blueberry
For releasing a new Amiga intro cruncher in 2015.
rulez added on the 2015-02-04 22:30:22 by raer raer
For supporting good old 68k amiga :)
rulez added on the 2015-02-05 14:48:39 by lvd lvd
For ruling on Amiga!
rulez added on the 2015-03-26 19:50:06 by Frequent Frequent
A great packer, thanks so much
rulez added on the 2015-09-10 00:25:10 by Fell Fell
This packer clearly doesn't have enough thumbs. So here, have one more.
rulez added on the 2017-05-02 14:54:43 by Charlie Charlie
Just tried this out. Works like a charm and is really easy
rulez added on the 2017-08-02 21:33:16 by Emufr3ak Emufr3ak
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.
added on the 2018-01-03 22:55:39 by Blueberry Blueberry
Superb. Thanks for your efforts.
rulez added on the 2018-01-04 20:30:36 by Skynet Skynet
And can be used on Amstrad CPC now =)
rulez added on the 2018-04-21 14:48:56 by Hicks Hicks
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)
rulez added on the 2018-05-26 22:22:14 by dOc.K dOc.K
simply fantastic for 4k intros on 8 bit computers!
rulez added on the 2018-09-05 01:01:43 by siko siko
Unsurpassed for pack ratio AND convenience.
rulez added on the 2019-12-02 11:29:40 by Nosferatu Nosferatu
thanx aloads mate, it crunches and worx like a charm
rulez added on the 2020-01-06 18:42:11 by chlumpie chlumpie
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.
added on the 2020-02-22 11:16:34 by Blueberry Blueberry
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
added on the 2020-02-26 20:43:55 by Zener Zener
It seems it happened only when using the overlap option, great tool!
rulez added on the 2020-02-26 21:01:00 by Zener Zener
What!! I've not given this a thumb!! Guess I'll be taking this for another drive soon 😉
rulez added on the 2020-02-26 22:10:16 by djh0ffman djh0ffman
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.
added on the 2020-03-02 21:09:31 by Blueberry Blueberry
Code:but I overlooked the cache flushing, which may also mess up these registers.

CacheClearU() definitely trashes d0/a0 (and d1 too). :)
added on the 2020-03-03 12:36:36 by StingRay StingRay
Unpacked thumb up!!
rulez added on the 2020-04-23 18:11:20 by toms toms
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.
rulez added on the 2020-05-10 12:24:31 by Aghnar Aghnar
There's a bug in your depacking routine: you forgot to initialize d5.
added on the 2020-06-18 21:48:14 by hitchhikr hitchhikr
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. :)
added on the 2020-06-19 22:49:09 by Blueberry Blueberry
rulez added on the 2020-06-22 08:03:36 by aGGreSSor aGGreSSor
it's the most efficient compressor so far :-) I converted the decompression routine to 6502, it works great! Thanks.

rulez added on the 2021-02-02 02:42:08 by xxl xxl
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. :)
added on the 2022-02-22 21:58:59 by Blueberry Blueberry
Exactly two years after the last release (because it's such a nice date today): Shrinkler 4.7!

Thank you, Blueberry!
added on the 2023-01-28 13:51:29 by mash mash

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 !

[previous edits]

add a comment