Kzip is giving me around 48% I think, but I’ve not got the figures here to check.
Kev
Does bz2 output jar-compatable files?
jar=zip and zip has a bzip2 mode (and copy… and deflate [default] and deflate64).
Hm. But it isn’t any good anyways.
The p200/gzip combo is much better. (Pack200 saves alot!)
3424 bytes for my game… instead of 4094 (jarg+kzip and the image was even external!)
[i]# The presentation (jar, class, or other) does not matter, as long as the code can be directly run from the shell.
The target JRE is 1.5.[/i]
So. Uhm… we could actually use that… right?
Gah… a half k (670+2 bytes actually)… I could have done so much with that :
I though bz2 was a different beasty all togther. But I could be wrong. I ofton am :’(
bz2 does not create .jars, indeed it can only compress single files.
I have found that 7zip with compression set to max, and the algo set to zip (so its jar compatable) created a smaller .zip file than bzip2 could a bz2 file, with the advantage that it is a .jar. About 55% compression I think. Additionally the overhead for the 7zip created archive was very small (about 70 bytes).
Will.
1.4 chain:
-compile
-jar (doesn’t matter if it’s stored or compressed)
-obfuscate (eg jarg or jax->jarg)
-extract
[-decompile]
[-check if there’s still stuff which should be inlined]
[-if so change it and goto 1]
-jar (7zip max or kzip[usually better] and compare if it’s smaller than the jar from step 3)
That one left 2 bytes… and the image had to be external.
1.5 chain (1.5/webstart only and you need some serversided script for serving it):
-compile
-jar (doesn’t matter if it’s stored or compressed)
-obfuscate (eg jarg or jax->jarg)
-extract
[-decompile]
[-check if there’s still stuff which should be inlined]
[-if so change it and goto 1]
-jar (store)
-pack200 (–no-gzip)
-gz(max eg with 7zip)
That one left 672 bytes… and the image was also included.
Another one:
T4XI!
http://games.cokeandcode.com/4k/city4k/city4k.jnlp
http://games.cokeandcode.com/4k/city4k/city4k.jar
Main-Class: R
I’m seriously considering not entering anymore, just carry on writing them anyway!
Kev
game list updated… I had to make an alternative launcher for T4XI, because games.cokeandcode.com still doesnt work for me. Hope you dont mind kev 
No problem… as long as it works… I’m really getting worried about that domain.
Some people got, some people don’t…
Kev
Working with images is a right git isn’t it? I’ve tried SuperPackME but it doesn’t seem to do me any good.
Anyone got any tips? I’ve got an indexed image with 23 colours at size 80x32. I can just fit it in but at the expense of game features 
Kev
Yeah, make it 40x32 instead 
Cas
Cas is right, but why stop there? Make it 16 or even 8 colors and 40x16 or even smaller. Should save some space, and if you then scale it up when drawing, it will give the game a nice retro feel. In Late 4K I ripped my own old gfx from atari, and scaled it by a factor 2.234324… or something, and still works sort of OK.
Has anybody tried to generate images (“sprites”) in code? How has that been compared to loading huge images (>150B :))
My Super Sprint 4k clone is still too large to enter, first I want to get the game working, then I’ll concentrate on making it small. I’m currently using 7088 bytes, which is 173% of the allowed size.
I’m going to be looking at having all images included in the code, therefore no image loading code is required, also no headers will be needed for stuff like PNGs so I should be able to save some space.
I also have lots of methods and static final variables, I think another thread mentions that I should inline everything into a single main method to reduce space, can anyone confirm this?
There is a great article on saving space in code, it takes a look at how to get Hello World down to 70bytes.
http://www.sys-con.com/story/?storyid=37060&DE=1
I was wondering as well if 1.1 class files are smaller than 1.5 class files, has anyone tested compiling with a -target=1.1 flag to see if that helps? I’m not using any 1.5 features so this is a possibility for me.
Andy.
[quote]Working with images is a right git isn’t it? I’ve tried SuperPackME but it doesn’t seem to do me any good.
[/quote]
How so? SuperPackME will probably give you about a 15% reduction (displayed as 85% reduction rate) with those images, plus it will compress even better. Be aware that even if the final result is near 100%, the JAR compression will still reduce it above and beyond the size of the PNG files.
[quote]Anyone got any tips? I’ve got an indexed image with 23 colours at size 80x32.
[/quote]
If you’re using SuperPackME, split the images apart. That will save you from having to draw only parts of the image. i.e. You can use g.drawImage(image, x, y, observer) or g.drawImage(image, x, y, scaleWidth, scaleHeight, observer). Also make sure you’re using 7Zip. I’ve tried KZip, but haven’t gotten any improvement. I use 7Zip like this:
7z a -tzip -mx=9 myzip.zip file.class META-INF/MANIFEST.MF
[quote]I can just fit it in but at the expense of game features :(
[/quote]
That's always the tradeoff, isn't it? :-) Beware that your best results from SuperPackME are going to be from small images with few colors. It's best if you keep the colors per image below 16. :-)Last one from me…
Webstart: http://games.cokeandcode.com/4k/hack4k/hack4k.jnlp
Jar: http://games.cokeandcode.com/4k/hack4k/hack4k.jar
Main-Class: H
Controls are:
Cursors - move character and attack
H - Heal yourself
Thanks for running the contest… its been a brilliant kick start for me. All the source for my entries is available on the little java games site in my sig.
Thanks again,
Kev
[quote]My Super Sprint 4k clone is still too large to enter, first I want to get the game working, then I’ll concentrate on making it small. I’m currently using 7088 bytes, which is 173% of the allowed size.
[/quote]
I found it better not to do it that way, and if I wanted to add a feature then I had to optimise some stuff to get it in, else I can’t have the feature (e.g. I don’t have full screen mode because it cost too much).
Will.
Speaking of full screen, anyone got a better way of doing it (size wise) than I am?
I replace:
f.setSize(1024,768);
f.setVisible(true);
with
{
GraphicsDevice gd = GraphicsEnvironment.getLocalGraphicsEnvironment().
getDefaultScreenDevice();
gd.setFullScreenWindow(f);
gd.setDisplayMode((new DisplayMode(1024, 768, 16, 60)));
}
And it costs me 139 compressed (7zip, max zip compression) bytes.
f is my JFrame.
Will.
I’m of the opinion that I write the game that I’d like to play (nothing says I can’t release the game after the comp at 150Kb) and then I take out all the bits I don’t really need (fancy graphics) to get it under the 4k limit.
I too would like to thank the organisers, this comp has really lit a fire under my ass to get coding on small managable (see finishable) projects rather than working on huge unfinished stuff…I think Cas made this comment 3 years ago, I’m finally listening Cas!
I have a few ideas as well for other entries, so as soon as I finish this one, I’ll start on the next, the current record for number of entries is currently 5 or 6 I think.
Andy.
I wish I’d listen to myself some time :-X
Cas
it is good advice
Regarding the full screen stuff, I ended up taking out the “gd.setDisplayMode((new DisplayMode(1024, 768, 16, 60)));” call which saved a lot of bytes, and isn’t so great on LCD monitors anyway (since they are best run at native resolution and there is no way I have enough space to make it user adjustable).
Will.