WormChase as an Applet

WormChase as an Applet Figure 3-1 shows the WormChase game as an applet and as an application. It has the same GUI interface as the windowed version: a large canvas with two text fields at the bottom used to report the number of boxes added to the scene, and the time. Class diagrams showing the public methods are given in Figure 3-10. A comparison with the diagrams for the windowed version in Figure 3-2 show the classes stay mainly the same. The only substantial change is to replace JFrame by JApplet at the top level. Figure 3-10. Class diagrams for the WormChase applet The code for this version of WormChase is in the directory Worm/WormApplet/. The Worm class is unchanged from the windowed version. The Obstacles class now calls setBoxNumber( ) in WormChaseApplet rather than WormChase. WormPanel reports its termination statistics in a different way, but the animation loop and statistics gathering are unchanged. WormChaseApplet handles pausing, resumption, and termination by tying them to events in the applet life cycle. By comparison, WormChase utilizes Window events. The applet's web page passes the requested frame rate to it as a parameter: <applet code="WormChaseApplet.class" width="500" height="415"> <param name="fps" value="80"> </applet> The WormChaseApplet Class Figure 3-11 shows the class diagram for WormChaseApplet with all its variables and methods. Figure 3-11. WormChaseApplet in detail The applet's init( ) method reads the FPS value from the web page, sets up the GUI, and starts the game: public void init( ) { String str = getParameter("fps"); int fps = (str != null) ? Integer.parseInt(str) : DEFAULT_FPS; long period = (long) 1000.0/fps; System.out.println("fps: " + fps + "; period: "+period+" ms"); makeGUI(period); wp.startGame( ); } makeGUI( ) is the same as the one in the JFrame version. The call to startGame( ) replaces the use of addNotify( ) in the JPanel. The applet life-cycle methodsstart( ), stop( ), and destroy( )contain calls to WormPanel to resume, pause, and terminate the game: public void start( ) { wp.resumeGame( ); } public void stop( ) { wp.pauseGame( ); } public void destroy( ) { wp.stopGame( ); } A browser calls destroy( ) prior to deleting the web page (and its applet) or perhaps as the browser itself is closed. The browser will wait for the destroy( ) call to return before exiting. The WormPanel Class The only major change to WormPanel is how printStats( ) is called. The stopGame( ) method is modified to call finishOff( ), which calls printStats( ): public void stopGame( ) { running = false; finishOff( ); // new bit, different from the application } private void finishOff( ) { if (!finishedOff) { finishedOff = true; printStats( ); } } // end of finishedOff( ) finishOff( ) checks a global finishedOff Boolean to decide whether to report the statistics. finishedOff starts with the value false. finishOff( ) is called at the end of run( ) as the animation loop finishes. The first call to finishOff( ) will pass the if test, set the finishedOff flag to true, and print the data. The flag will then prevent a second call from repeating the output. A race condition could occur, with two simultaneous calls to finishOff( ) getting past the if test at the same time, but it's not serious or likely, so I ignore it. In the windowed application, stopGame( ) only sets running to false before returning, with no call to finishOff( ). The threaded animation loop may then execute for a short time before checking the flag, stopping, and calling printStats( ). This approach is fine in an application where the animation thread will be allowed to finish before the application terminates. Unfortunately, as soon as an applet's destroy( ) method returns, then the applet or the browser can exit. In this case, the animation thread may not have time to reach its printStats( ) call. To ensure the statistics are printed, finishOff( ) is called in the applet's stopGame( ) method. The other call to finishOff( ) at the end of run( ) is a catch-all in case I modify the game so it can terminate the animation loop without passing through stopGame( ). Timing Results The timing results are given in Table 3-3. Table 3-3. Average FPS/UPS for the applet version of WormChase Requested FPS 20 50 80 100 Windows 98 20/20 50/50 82/83 97/100 Windows 2000 20/20 46/50 63/83 61/100 Windows XP 20/20 50/50 83/83 100/100 The poor showing for the frame rate on the Windows 2000 machine is expected, but the applet performs well on more modern hardware.