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

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.

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.

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.

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

get over the harsh language, twice in a row you've more or less accused me of things I haven't done (saying you're trying to make everything hard, saying the 8k is a bad idea, etc.)

I'm not even here to talk about the 8k, everything I'm talking about here is the 4k. if you want to make an 8k, go for it, but this thread is not the place to organize it. this topic, as the subject suggests, is clearly about planning for the '08 4k contest.

my personal stance on the matters in this thread:

- 8k: neutral, you can organize that elsewhere- pack200: see my second post on this thread- compression: while I agree it's not the most fun part of the contest, there's no feasible away around it. Abuse says it perfectly when he says "you cannot escape it"

also, Riven, I did not disagree with your comments without making a fair argument. please re-read my reasoning before taking it personally.

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.

yeah, that's the ticket - though I was intending to do a lot more than that, and perform it automatically via bytecode manipulation.

I wonder if the set of public classes defined in the "java.*" package inside the "rt.jar" can be assumed as being a constant.If so, an entire method invocation could be simplified down to 1 or 2 integers. (rather than several 100 bytes as is when accessed via the constants pool)

It's a very nice idea, and I couldn't have thought of it by myself. Maybe it's a step-stone to another hack.. We'll see!

I agree, the cost per invocation would be greater, especially for primitive type parameters.

Perhaps using reflection is too costly and not a good direction to investigate, rebuilding the constants pool using the static-linking mechanism maybe a more profitable (and lower overhead) means of implementing a similar compression scheme. (though only feasible if the static-linking mechanism can be made to work!)

I've done some interesting experiments with reflection.. you can't rely on the class names being in the same order, of course, but.. say.. if you need to name 200 enemies in a game, picking class names from java.awt might be an interesting approach.

Didn't someone last year try embedding a pack200 jar inside a class file?If I remember rightly, most if not all the gains were eaten up by the overhead in unpacking & instanciating the contained class within said pack200 archive?

You're all insane. I love it.Granted, I've far less experience with these things than most of you guys, but this way of thinking is well above my skills on so many levels. I mean, I understand what you're saying (for the most part), but there's no way I'd ever have thought of some of those things myself. Brilliant, I say. And pretty silly. :>

May I say I fear the day Markus and Abuse re-enters the contest? (I can't remember if Riven participated or not last year?)

Didn't someone last year try embedding a pack200 jar inside a class file?If I remember rightly, most if not all the gains were eaten up by the overhead in unpacking & instanciating the contained class within said pack200 archive?

Yeah that was me

for my entry it did not help, but for many other 4k entries i tested it did give net gains.

I will probably attempt to optimise the 'launcher' code further this year to see if it will give net gain for my entry this year.

You're all insane. I love it.Granted, I've far less experience with these things than most of you guys, but this way of thinking is well above my skills on so many levels. I mean, I understand what you're saying (for the most part), but there's no way I'd ever have thought of some of those things myself. Brilliant, I say. And pretty silly. :>

May I say I fear the day Markus and Abuse re-enters the contest? (I can't remember if Riven participated or not last year?)

Given my field is J2ME, I have a vested interest in any new tech. that can reduce code size (though obvious mangling with the bytecode stream, or manipulating the reflection api is beyond the scope of what is possible in J2ME)

A further optimisation that has yet to be investigated is the J2SE JSR/RET instruction ([jump to | return from] sub-routine).it is normally only used for flow of control when handling finally{} blocks, however given that 4kb games are typically contained within a single 'main' (be that the 'main' method, or the class constructor), it could be used to embed utility methods within this 'main' method allowing them to be executed as sub-routines. (reducing their invocation cost, and eliminating several constant pool entries)

It is worth noting the JSR instruction, while still supported, is no-longer used in classes generated by the 1.6 compiler. (instead, the contents of the finally block are duplicated)A change that has come about due to the reorganizing(optimisation) of the class file verifier (so it operates in a similar way to those employed in J2ME VMs)

Therefore, if a bytecode tool to perform this optimisation were to be attempted, you'd have to use the java 1.5 compiler (not sure if 1.6 compiler -target 1.5 will work)

Given my field is J2ME, I have a vested interest in any new tech. that can reduce code size (though obvious mangling with the bytecode stream, or manipulating the reflection api is beyond the scope of what is possible in J2ME)

I am not 100% sure whether it will work with J2ME... it should, but i found by creating a new Class Attribute and then embedding image data inside this attribute significantly saves precious bytes by removing an entry in the JAR and is better than embedding using Hex ecoded values in the source.

The JVM ignores this new unknown attribute and it is simple to read in the image data by means of pre-appending a unique byte sequence ( in my entry last year it was

Quote

||

) In your code use the .getResourceAsStream(<the class filename>) and seek until you reach this magic unique sequence. From there is is as simple as reading in you images as usual.

Unfortunately most J2ME VMs prevent you getting a stream to the class files within the jar

There is also the memory overhead of embedding any kind of data inside class files - in that it will effectively be loaded into memory twice - once in the class file definition, and a second time in your expanded in-memory representation.

To me the allure of pack200 was getting those few hundred more bytes into the game. The original appeal of the j4k was 'can it be done?' and then it turned into 'yes, it can be done, now what cool games can be made?' and Kevin, Markus (and a few other people I can't name) proved that really cool games can be made in 4k.

I'm sure there are lots more cool games to be made in 4k, even without pack200. Me, I'm still waiting for the lwjgl 16k.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org