Oh please… me != n00b. :
Inside the ZIP (or JAR…) there is a little chunk of GZ for each ZipEntry. The GZ is the data/content, ZIP is the structure, JNLP is the accessor, HTTP is the transportation.
In ZIP (or JAR…), the ‘zipentry-listing’ is actually twice stored, one ‘stream-like’ at the beginning, and one ‘table-like’ at the end. It’s such a waste of space!
Maybe J4K has gained too much momentum to steer it around a bit? It would be too bad, because I’m not really fond of where it’s heading
[quote=“Riven,post:21,topic:30440”]
… I didn’t even submit an entry last year. :-\
I kind of like the idea of having a standardized compressor and a higher max-limit for the class itself, although it would not lead to equally sized games, which is a shame… 
Riven, seriously, you’re splitting hairs there. It would be ridiculous to count ONLY the “compressed byte count” of the class file without counting the ZIP overhead that is neccessary to reassemble the game to be loaded. It’s hardly a waste of space, it’s how your game is put back together. If you want to take out the duplicate zipentry listing without corrupting your zip file, nobody’s stopping you.
And this has been the case since J4K1, so it’s not a new rule or direction; if anything, there’s too few changes (hence why some people want pack200).
[quote]Riven, seriously, you’re splitting hairs there. It would be ridiculous to…
[/quote]
Yeah, relax. Everybody is entiteld to their own opinion, and it’s not up to you to say my intent is to split hairs and to make everybodies life hard and miserable. faking a sob
[quote]If you want to take out the duplicate zipentry listing without corrupting your zip file, nobody’s stopping you.
[/quote]
Can’t be done. Not possible. one listing == corrupt archive
You know what the point is - and I apologize to Moogie for the “average Joe and his dog” - IIRC he was the one that re-zipped my JAR and told me I had >100 more bytes to spare. I tried, and tried, but I simply couldn’t get it to compress it to the claimed size. Even downloaded the generously released ‘bruteforce tool’, which kept crashing on me, and the JARs it spit out, where not that far from 4096 bytes anyway - I simply failed to replicate it! This was extremely demotivating, knowing that if I could only get that zipper to work, all my problems were over, and I’d have room for a few more features.
I kinda stopped right after that.
I just don’t want to spend half of the development time on finding/building/bruteforcing the right JAR, it’s a Java contest! Maybe we should create a sub-category, or I could maybe build a little site to roll my own geeky-contest.
Who’s got a spare dedicated/colocated server with a fancy JRE installed? Just send me a PM, I can offer a nice contest in return
what the hell are you talking about?
anyway, the whole JAR thing comes with the territory. the fact of the matter is, code is not the only thing you have to optimize.
if we were to run a contest where the server zips up everything FOR you consistently, there would be WAY too many complaints about “well, from the server, it’s 4.2k, but on my local machine I’ve crunched it with proguard/JoGa in such a way that it’s 3.82k”
the problem with compression in general is there’s nothing consistent about it. each game is subject to a different compression setting that may or may not work better.
[quote=“Riven,post:25,topic:30440”]
I wish I could…
[quote]what the hell are you talking about?
[/quote]
Little aggitated?
Anyway, the slightly more or less than 4K isn’t a problem as, as said earlier, it whould be a 8K bytecode contest, but heck, why am I even bothering, you’re attacking it like there’s not tomorrow, so I’m not really expecting to convince you.
I’m going to see where I can get a tiny server with full access and give a few of my ideas a try.
To lighten the mood a little, I scraped all my art-skills together
how 'bou that eh? 
:-*
String compressedClass = <utf8encodedZlibStream>;
byte[] zlibStream = getBytes(compressedClass); // decoding algorithm for whatever algorithm you used to encode into utf8 form
Inflater inf = new Inflater();
inf.setInput(zlibStream);
byte[] uncompressedClass = new byte[100000];
int len = inf.inflate(uncompressedClass);
Class c = this.getClass().getClassLoader().defineClass("A", uncompressedClass, 0, len);
c.newInstance();
10 lines of code, and i’ve defeated your “8kb uncompressed class” limit.
Compression is a part of 4kb development, you cannot escape it.
However, good compression does not make a good game AND your game does not need to be optimally compressed (impossible!) for it to be feature complete.
Write a good game, and write it small - then optimise; optimise; optimise until you reach the 4kb limit - then stop.
I think i can say that this seemingly yearly occurrence of bickering around the rules of the competition is not good for the image of the competition.
I have voiced my opinions but i am not evangelical about forcing my view. I have listed counter arguments for the other proposals so that people can make up their own mind.
What ever the outcome, the rules have only a minor part in the development of a 4k game, most of the challenge and fun does come from optimising, hacking and using tools to hunt down those last 15 bytes
I will be attempting to enter a game no matter the rules. It would be a little childish to boycott the competition and the fun it is just because a rule! Sure i would love to have the extra 1k that PACK200 would give me to make a much more detailed game world. But I will make do with constraints given.
I just had an absolutely stonkingly crazy, but potencially amazing size saving idea 
:hint: the constants pool can be almost entirely eliminated :-X
lol, nice art skillz ;D
Certain element or irony… that image is more than 4kb in size ;D
Pah, using superior compression - cheating!
It should be supplied as an uncompressed bmp, and compressed on the server ><
[quote=“Abuse,post:36,topic:30440”]
Ouch. Meow.
That decompression code was a really good point, though. I hadn’t thought about that.
Hm? Any reference to a class or method or field causes UTF-constants to be inserted inthere. Little you can do about it. If you use your on-the-fly decompressor, the original compressed bytecode, has an constant-pool too, so you’re not really saving much. Reflection is another way to shrink the constant-pool, but it has significant overhead everywhere you use it. Hm… I’m out of ideas. You got something figured out that will make us worship you for the rest of your days.
One more hint could do!
g.drawLine(..);
g.drawRect(..);
*cough*
Method[] m = Graphics.class.getMethods();
m[54].invoke(...);
m[33].invoke(...);
* Riven hopes not.
again, what the hell are you talking about? to this day, I have never said anything against (or for) the 8k contest. it’s like you’re trying to cause an argument with me that doesn’t exist.
but in regards to the 8k, I’m fairly sure it would be a repeat of what happened with the 16k
but “attacking it like there’s no tomorrow”? bullshit. I’ve never even mentioned it in my posts. ever.
You are reacting to my suggestions of how to make a 8K-source variant. In my interpretation, that was your response against it.
You’ve been using strong words three times in a row now. I’m like… why…
“it would be rediculous to…” & “what the hell are you…” aren’t exactly the usual replies on these forums - before you start getting that worked up, you might reread what was said, or look for some source for miscommunication. I’m not here to try to have a fight with you. I’m just sharing my opinion with others - some argree, some disagree strongly - that’s all right, as long as we all keep our cool…
Now hopefully, you’re not taking this the wrong way. :-*