![[WormChase App PIC]](winWorm.jpg)
Chapter 3. Worms in Windows and AppletsIn this chapter, we test the threaded animation loop of chapter 1 inside a windowed application and an applet. To simplify comparisons between the approaches, the programs are all variants of the same WormChase game. In the next chapter, we continue the comparisons, concentrating on several kinds of full-screen applications.
![[WormChase Applet PIC]](applWorm.jpg)
The top image on the right shows the windowed WormChase application,
and the image below it is the applet version.
The main drawback of the animation loop of chapter 1 is the need to install Java 3D so that its timer is available. Consequently, two versions of the windowed WormChase application are investigated here, one using the Java 3D timer, the other using the System timer. A comparison of the two will show when the Java 3D timer is beneficial.
All the WormChase versions in this chapter, and the next, use the same game-specific classes. They also employ a very similar WormPanel class, which corresponds to the GamePanel animation class of Chapter 2.
The main differences between the programs lie in their top-level classes. For example, in this chapter, the windowed applications uses a subclass of JFrame while the applet utilizes JApplet. This requires changes to how game pausing and resumption are triggered, and the way of specifying the required frames per second (FPS).
Testing is done via the gathering of statistics using a version of the reportStats() method detailed in Chapter 2. The main change is that an average updates per second (UPS) is calculated alongside the average FPS.
The overall aim of the testing is to see if the animation loop can deliver 80-85 FPS. Failing this, the programs should produce 80-85 updates/second without an excessive number of frames being skipped.