Compression toolchain

Contests 4K Game Competition - 2010
#1

With the code (riven/pjt33) and hints from the thread, http://www.java-gaming.org/index.php/topic,21630.0.html,
I’ve put together a compression tool. Hopefully it will do almost the same thing as riven’s web service but locally.
I personally like to be able to tweak all parameters of everything!

On the first run the app will write a configuration file where you adjust the path and parameters for 7z, proguard and kzip manually. So you will also need to download them. This is only tested on linux and i don’t even have an appletviewer configured for the browser so my modifications to pjt33’s server code is totally untested.

Also i’ve been having some trouble running the Zip2Gzip (http://www.java-gaming.org/index.php/topic,21630.msg177304.html#msg177304) on the files generated by 7zip. So right now they aren’t run through it at all. I’ll setup a google code project for this if it ever reach some kind of stable state :slight_smile:

Toolchain:
javac->jar->(proguard)->pack200->[kzip -> zip2gz | 7zip]

And here is the file:
http://static.slackers.se/files/fourk-0.1.jar

Please let me know about the errors you find.
Thanks

#2

So how do the file sizes compare with my webservice?

#3

Well my app produces bigger results, no question about that. But it gives you the chance to do a decent compression offline and be able to tweak the parameters if you like. That said, i will still use your service to get the “real” lower bound size for the final jar.

Here is a comparison between the two:

[tr][td]java-four-kay-shrink[/td][td]fourk[/td][/tr]
[tr]
[td]G.java => 2115 bytes
G.class => 1426 bytes
G.normal.jar => 991 bytes
G.progrd.jar => 884 bytes
G.normal.pack => 793 bytes
G.progrd.pack => 746 bytes
G.normal.7z.pack.gz => 661 bytes => test
G.progrd.7z.pack.gz => 627 bytes => test
G.normal.kz.pack.gz => 635 bytes => test
G.progrd.kz.pack.gz => 601 bytes => test
G.normal.bj.pack.gz => 647 bytes => test
G.progrd.bj.pack.gz => 608 bytes => test[/td]
[td]
G.java 2034 bytes
G.class 1426 bytes
G.normal.jar 999 bytes
G.proguard.jar 884 bytes
G.normal.7z.pack 718 bytes
G.proguard.7z.jar 991 bytes
G.normal.kz.pack.gz 634 bytes
G.proguard.kz.pack.gz 902 bytes
[/td]
[/tr]

As you can see i’m not sure about the name standard or in which order to run these tools :slight_smile: I need to take a big long look at the naming standard…

(edit) Forgot to mention, G.java is the template from this post - http://www.java-gaming.org/index.php/topic,21626.msg177577.html#msg177577

#4

I don’t have a Windows machine, so I don’t think there’s any way I can test 7zip. If you could create a really small zip file with it (e.g. zip a text file with contents “Test”) and get it to me somehow (maybe post it UU-encoded) then I can try to look into this next week.

#5

Here is a test archive, http://static.slackers.se/files/test.7z, it contains readme.txt with the contents ‘Test’.
There is a port of 7zip available at: http://sourceforge.net/projects/p7zip/files/ or in aptitude ‘p7zip-full’. Don’t know about mac though.

Before you start debugging let me run some additional tests tonight, there is always a chance I’ve messed up.
Can you also confirm the toolchain i wrote down in my first post? I’m kind of a beginner with this compression business :slight_smile:

(edit) The file in base64:

N3q8ryccAAOcDTHwCgAAAAAAAABUAAAAAAAAADju/HYAKhlKZ2vNEoAAAQQGAAEJCgAHCwEAASMD
AQEFXQAAAQAMBQAICgHCGnj6AAAFAREXAHIAZQBhAGQAbQBlAC4AdAB4AHQAAAAUCgEAgOodS3Wp
ygEVBgEAIICkgQAA
#6

Don’t bother looking at this problem :slight_smile: I was compressing the files to 7zip format so it’s kind of obvious why the zip2gz converter didn’t work. Sorry for wasting your time.

#7

Well, it seems you are trying to build something, rather than providing a solution for us to use.

I have taken a look, and I found several hardcoded paths and basically everything else was Linux. Now I don’t have a problem with Linux, as my webservice runs on Linux (including 7zip through wine), so I’m not even too biased. But very few are using Linux on our dev machine.

What you have written may be useful to you, but in the current version, you should not expect many people to jump in and use or improve it. People are lazy, truly lazy, what’s why I’m not even making anybody upload a classfile, it’s just too much hassle. For most it is good enough, and others simply already rolled their own.

Don’t get me wrong, I’d love to see you do a better job than my 4K shrinker!

#8

You’re absolutely right. In time i hope that it can become a tool that people actually can use. When the project is decent enough i’ll publish the source and binaries. But right now it’s doesn’t really work properly.

All commands are stored in settings.properties which is generated in CWD on the first start of the application. This is kind of hard to understand since there is no readme or anything, just a tiny tiny log row :slight_smile: Anyway, in that file, the path to each binary is defined along with the necessary parameters. The toolchain is fixed for now but in time that might be configurable as well.

#9

Ohh. Don’t worry about wasting my time - I was thinking of looking at it tomorrow, because I’ve been away on a business trip all week, so no time wasted.