Does any of them provide for what is needed? End-user browser stability?
Other than a few people with no java installations, I haven’t received a single complaint about left 4k dead not working, and it’s received quite a lot of attention.
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.
public class A extends Applet implements Runnable {
public void start() {
enableEvents(...);
new Thread(this).start();
}
public void run() {
// Initialise
...
while (!isActive()) Thread.yield(); // Optional line to ensure Appletviewer works
Graphics g;
while ((g=getGraphics())==null) Thread.yield(); // Optional line to ensure Webstart works
// g=getGraphics(); // You need this if the previous line is omitted
do {
// Game Loop
...
if (g!=null) { // Catch Null Pointer exceptions (in most cases)
// Draw on screen
...
}
...
} while (isActive());
}
...
}
Question: do you rely on System.currentTimeMillis() or System.nanoTime() to cap the FPS in the rendering loop? I guess so otherwise you’d bust the 4k limit using a third party lib.
BTW, thanks for the code, it will save precious time about code size optimizations.
This does not use double buffering.
I have updated the skeleton applet I posted on the previous page.
And so it does! Wowzers. I used it for Left 4k Dead 2 which I released a few days ago, and just that change alone gained me some 100+ extra bytes. Amazingsauce!
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.
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?
[quote=“pjt33,post:68,topic:34414”]
Sounds great =D
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.
3 months. 1st of Dec - 28th of Feb.
Are the rules going to be different to last year?
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.
The main reason I think was because Java 1.4 does not support pack200. Guess 1.4 is old enough now to set the minimum contest requirement to Java 1.5 (5.0).
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.
That’s not how the documentation paints it:
http://java.sun.com/j2se/1.5.0/docs/guide/deployment/deployment-guide/pack200.html
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.