0.5 Slick0150: a first look at sprite motion, collision detection  (Page 3/10)

Fortunately, the value of delta can often be used to give the appearance of running at the target frame rate even though the actual frame rate may be belowthe target. I will show you how to do that in this module.

Discussion and sample code

A program with a relatively constant frame rate - Slick0150a

I will begin by discussing a case with a relatively constant frame rate. The program for this case, Slick0150a , is shown in Listing 9 .

The screen output for Slick0150a

Before getting into the coding details, I will show you some output. Figure 3 shows a screen shot of the game window while the program is running.

Figure 3 . Screen shot of the program named Slick0150a.

The screen shot in Figure 3 caught the ladybug in mid flight. As mentioned earlier, the next time it collides with one of the edges of the gamewindow, it will bounce off and move in the opposite direction like a pool ball striking the cushion on the edge of a pool table.

The FPS output

As you learned in an earlier module, the text in the upper-left corner is the frame rate in frames per second computed and automatically displayed by the gameengine. You will see later that a target frame rate of 60 frames per second was requested by calling the method named setTargetFrameRate and passing 60 as a parameter.

At 60 frames per second, a time interval of 16.6666 milliseconds would be required to complete each frame. It appears that the setTargetFrameRate method truncates this value to an integer value of 16 milliseconds, which represents a framerate of 62.5 frames per second. It also appears that the code that displays the frame rate converts the actual frame rate to an integer for display. Hence you see an FPSvalue of 62 in Figure 3 .

The traversalTime output

The traversalTime output that you see in Figure 3 is computed and displayed by the program that we will examine shortly. This is the time required for the sprite to complete one round tripfrom the right edge to the left edge and back to the right edge.

If you compile and run this program, you will see that the traversalTime value is reasonably stable at around 3015 milliseconds.

The theoretical traversalTime

Although it isn't shown here, a separate output on the command-line window reported the width of the background image to be 414 pixels and the width of thesprite to be 48 pixels. The sprite is never allowed to go outside the boundaries of the game window, so the one-way distance from the left edge to the right edgeis 366 pixels. (This is the distance that the upper-left corner of the sprite travels during the one-way trip.) The round-trip distance is twice that, or 732 pixels.

You will see later that the sprite is caused to move horizontally by four pixels during each frame. At 62 frames per second, this represents a horizontalspeed for the sprite of 248 pixels per second. At that speed, the sprite should complete the round trip in 2952 milliseconds. That is close enough to thetypical reported time of 3015 milliseconds to validate the theoretical considerations.