The following is my suggestion for a template. Note that the graphics context is grabbed outside the main loop, which would cause issues if the browser window is minimised and then maximised as internet explorer assigns a new graphics context. However fortunately isActive() goes false when the window is minimised and thus the thread terminates. It is recreated when the window is maximised, which causes a new graphics context to be grabbed.

The optional lines can be omitted if you don't care about Appletview and Webstart, and are desperate to save a few bytes.

The following is my suggestion for a template. Note that the graphics context is grabbed outside the main loop, which would cause issues if the browser window is minimised and then maximised as internet explorer assigns a new graphics context. However fortunately isActive() goes false when the window is minimised and thus the thread terminates. It is recreated when the window is maximised, which causes a new graphics context to be grabbed.

The optional lines can be omitted if you don't care about Appletview and Webstart, and are desperate to save a few bytes.

Won't this cause the key to toggle on/off repetedly for keytyped events?

What keytyped events? The 1.0 event model has KEY_PRESSED and KEY_RELEASED.

If I hold down a key then keyDown remains consistent and keyPressed flickers inconsistently, but it's probably quite variable between OSes and Java versions. My Debian/KDE/Sun Java 6 setup has aggressive key-repeat, so I get a continuous stream of KEY_PRESSED and KEY_RELEASED events. It appears that the (KEY_RELEASED KEY_PRESSED) auto-repeat sequence occurs an integer number of times between frames (don't ask me how it's so consistent), but not always once per frame.

I think what I have there will be adequate for my games this year; the ideas I have in the pipeline are mainly mouse-driven, and the one key-driven one is going to rely on keyDown. The whole issue of key repeat is a thorny one, though, because there's so much variation. Some games last year were hard to play on my box possibly because they weren't expecting it.

What keytyped events? The 1.0 event model has KEY_PRESSED and KEY_RELEASED.

If I hold down a key then keyDown remains consistent and keyPressed flickers inconsistently, but it's probably quite variable between OSes and Java versions. My Debian/KDE/Sun Java 6 setup has aggressive key-repeat, so I get a continuous stream of KEY_PRESSED and KEY_RELEASED events. It appears that the (KEY_RELEASED KEY_PRESSED) auto-repeat sequence occurs an integer number of times between frames (don't ask me how it's so consistent), but not always once per frame.

I think what I have there will be adequate for my games this year; the ideas I have in the pipeline are mainly mouse-driven, and the one key-driven one is going to rely on keyDown. The whole issue of key repeat is a thorny one, though, because there's so much variation. Some games last year were hard to play on my box possibly because they weren't expecting it.

Does the jvm for linux *still* have that repeated keypress/release bug when holding a key down?!That's been there for as long as i've been using Java, core awt behaviour that simply fails to conform to the awt event model specification.

Does the jvm for linux *still* have that repeated keypress/release bug when holding a key down?!That's been there for as long as i've been using Java, core awt behaviour that simply fails to conform to the awt event model specification.

Mindboggling.

To be honest I think it's my KDE settings rather than the JVM, but anyone who wants to write cross-platform should assume that it's a possibility. The joys of write-once-debug-everywhere. After all, who's going to reconfigure their desktop just to play a minigame?

Here is a question which has not already been asked, it seems : Appel, when will end the submission period for the coming 2010 competition ? I didn't find the answer on the official site or in this topic.

Here is a question which has not already been asked, it seems : Appel, when will end the submission period for the coming 2010 competition ? I didn't find the answer on the official site or in this topic.

Specifically the pack200 rule. Does it even need to be there since the games are hosted by your own web host? I would like to embed a pack200 version of my game into a loading stub which reads itself and extracts the embedded game, creates an instance and uses it.

and what is the rules about signing? is the digital signature component counted toward the 4096 bytes? last year the rule was:"If your JAR is below 4K until you sign it, you must provide a runnable unsigned JAR to demonstrate the game meets the competition rules." but since it is now an applet it is not "runnable" unless it is in the context of appletviewer.

Specifically the pack200 rule. Does it even need to be there since the games are hosted by your own web host? I would like to embed a pack200 version of my game into a loading stub which reads itself and extracts the embedded game, creates an instance and uses it.

and what is the rules about signing? is the digital signature component counted toward the 4096 bytes? last year the rule was:"If your JAR is below 4K until you sign it, you must provide a runnable unsigned JAR to demonstrate the game meets the competition rules." but since it is now an applet it is not "runnable" unless it is in the context of appletviewer.

The rules on the java4k.com site today are outdated.

Regarding pack200. I don't remember all the reasons why it wasn't allowed. Some discussion about it is in order perhaps.

I haven't really taken a look at pack200. Does something need to be supported on the server?

nope nothing needs to change on the server side, instead of uploading foo.jar developers would upload a foo.pack.gz

Any jre 1.5+ should detect this as a pack200 file and run it.

But do be careful since there are two versions pack200 atm (java 5 and java 6 editions). Using the pack200 from java 6 will not work on java 5, so when creating the pack200 files do remember to specify the parameter to create a pack200 file compatible with java 5.

However its unlikely for there to be any significant size reduction when using pack200 on a 4k file.

well the server stuff is just there if you want to maintain backwards compatibility with older versions of java, it'll just check if the jre requesting the file supports pack200, if it does it gives it the foo.pack.gz file, if it doesn't then it gives it a normal foo.jar. Its a good way to save bandwidth and give users a quicker download but unlikely of use to the 4k competition.

DeliverablesApplets only (required), webstart optional (applets can be launched as Webstart).

Isn't this a bit overly restrictive? I was planning on resubmitting my poker server/client this year, modified to not use the command line for the server address input, but I'm not sure an Applet can act as a server, or even connect to a server?

Tried the Java 1.0 keyboard event model, but only managed to save about 6 bytes, which was rather strange as enableEvents() was no longer required. Probably 'enable' and 'Event' occurred elsewhere and compression did the rest.

The java penetration thread elsewhere on this site makes interesting reading, with java 1.6 installs really taking off now, but java 1.5 still having a large user base. 1.4.2 seems to be down to 5%. I'll probably code for 1.4.2 once more out of force of habit, but 1.5 now looks the better target.

It has been particularly wet and windy in the UK this last week or so, with the result that I spent last Sunday refactoring my isometric game codebase into 4k.

Isn't this a bit overly restrictive? I was planning on resubmitting my poker server/client this year, modified to not use the command line for the server address input, but I'm not sure an Applet can act as a server, or even connect to a server?

Note that the Applet-only restriction only applies to the end-user part of the game. As long as the end-user can play the game in a web browser, just like should be the norm, that game qualifies. You may of course write some server application that the game interacts with. I am not knowledgeable enough of Applets to know if you can host that server wherever, maybe you can with a signed Applet. Perhaps I can look into hosting it, but I am skeptical about it since running third-party processes on the machine is dubious.

But I am willing to accommodate anyone that wishes it. Just need to talk to me in order to find a solution that works.

Has there been a decision on how to handle scoring for games where one judge couldn't start the game? Also, will they be asked to try it on multiple platforms? I understand if this is not the case, of course.

Note that the Applet-only restriction only applies to the end-user part of the game. As long as the end-user can play the game in a web browser, just like should be the norm, that game qualifies. You may of course write some server application that the game interacts with. I am not knowledgeable enough of Applets to know if you can host that server wherever, maybe you can with a signed Applet. Perhaps I can look into hosting it, but I am skeptical about it since running third-party processes on the machine is dubious.

But I am willing to accommodate anyone that wishes it. Just need to talk to me in order to find a solution that works.

Just to clarify, I assume the total size of the entire project (including server parts) must not exceed 4KB, the only exception being jnlp files or applet tags on the condition that those don't inject any data or logic into the game.

Just to clarify, I assume the total size of the entire project (including server parts) must not exceed 4KB, the only exception being jnlp files or applet tags on the condition that those don't inject any data or logic into the game.

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