//mobile and embedded /
In this article, I explain the details of
the GameCanvas class, because that is
the only class we use for our example
code. For more details on gaming in
general and on the other classes, refer to
my gaming basics article.
The GameCanvas Class
The Java ME API recognizes that a lot of
MIDlets will be game-centric and, therefore, it provides the GameCanvas class.
This class does everything that the normal Canvas class does, but it is extended
to provide game-specific attributes,
such as an offscreen graphics buffer and
the ability to query key status.
The need for an offscreen buffer. Why is
having an offscreen buffer important?
Because it is an implementation of the
double-buffering philosophy that is
used to minimize flickering while rendering images in a game on the graphics display. If there were no offscreen
buffer, the game would suffer from flicker issues, which would make it difficult
to play the game.
When displaying content
on a device’s screen, the
CPU process that is required
for drawing the screen is
usually intensive. Hence,
if the drawing operation is
done very quickly, the CPU
lags. This lag produces a
To minimize this flicker,
the drawing operation is
done in an offscreen buffer.
This buffer is in memory,
and it is separate from the
onscreen buffer. Once the drawing to
this offscreen buffer is completed, this
buffer can simply be copied across to the
actual onscreen buffer. The copy opera-
tion is not as expensive as the direct
rendering operation; hence, the load on
the CPU is not as intense. This process
minimizes the flicker that might be pro-
duced as the CPU completes the copy.
Offscreen buffer in GameCanvas. By
providing an automatic offscreen buf-
fer, the GameCanvas class minimizes the
work that is required by the developer
to maintain this buffer. This buffer is
the same size as the device’s display
area. The area that should be copied
across can be limited so that only parts
of the actual screen are modified. This
process of copying from the offscreen
buffer to the main screen is usually
called flushing. Flushing is implement-
ed in the GameCanvas class by using the
flushGraphics() method. Flushing doesn’t
clean this offscreen buffer; it simply
copies the contents of the buffer to
the device screen. Therefore, it is your
responsibility to clean this
buffer before starting to do
another rendering opera-
tion; otherwise, the new
rendering operation will
mix with or override the
game confirms that a current location for Player 1 is present and then
sends a request to the server to find
players around that location.
4. The server returns a list of players,
along with some unique identifiers.
5. Player 1 selects a fellow player and
requests that the server start the
game with the selected player.
6. Once Player 1 has requested that
a game with a selected player be
started, the game should notify the
central server and initiate the load-
ing of the game on Player 2’s device.
7. After the initial handshake, Player 1’s
screen should show the ball in the
bottom middle of the screen.
8. Then Player 1 can turn his phone left
or right to move the ball.
9. Behind the scenes, the game should
engage the tilt accelerometer and
gather data from it.
10. If Player 1 is tilting the phone left
along the y axis, the ball should
move left in the x axis (relative to
its position on the phone screen).
Similarly, if Player 1 tilts the phone
right along the y axis, the ball should
move right in the x axis (relative to
its position on the phone screen).
11. Once the ball reaches the boundary
conditions of 0 or screen width, the
server should be notified, and the
waiting Player 2’s screen should
12. If Player 2 is at the same location
and has tilted the phone at the same
tilt, she should be able to “catch”
the ball. The server should indicate
success or failure accordingly.
JAVA IN ACTION
To help you conceptualize the Mobile
Sensor API use of this game, let’s think
of the workflow for getting this game
started. Writing down the workflow of
the game should help us design and
1. Player 1 starts the game, and the
game automatically searches for
the current location in terms of GPS
coordinates. If the location is not
available, the phone displays a message and the player cannot play.
2. Once the location is found using the
specified criteria, the game notifies
the server about the coordinates.
The server registers the coordinates
using the phone’s International
Mobile Equipment Identity (IMEI)
number, latitude, and longitude
(and, optionally, the name of Player 1
3. When Player 1 is ready to play a game,
Player 1 presses the Find button. The
become de rigueur,
there has been an
to include location-
based features in
gaming as well.