pouët.net

available at http://www.farbrausch.de/~fg/kkrunchy/test/ (exe named accordingly).

i posted this at the oneliner and in the prod comments for kkrunchy as well, but this is bound to go unnoticed by everyone who didn't happen to have pouet open at the right moment, so i hope this will last a *bit* longer :)

a bit slower than previous versions from the 0.23a3 series, and needs somewhat more memory for depacking too (~11mb instead of ~6), but it seems that most people don't care if depacking takes half a second longer if it saves 200 bytes. i'm kinda unwilling to make it as slow to depack as apk2 (or, even worse, crinkler :) because i really don't want to (have to) add a depacking progress bar, so take this is a compromise.

if you're like me and don't want longer depacking time unless it's necessary, feel free to use the 023a3_neuneu version in the same directory; it includes nearly all of the recent changes and depacks somewhat faster (in fact, usually even faster than 023a2).

other changes in the 023a3/4 series: improved support for vc8 and purebasic runtime libraries. (if you're experiencing weird problems with your programs using 023a2 and use one of these two compilers, go ahead and try this version, it might well fix it).

i <3 demoscene =)

Bad timing. :')

Nice work man :)

Thanks!

Although... I did some searching but could not find a solution to this possibly very simple problem:
I use VS2008, WinXP 32bit SP3, compile, generate .map, compress and I get a .kkm file but there is no compressed size nor ratio. Just uncompressed size info. Like this:

Functions by packed size:
0.00/ 400: Camera::update Animation.obj
0.00/ 128: Animation::init Animation.obj
0.00/ 192: Animation::addUnit Animation.obj
0.00/ 1712: Animation::render Animation.obj
0.00/ 544: Animation::update Animation.obj
0.00/ 1024: Overlay::frame Overlay.obj
0.00/ 816: Overlay::precalc Overlay.obj


Its the same for all entries in the kkm-file and kkrunchy versions nor input parameters matters. What am I missing?

kkm file generation doesn't work for any of the variants using the new compression code.

the problem is that it relies on an exact mapping of which bytes in the source executable occupy which (fractional) bits in the packed data, which is kind of fiddly as you might imagine. when i integrated the new compression code my interest in writing 64k packers (or 64ks for that matter) was already pretty much over, so i never got around to writing that piece of code. use one of the older versions if you need stats. it's not really representative, but it's not that bad either.

@First posting
I noticed that on the product's glops.
It is notably slower but compresses has a more powerful compression result.

anyone knows why nod4 reports this as 'probably a variant of Win32 Agent/Trojan', i mean i can exclude it, but why oh why...

because antivirus manufacturers put one-way exe packers (i.e. those that they're not able to reverse) on their blacklists.

And because they want such masterpieces dead.

And because they are promoting these types of compressors.

And because...

Ryg: Thanks for the quick reply! Although the earliest version I could find is the 0.23 alpha from the webpage and it has the same issue. Though, I dont know if I really need the stats. I just wanted to make sure I didnt miss out on some rad feature all the cool kids use. :)

Our 64k intro for Solskogen 2010, compressed with kkrunchy (this being the most recent version I could find) refuses to run on Windows 7. It's as if it's not being recognized as an executable.

Is this a known issue or am I doing it wrong? Runs fine uncompressed.

So it seems this was released in 2007, which probably explains it. Is there a more recent version with win 7 compatibility?

Dunno if it makes much of a difference, but you should probably resort to the official binaries and not those in the "test" folder. Intros packed with kkrunchy also run on Win7 here, and they can also be packed on Win7 and still run afterwards. :D

I should have mentioned that I first tried the official binaries (well, at least one of them, anyhoo) -- and had the same problem. I'll give both of them a try again tomorrow. Thanks for the assurance that this should work, in principle. I must be doing it wrong.

Apparent fix thanks to Kusma:

This happens in Visual Studio versions later than 2005. Disable Project Properties -> Linker -> Advanced -> Random Image Placement (ish)

The lack of kkm file generation for size reports in this version of kkrunchy recently became a big problem for me, so I spent a couple of nights implementing it.

Before I put the patch out there: Has anyone else done any work on kkrunchy after the source code was released last year?