Using the game API function to make a two-dimensional action game

MIDP 2.0 includes an API function to simplify the programming of two-dimensional games. This API function is very simple, including only five classes in the Javax.microedition.lcdui.game package. These five classes provide two key features:

The new Gamecanvas class makes it possible to draw a screen in a game loop and respond to keyboard input without calling the system's paint and input threads.

Powerful and complex layer (layer) API functions can easily and efficiently build complex scenarios.

Mutank Example

Create a game loop using the Gamecanvas class (game loop)

The Gamecanvas class is a canvas class with features that provide a way to redraw and check the status of a device key immediately. These new methods encapsulate all functions (functions) of a game in a loop and are controlled by a single thread. Why is it so appealing? Let's consider how you perform a typical game that uses the canvas class:

public void MicroTankCanvas
extends Canvas
implements Runnable {
public void run() {
while (true) {
// Update the game state.
repaint();
// Delay one time step.
}
}
public void paint(Graphics g) {
// Painting code goes here.
}
protected void keyPressed(int keyCode) {
// Respond to key presses here.
}
}

This is not a beautiful picture. The run () method, which runs in the application thread, refreshes the game each time period. A typical task is to refresh the position of a small ball or flying object, drawing a character or an aircraft animation. Each time through the loop body, the repaint () method is used to refresh the screen. The system sends the key event to keypressed (), which refreshes the game state appropriately.

The problem is that everything is in a different thread, and the game code is easily confusing in three different ways. When the active drawing loop in the run () method calls the repaint () method, there is no way to know exactly when the system calls the paint () method. When the system calls keypressed (), there is no way to know what the other part of the program is doing. If the code in your keypressed () is going to refresh the state of the game, and the paint () method will display the screen at the same time, the screen will continue in a very strange state. If the display screen takes more than a single time period, the animation will look choppy or strange.

The Gamecanvas class allows you to avoid common painting (painting) and key message (key-event) mechanisms, so all game logic can be included in a single loop. First, the Gamecanvas class allows you to access graphics objects directly using the Getgraphics () method. Any representation of the returned Graphics object (rendering) can be achieved through the screen outer buffer (offscreen buffer). You can copy the buffer to the screen with Flushgraphics () until the screen is refreshed before returning. This gives you a better control over how to invoke the Repaint () method. The Repaint () method immediately returns a value so that your application cannot determine when the system will call paint () to refresh the screen.

The Gamecanvas class also contains a method for obtaining the current state of the device key, the so-called polling technology. You can replace the wait system call Keypressed () method by calling the Gamecanvas class's Getkeystates () method to determine immediately which key is pressed.