Fastest depacker

[Don_Adan]

Originally Posted by VladR

Hi guys. Just joined the board. Happy to be here !

I'm working on a 4 KB demo for Atari Jaguar and am in need of some serious packer. I don't mind abysmal depacking times, as it can't possibly be that long with just couple KBs.

Is Shrinkler achieving best compression ratio ?

Obviously, there is going to be a threshold where depacker, regardless of its compression ratio, is simply too big for a 4 KB executable.

Are there any known 4-KB specific depackers with best ratio ? I don't mind implementing it by myself, I just need to avoid scenario where I implement something and a week later find out I should have implemented a different depacker.

The target data payload is:
68000 code
GPU RISC code
DSP RISC code
gfx data
audio data

The best compression ratio has PackFire (LZMA mode). Depacking is slow, but can be ok for 4KB intro. I created (packed only) one 4KB intro for test some years ago.

[ross]

Originally Posted by Don_Adan

The best compression ratio has PackFire (LZMA mode). Depacking is slow, but can be ok for 4KB intro. I created (packed only) one 4KB intro for test some years ago.

Hi Don, this can be true for pure data but very few times for the final executable.
LZMA depacker code is much bigger (and also a little slower) than Shrinkler one so for 4KB intros I wouldn't choose it.
But I have no statistical data to show

[Don_Adan]

Originally Posted by ross

Hi Don, this can be true for pure data but very few times for the final executable.
LZMA depacker code is much bigger (and also a little slower) than Shrinkler one so for 4KB intros I wouldn't choose it.
But I have no statistical data to show

My version was optimised and perhaps was short enough. I used this one only for fully PC relative code and with BSS_Code hunk, because i dont want to use alloc/free memory and to reloc code. I dont remember depacker size, about 600-800 bytes, i think. How big/long is Shrinkler depacker?

[VladR]

I welcome all ideas, as they're all new ideas I haven't had 5 minutes ago

I think I now understand how people cram some bitmaps into their 4 KB demos. If your executable is around 8 KB, there's definitely room for some small bitmaps (especially at 4-bit color).

I just compiled out the 32x32 terrain heightmap (1,024 Bytes less now) and the executable is just 2,880 Bytes (from 3,904). Shrinkler took it down to 1,412 Bytes, e.g. 49.08 % !!!

Those 2,880 Bytes is pure code - roughly 50% 68000 and 50% GPU RISC. I do wonder, how well it compresses either one. I'd suspect RISC is packed better because of the same combination of many instructions.

Looks like the heightmap was compressed from 1,024 Bytes to 668 (2,080 - 1,412 ->66%), which is still pretty neat. I wouldn't have guess it'd do that much.

Of course, next step is to reduce the heightmap by 4:1 from 32x32 to 16x16 and interpolating the rest via code, hence I should be around ~1.6 KB with base code, leaving ~2.3 for Audio and perhaps some other effects.

[ross]

Originally Posted by Don_Adan

My version was optimised and perhaps was short enough. I used this one only for fully PC relative code and with BSS_Code hunk, because i dont want to use alloc/free memory and to reloc code. I dont remember depacker size, about 600-800 bytes, i think. How big/long is Shrinkler depacker?

<180 bytes

[Don_Adan]

Originally Posted by ross

<180 bytes

Then maybe packed exe can be shortest. If you want you can check size of LZMA optimised depacker from BC Kid. I cant check this.