The other thread with applet templates is a bit of a mess, and there doesn't seem to be any consensus on which ones work. Does anybody have a template that seems to work well? I could always use what I've used before, but since one person couldn't start two of my applets last year, well... I'd very much appreciate a nice, reasonably stable template.

The only other significant improvement worth suggesting would be to use an [Volatile]Image obtained from Component#create[Volatile]Image(width,height), rather than the BufferedImage - but obviously this is not useful for those doing any per-pixel rendering.

this is a true mess, it runs an anonymous Thread "open in the sky" where it couldn't be checked for a termination, an aborting, ... in shorter words with no control over it.A correct impl. would handle native lnstallation and loading, with control over start-stop behaviours, window focus and a caching system.an applet is implemented through init-destroy and start-stop methods. So this template should define ignition AND shutdown otherwise anyone terminating the applet into a middle-aged browser would see its system crushing down out of memory and busy... I like the one from LWJGL or appletLoader from JOGL which truely provide a powerful interface to such complex applet management with high-valueable capabilities.

this is a true mess, it runs an anonymous Thread "open in the sky" where it couldn't be checked for a termination, an aborting, ... in shorter words with no control over it.A correct impl. would handle native lnstallation and loading, with control over start-stop behaviours, window focus and a caching system.

It has an isActive() check.

Groboclown: Not including the enableEvents may not work on non Sun JVMs.

If anyone is wanting to add music to their applet, here's the template that I use for that. I've tested this on Linux, Mac, and Windows; it seems to correctly start and stop the audio, or ignore audio playback if no audio can be detected. Of course, the logic for generating sound is an exercise left to the user.

// Set the volume. Necessary on some platforms// Note that you may want to save this volume control// in a class variable if you want to allow the user to// control the volumeFloatControlvolume = (FloatControl) this.o.getControl(FloatControl.Type.MASTER_GAIN);volume.setValue(volume.getMaximum());this.o.start(); } catch (Exceptione) {// Exception - sound could not be initializedthis.t = 1; }newThread(this).start(); }

publicvoidrun() {if (this.t == 0) {// we're in the music playing threadthis.t = 1;// start the game threadnewThread(this).start();

// cut-n-paste logic from above, with the exception of this shut-down block,// which now becomes:if (!isActive()) {this.o.stop();this.o.close();this.o = null;return; } }}

Alternatively, you can eliminate the launching of the music thread and use the SourceDataLine.write as the timer for waiting for the next frame (I did this in a not-so-successful DDR-style game), but then you can run into complicated issues around buffer underruns, which are difficult to deal with in a platform independent way.

One of the rules is "The Applet may not cause "leaks" in the browser, resulting in browser instability.". I remember there was some brief discussion on this a few weeks ago, however I can't see any code in any of the templates that handles this.

How is this generally handled? Main reason I ask, is in my game after a few browser refreshes the game becomes choppy/slow. I guess the applet is not cleaning up my many BufferedImage objects. Last years entry suffered from a similar problem.

One of the rules is "The Applet may not cause "leaks" in the browser, resulting in browser instability.". I remember there was some brief discussion on this a few weeks ago, however I can't see any code in any of the templates that handles this.

IIRC the main point here was that your main loop should exit and your thread finish when the user moves away from the page.

What I meant is most of the templates I have seen have a start()/init() to start the main Thread and a run() method. Do we not need a destoy() method too (to stop thread) or is this handled automatically?

What I meant is most of the templates I have seen have a start()/init() to start the main Thread and a run() method. Do we not need a destoy() method too (to stop thread) or is this handled automatically?

If the thread terminates when isActive() goes false, then everything closes down cleanly when the player leaves the page, so we can omit destroy().

I've had some problems with Thread.yield-loop on some systems. It makes the CPU go to 100% which makes the applets input really slow. It works much better for me with an ordinary Thread.sleep(10) construct. The systems I've had problems with were all Ubuntu 9.10 x64 with Java 1.6.0u16.

I didn't use this on either of my entries because I didn't realize that it's smaller than the method I was using until too late, but here's a template that maintains a relatively steady frame rate and goes easier on your CPU.

If you tried that, you'd find it wouldn't work. For a reason called the Java Event Dispatching Thread (EDT). The loop in the run method would block any user input, drawing, etc, that the EDT needs to do.

Does anyone have a good method for passing mouse input to the main function?

For key input there's the giant array of booleans that we al know and love, but passing mouse events over is hard.

What I've been doing is maintaining a LinkedList of Events and using it as a queue. HandleEvent adds them, your input loop does while(!events.isEmpty()) {Event e = events.removeFirst(); [Input Code]}

That requires you to wrap your entire event handler in an exception handler though, or you'll get concurrent modification issues that don't make any sense. On the bright side, wrapping something in an exception handler is free if you're doing anything else that requires exception handling, such as the Thread.sleep() in my version of the template.

But requiring a LinkedList is kinda crappy. You could also do it with an array and an index, which might be smaller, but I haven't checked.

I detect mouse presses and releases and write them into an boolean array (dimension needs to be 5 iirc). I also read the current mouse position and store that in mouseX and mouseY. Bear in mind that other mouse events may update mouseX & mouseY. Thus it works very much like the keyboard boolean array. To action a mouse click, the main loop does something like:

1 2 3 4 5

if (mouse[1]) { // 1 is left buttonmouse[1] = false; // leave out if you want to do this repeatedly while the mouse button is down// do something with mouseX and mouseY// the assumption is the main loop runs faster than the user can click the mouse buttons}

Mouse drag events are not supported, but could be faked in the main game loop by maintaining a second array of mouse button states and copying current state into last state on every loop.

Incidentally I only have one event handler which does both keyboard and mouse.

For the current versions of Mac Java, the run() method needs to include a wait at the beginning to ensure that the applet is ready before running:public void run() { while (! isActive()) { // Wait technique, such as Thread.yield() or Thread.sleep() } // rest of the code}

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