| << Chapter < Page | Chapter >> Page > |
Purposely insert a time delay
Everything down to the last two lines of code in Listing 7 is the same as the program named Slick0150a . At that point I inserted code that will cause an additional random timedelay ranging from 0 to 43 milliseconds before the render method returns. I did this to simulate asituation in which the rendering process is very complex and the time to render varies quite a lot from one frame to the next.
A new average frame rate
In this case, the average additional delay time should be about 21.5 msec. This makes it impossible to maintain the target frame rate of 60frames per second or 16.666 milliseconds per frame.
This additional delay should result in an average frame rate of about 46 or 47 frames per second, which is consistent with the screen output shown in Figure 4 .
A wide variation in delta values
Not only does this code result in a reduction in the average frame rate, it also results in a wide variation in the values of delta received by the update method on a frame to frame basis.
As before, the init method calls the setTargetFrameRate method requesting a frame rate of 60 frames per second. This guarantees that the minimum delta that will be receivedby the update method will be in the neighborhood of 16 milliseconds. (The game loop won't be allowed to run any faster than 60 frames per second.)
The last two lines of code in Listing 7 will cause the value of delta to be as large as about 43 milliseconds.
Therefore, the incoming delta values in the update method will vary between about 16 milliseconds and about 43 milliseconds on a totally random basis fromone frame to the next.
Listing 8 shows the code in the update method that is different from the code in the update method for the program named Slick0150b .
| Listing 8 . Beginning of the update method for Slick0150b. |
|---|
public void update(GameContainer gc, int delta)
throws SlickException{//Compute new location for the sprite.
bugX += bugXDirection*xStep*delta*targetFPS/1000.0;bugY += bugYDirection*yStep*delta*targetFPS/1000.0;
//The following code does not correct for variations// in delta. The step size is always the same
// regardless of delta. Enable this code and disable// the two statements above to see the effect.
// bugX += bugXDirection*xStep;// bugY += bugYDirection*yStep; |
Compute new location for the sprite
As before, the method begins by computing a new location for the sprite. However, the code in Listing 8 attempts to maintain a constant overall speed as the bug moves across the gamewindow despite the fact that the value of delta varies quite a bit from one frame to the next.
Vary the step size
In order to accomplish this, the step size is caused to vary in proportion to delta or inverselywith the instantaneous frame rate. Given the earlier estimate that the value of delta can vary from about 16 milliseconds to about 43 milliseconds, the step size can varyfrom about 4 pixels per frame to about 10 pixels per frame. When the value of delta is small, the step size will be small. When the value of delta is large,the step size will be large.
Notification Switch
Would you like to follow the 'Anatomy of a game engine' conversation and receive update notifications?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|