| << Chapter < Page | Chapter >> Page > |
When we see that the light has turned green, we reengage the transmission if necessary, gently press the gas pedal, cause the motor to speed up, and drivethrough the intersection at a safe and reasonable speed.
Analogy for a polled program
I like to think of a polled program as being somewhat analogous to a car in which the gas pedal is strapped to the floor causing the motor to run at maximum rpm allthe time.
In such a car, the only way to stop at a stop light would be to disengage the clutch and press the brake pedal. While the light is red, themotor would be consuming fuel at a high rate.
When the light turns green, we would reengage the clutch, speed through the intersection, and hope that wedon't receive a traffic ticket.
Event-driven versus polled programs
Event-driven programs tend to idle when they have nothing to do, thus conserving computer resources. Polled programs run at full speed all of thetime, thus consuming maximum computer resources.
Game and simulation programs, (this one included) , tend to be written as polled programs. Most other modern programs tend to be written asevent-driven programs. However, you can probably write any program using either scenario, or perhaps a combination of the two.
Slick2D supports both scenarios
With regard to input, Slick2D supports both the polled and the event-driven scenarios.
Probably most user input in a Slick2D game or simulation program should be programmed using the polled scenario. However, if the user taps a keywhile the program is in the render method, the program might not recognize that the key has been tapped. If that tap is critical to theoperation of the program, it might be wise to also employ the event-driven scenario to detect such critical events.
The program that I will discuss in this module is written using only the polled approach to user input. I have published numerous online tutorialsthat explain the use of the event-driven approach that you can find with a Google search.
Keyboard, mouse, and controller
The Slick2D Input class supports input from the keyboard, the mouse, or from a game controller. I will discuss only keyboard and mouse input in this module.
Much of this program is identical or very similar to the program named Slick0150a that I explained in the earlier module titled A first look at sprite motion, collision detection, and timing control . I will explain only the code that is new and different in this module.
Will discuss in fragments
A complete listing of this program is provided in Listing 5 . Most of the code that is new and different is contained in the update method, which begins in Listing 1 .
| Listing 1 . Beginning of the update method. |
|---|
public void update(GameContainer gc, int delta)
throws SlickException{//Get a reference to the Input object.Input input = gc.getInput();//Control horizontal bug position by pressing the
// arrow keys or pressing the left and right mouse// buttons.
if(input.isKeyDown(Input.KEY_RIGHT) ||input.isMouseButtonDown(Input.MOUSE_RIGHT_BUTTON)){
bugX += xStep;}//end ifif(input.isKeyDown(Input.KEY_LEFT) ||
input.isMouseButtonDown(Input.MOUSE_LEFT_BUTTON)){bugX -= xStep;
}//end if |
Notification Switch
Would you like to follow the 'Anatomy of a game engine' conversation and receive update notifications?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|