Application Timing Results

This version of WormChase is a windowed application, with an animation loop driven by the Java 3D timer. Can it support frame rates of 80 to 85 FPS?

I consider the average UPS, which gives an indication of the speed of the game. Table 3-1 shows the FPS and UPS figures for different requested FPS amounts, on different versions of Windows.

Table 3-1. Average FPS/UPSs for the windowed WormChase using the Java 3D timer

Requested FPS	20	50	80	100
Windows 98	20/20	48/50	81/83	96/100
Windows 2000	20/20	43/50	59/83	58/100
Windows XP	20/20	50/50	83/83	100/100

Each test was run three times on a lightly loaded machine, executing for a few minutes.

The numbers are for the machines hosting Windows 98 and XP, but the frame rates on the Windows 2000 machine plateaus at about 60. This behavior is probably due to the extreme age of the machine: a Pentium 2 with a paltry 64 MB of RAM. On a more modern CPU, the frame rates are similar to the XP row of Table 3-1.

A requested frame rate of 80 is changed to 83.333 inside the program, explaining why the 80's column shows numbers close to 83 in most cases. The frame rate is divided into 1,000 using integer division, so that 1000/80 becomes 12. Later, this period value is converted back to a frame rate using doubles, so 1000.0/12 becomes 83.3333.

The Windows 2000 figures show that slow hardware is an issue. The processing power of the machine may not deliver the requested frame rate due to excessive time spent in modifying the game state and rendering. Fortunately, the game play on the Windows 2000 machine does not appear to be slow, since the UPS stay near to the request FPS.

Close to 41 percent of the frames are skipped ([83-59]/83), meaning that almost every second game update is not rendered. Surprisingly, this is not apparent when playing the game. This shows the great benefit of decoupling game updates from rendering, so the update rate can out perform a poor frame rate.

Timing Results Using currentTimeMillis( )

It is interesting to examine the performance of a version of WormChase using System.currentTimeMillis( ) rather than the Java 3D timer.

The WormChase class and its associated main( ) function must be modified to represent the period value in milliseconds rather than nanoseconds. In WormPanel, the calls to J3DTimer.getValue( ) in run( ) and storeStats( ) must be replaced by System.currentTimeMillis( ). The sleep( ) call in run( ) no longer needs to change sleepTime to milliseconds:

     Thread.sleep(sleepTime);  // already in ms

storeStats( ) must be edited to take account of the millisecond units.

The code for this version of WormChase is in Worm/WormPMillis/. The timing results are given in Table 3-2.

Table 3-2. Average FPS/UPSs for the windowed WormChase using the System timer

Requested FPS	20	50	80	100
Windows 98	19/20	43/50	54/83	57/100
Windows 2000	20/20	50/50	57/83	58/100
Windows XP	20/20	50/50	83/83	100/100

The Windows 98 row shows the effect of the System timer's poor resolution: it causes the animation loop to sleep too much at the end of each update and render, leading to a reduction in the realized frame rate. However, the UPS are unaffected, making the game advance quickly.

The Windows 2000 row illustrates the slowness of the host machine. The figures are comparable to the version of WormChase using the Java 3D timer. The Windows XP row shows that the System timer's performance is essentially equivalent to the Java 3D timer. The System timer's resolution on Windows 2000 and XP is 10 to 15 ms (67 to 100 FPS).