got home late from work today, so I'll post a *full* list of rules tomorrow. but I didn't want to dissapoint anybody who was waiting for 12:00 AM of December 1st to arrive, so the submission page is open!

screenshots and custom homepages are a plus (saves me some work ). currently the FTP Hosting link is unavailable but I will be offering free hosting to whoever needs it this year.

be sure to select "Java 4K 2006" as the contest, and also be sure your minimum Java requirement is at 1.4 or earlier.

games will enter an approval queue where I will approve the games based on content. game sizes will not be validated until the contest closing, so feel free to post unfinished previews if desired . Approval queue is checked daily, so expect to see your game in at least 24 hours or less.

also, this is the first public run of the submission page. please alert me of any bugs - we can't afford to lose track of any games

finally, judges are needed, so feel free to volunteer if you're not submitting an entry.

woogley, you're confused. I didn't ask about external libs, it was somebody else.

Let me see if I understand the rules:If I use webstart, then the SIGNED jar (if I need a signature) has to be below 4k?Fine, so I'll just submit a normal JAR as the official entry and link to a webstartable version anyway... which brings me to my next question: If I submit both links (JAR and webstart) on the submission site, which version will you use to check size? I hope you'll use the archive, because I really wish to be able to provide webstart on the site as well so that people can try the games, and still have my JAR ar the official, size-checked entry.

How are things going with those comments fields for games on the site? Will that be possible soon?

Kev, yes you can use Webstart's main-class attribute, nothing wrong there. As long as it executes from the link on Java Unlimited with no command line, you're in the clear. This year's contest is shooting for a "plug and play" type of feel.

Also don't forget you don't need a manifest in a JAR if there is only one class file in the JAR (or at least that's how it used to be in the 1.2 days).

edit: Morre, about your question. You can use a signed JAR that is above 4K for webstart if you also provide the same JAR unsigned that is below 4K as a download as well. If you submit both a webstart and unsigned JAR version, the only size I check is the unsigned JAR.

A Question: If a game has both an Archive URL and a Webstart URL, which one is used for official judging? I understand that you can force the Webstart URL to be invalid by making the JAR larger than 4K via a signature, but what if both JARs fit?

For example, someone could create two separate versions of their code, one with full screen support, the other without. That would allow the Webstart version to work without a signature. Yet that developer may not actually want the Webstart version to be the one judged. How would this be resolved?

jbanes, interesting. like I said above... when it comes to size, the archive URL is the one validated. As far as which file is judged, the gameplay itself should be the same on both launch options, so does it matter? You might want to put in your submission notes that the archive URL runs fullscreen which could potentially be more fun than a non-fullscreen webstart version.

Be careful when you have differences like that though... because the game is disqualified if any part of the gameplay is different between launch types (i.e. extra in-game feature due to extra space on the unsigned jar...). Fullscreen counts as a launch feature so that won't be marked against you.

Either way I'll have judges play both webstart and archives so you'll be in the clear. Either way like I said.. best you can do is say in your submission notes if one launch version could be more fun due to fullscreen or whatever.

Woogley, Can I take you up on the hosting offer for the 4k contest. I see that my entry LadyBug is not showing the screen shot as it is bieing hosted on the free site tripod which replaces direct links to images with a plug for their site. What are the FTP details to upload my image to your site.

Is there any "j4k guide for n00bs" anywere? I have been doing something (just to try) and i have just reached 4061B only with input and rendering implemented and i don't know how sqash my code harder

Some hints:

- Use only one class- The class should inherit from JFrame if it is a webstart app. That way the close box automagically works, although you need to call isVisible() from time to time & do a System.exit(0), if the Frame is no longer visible.- Put the entire game in the constructor if possible. Each function added to the class has overhead- Avoid using class variables, unless you absolutely need them (e.g. more than one function accesses them) as these are more expensive in space than local variables in a function.- If you declare any constants as class variables, declare them as private final static. This will get them inlined.- Use the minimum number of class library methods. Everytime you use one of these, the full name (class+method) ends up in the .class file.- Use long variable names as usual, except for the class name, which should be a single letter. Use an obfusticator such as proguard. This will reduce all variables in the .class to single letters, remove unused functions.- Unjar the file proguard produces and then rejar using a standard zip compressor such as 7zip or kzip. Remember to specify the command line switches to get maximum compression.- You don't need a manifest if you use webstart as the only starting method. If you do include a manifest (& it is a nice touch) you only need the version and main-class statements.

- If you declare any constants as class variables, declare them as private final static. This will get them inlined.

You save even a little more space by manually removing the constants and putting the value in their place.

From the start you can program a little more normally, so it is easier to follow your own code. Then remove constants and replace them with their values. Don't use temporary variables for calculations, just put the calculation inline. Don't worry about using single letter variables, because an ofuscator will take care of that for you. It also removes class information for reflection, because you won't need them.

Don't use temporary variables for calculations, just put the calculation inline.

If you do use a variable, however, don't be a scrooge with them. Since local variables are all on the stack, it doesn't matter to the compiled code if you reuse one variable or ten. It generates pretty much the same code. So I guess the other lesson to get out of this is to watch out for false economy.

Don't use temporary variables for calculations, just put the calculation inline

That is certainly a false economy - any halfway decent peep-hole optimiser will automagically inline such assignments.(a value written to, and immediately read back from a local)

Keeping the number of entries in the constants pool to less than 256 will give a very real gain.It will avoid use of the larger ldc_w instruction.(and may also help compression, because you will potencially have one less unique symbol to compress)

Also, *never* use double or long constants - they use up 2 entries in the constants pool,and are read from the pool using a different instruction.It is best to store them as float/int and let them be cast upto the needed type.

A good example of this (as most will be using it ) is enableEvents(long).If you simply pass in a constant to this method (regardless of whether it is an int or a long),it will be expanded to a long by javac, and stored in the constants pool as such.

It is better to store the value in the constants pool as an integer, and then cast it to a long when it is passed into the method.However, i'm unsure if you can perform this optimisation using the Java syntax;or whether the java compiler will always evaluate the constant, and extend it to a long.(it is certainly an optimisation worth automating with BCEL)

[crazyness]infact, if you are using a small value (10 or less) for the enableEvents flag (for example 6 ) - the optimal solution turns out to be enableEvents((long)(3+3)) as this completely eliminates the constants pool entry! (there are specific instructions for pushing the integer values -1 through to +5 onto the stack)[/crazyness]

The same goes for people using Math.PI; cast it to a float before you use it, to avoid the overhead of a huge 8byte! constants pool entry.

Structuring your code so the active scope of a variable is as small as possible will also give you gains.Due to Java's smaller-bytecode instructions for accessing the first 4 local variables (1byte rather than 2),keeping the active set of local variables as small as possible will help your code size.

[crazyness]infact, if you are using a small value (10 or less) for the enableEvents flag (for example 6 ) - the optimal solution turns out to be enableEvents((long)(3+3)) as this completely eliminates the constants pool entry! (there are specific instructions for pushing the integer values -1 through to +5 onto the stack)[/crazyness]

Are you trying to tell me that javac doesn't evaluate the 3+3 and put a 6 in the bytecode when compiling the source code? I have a hard time believe that, but not enough energy to check .

[crazyness]infact, if you are using a small value (10 or less) for the enableEvents flag (for example 6 ) - the optimal solution turns out to be enableEvents((long)(3+3)) as this completely eliminates the constants pool entry! (there are specific instructions for pushing the integer values -1 through to +5 onto the stack)[/crazyness]

Are you trying to tell me that javac doesn't evaluate the 3+3 and put a 6 in the bytecode when compiling the source code? I have a hard time believe that, but not enough energy to check .

oh no, you are absolutely right! javac *does* evaluate it (and infact expands it to a long constant 6L ).Thats the problem, and why the optimal solution cannot be achieved by compiling with javac - without later performing such bytecode optimisations with a tool like BCEL.

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