Regarding peephole optimizations, are they worth it? Have you managed to fit something valuable in the size gap you got from making a peephole optimization?
[quote=“DonaldEKnuth,post:21,topic:26032”]
I know that Abuse (Robin Chadwick) used peephole optimizations to get another 10-20 bytes during the second year of the contest. Unfortunately, it’s such a painful process that he kind of burned himself out doing builds. IMHO, your best bet is to automate any optimizations you find by writing code in using the Bytecode Engineering Library. That way you can keep your builds automated rather than spending time on manually tweaking your code.
I personally don’t think it’s worth it, but then again I don’t have quite as much time to burn as some of you young’uns. 
Well I don’t intend to do anything such this year either, it would have been nice to create another entry (some kind of action game this time) but it will have to wait. There got to be people here younger than me though, after all my first computer was a Commodore 64. 
(Some kind of fuzzy age scale.)
[quote=“DonaldEKnuth,post:23,topic:26032”]
Yeah, but for all I know you were only 2 years old at the time! 
[quote]Yeah, but for all I know you were only 2 years old at the time! Cheesy
[/quote]
That’s why it’s a fuzzy scale.
for what it’s worth, I’m only 18 (turning 19 on february 16th)
I find it odd the Kzip using a larger search window to find the best match would be relevant when we are talking about source files that are tiny to begin with (i.e.the entire source data would likely fit into a 8k or 16k search window). There must be something more to it, or I just don’t have a good understanding of the deflate algorithm?
Anyway… good info in this thread. I may be able to get a few more bytes.
[quote=“jbanes,post:22,topic:26032”]
Chaddock >:( :
I only started worrying about it when I had features already in, that I couldn’t get to fit any other way.
Its definitely a worthwhile investment though, as JBanes pointed out, they can be quite easily automated, so you silently reap the benefits in any future games.
(It just so happens bytecode optimisation for size is a very real concern in J2ME development - my job)
One thing I realy want to automate, is replacing methods & method invocations, into sub-routines.
It will allow more modular program structure, without the overhead of methods.
(unfortunately, such an optimisation would be of no benefit to J2ME - as there is no JSR instruction >:()
Abuse, is that you?
yeah, dropped my other account ages back - 110 posts to be exact
I spent a fair bit of time comparing kzip & 7zip in december. I found that 7zip gave good results, but that manually playing about with the kzip parameters could find a “sweet spot” with better compression. You need to generate zips with several /bxxx options & then select the best one.
The Joga/Proguard combo looks interesting. Currently I’m using proguard 3.2 as I’ve found some of the proguard 3.4 optimisations cause a significant loss in throughput. This was particularly a problem with Speed4k, which really hammers the processor.
Alan
[quote=“DonaldEKnuth,post:14,topic:26032”]
Donald, can you post the KZip parameters you’re using? I’ve run through the block size space and I’m simply not seeing any improvement with KZip 11/22/05.
If I just type KZip I see that my version is compiled Nov 23 2005, I guess it’s the same version as you use but then agai perhaps it isn’t?. What I did was simply to extract the zip-file to an empty dirextory using 7Zip. Then I issued the command (while inside that directory): kzip /r xero.jar .
And got xero.jar with size 3951 bytes. I am not doing anything “fancy” as you can see. I tried it again just now, same result (and the resulting xero.jar works).
Interesting. The version I had was the Mac version which should have been the same. Doesn’t seem it was, though. I was able to reproduce your results on Windows, but the resulting JAR file crashes the JVM. The source JAR file works fine, so I’m not sure what that’s all about. It’s questionable at this point whether KZip will work for me or not. We’ll see. 
FWIW, the latest Mac version (posted a day before the Windows version) produces files that are between 4300 and 4400 bytes, depending on the block size used. The windows version can hit 3,910 bytes with “kzip /r /b128 Xero.jar .”.
[quote]. I was able to reproduce your results on Windows, but the resulting JAR file crashes the JVM. The source JAR file works fine, so I’m not sure what that’s all about.
[/quote]
It works great for me, I’ve only played it for about 10 minutes though (the repackaged JAR I created).
[quote]The windows version can hit 3,910 bytes with “kzip /r /b128 Xero.jar .”.
[/quote]
Is this the version you were using when it crashes the JVM?
When does it crash the JVM? I use Windows XP Pro SP2 with all patches and JVM 1.5 from Sun.
Pretty much immediately. If I run it, the screen changes to a nearly black screen (some streaking with the desktop image, but barely visible), then poof it returns back to the desktop. The console dumps the standard JVM crash data and creates a log file. I was eventually able to run it, but it seemed to crash unpredictably.
Not that it should matter, but does the JAR I compressed with KZip crash as well? Temporary Xero.jar (I’ll take it away when you want to [after your next reply] just thought you might like to try it.)
Worked for me. XP Professional here
Yours works. I’ve attached some of the files that don’t work. See if they work on your machine.
(I’ve renamed them with the PNG extension for uploading. Just change the extension to JAR to run them.)
Curious. I used kzip on kanainvaders & that runs on the mac. Maybe there’s a bug in the mac’s unzip implementation, which is only triggered on special conditions?