<< Chapter < Page Chapter >> Page >

Test for collisions on other three sides of game window

Listing 5 tests for collisions between the sprite and the other three sides of the game window and takes appropriate action when acollision occurs. The code in these tests is less complex than in Listing 4 because they don't need to compute the traversalTime .

Listing 5 . Test for collisions on other three sides of game window.
//Continue testing for collisions with the edges. if(bugX<= 0){ bugXDirection = 1.0f;bugX = 0; }//end ifif(bugY+bugHeight>= backgroundHeight){ bugYDirection = -1.0f;bugY = backgroundHeight - bugHeight; }//end ifif(bugY<= 0){ bugYDirection = 1.0f;bugY = 0; }//end if}//end update

The render method

The render method is shown in its entirety in Listing 6 .

Listing 6 . The render method for Slick150a.
public void render(GameContainer gc, Graphics g) throws SlickException{//set the drawing mode to honor transparent pixels g.setDrawMode(g.MODE_NORMAL);//Draw the background to erase the previous picture.background.draw(0,0);//Draw the bug in its new location. bug.draw(bugX,bugY,bugScale);//Display the traversal time computed in the update// method. g.drawString("traversalTime: "+traversalTime,100f,10f); }//end render

There is really nothing new in Listing 6 . Therefore, it shouldn't require an explanation beyond the embedded comments.

Each time this method is called, the location of the sprite will have changed by a few pixels relative to its previous location. Displaying the sprite in anew location each time the picture is drawn produces the impression that the sprite is moving.

A program with a highly variable frame rate - Slick0150b

This program differs from the previous program in that it attempts to maintain a constant overall speed as the bug moves across the game window despite the fact that the instantaneous frame rate varies quite a bit from one frame to the next. Toaccomplish this, the step size is made to vary in proportion to the deltavalue received by the update method, or inversely with the instantaneous frame rate.

A complete listing of the program is provided in Listing 10 near the end of the module. Most of the code in this program is the same as code in the previousprogram, so I will explain only the code that differs between the two.

The screen output for Slick0150b

Figure 4 shows a screen shot of the game window while this program is running. I will have more to say about this output later after I explain some ofdifferences between this program and the program named Slick0150a .

Figure 4 . Screen shot of the program named Slick0150b.
Missing image.

The render method

The significant differences between the two programs occur in the update method and the render method. I will begin with an explanation of the render method, which purposely creates an issue that is resolved by code in the update method.

The render method is shown in its entirety in Listing 7 .

Listing 7 . The render method for Slick150b.
public void render(GameContainer gc, Graphics g) throws SlickException{//set the drawing mode to honor transparent pixels g.setDrawMode(g.MODE_NORMAL);//honors transparency//Draw the background to erase the previous picture. background.draw(0,0);//Draw the bug in its new location. bug.draw(bugX,bugY,bugScale);//Display the traversal time computed in the update // method.g.drawString( "traversalTime: "+traversalTime,100f,10f);//Purposely insert a time delay. int sleepTime = (((byte)random.nextInt()) + 128)/6;gc.sleep(sleepTime); }//end render

Get Jobilize Job Search Mobile App in your pocket Now!

Get it on Google Play Download on the App Store Now




Source:  OpenStax, Anatomy of a game engine. OpenStax CNX. Feb 07, 2013 Download for free at https://legacy.cnx.org/content/col11489/1.13
Google Play and the Google Play logo are trademarks of Google Inc.

Notification Switch

Would you like to follow the 'Anatomy of a game engine' conversation and receive update notifications?

Ask