Quick 2D Overview

Before getting deeper into the concepts behind using Java for 2D games, a quick overview is in order. Each 2D game uses images that it draws to the screen. Given that the display and the images are the two major components of a 2D game from a graphical view, a general overview should get everyone on the same page. For most readers, this will be a quick review.

Display Overview

The display in 2D games is ordered in an inverted coordinate system with the starting point of the grid being set to the upper-left corner.

image from book
Figure 3.1: The 2D coordinate system.

The screen is composed of picture elements (pixels) that store a color value used to display images and background during the game. A screen has the additional properties of height, width, and bit depth. The bit depth indicates how much memory is used to store each pixel. Common depths are 8, 16, and 32 bits per pixel. The amount of memory needed to store any image or background can be determined by multiplying the height, width, and bit depth. The combined attributes are referred to as the screen’s resolution. Some particularly high resolutions require megabytes of memory to store and can affect performance during the execution of the game.

Each time a frame is ready to be drawn, the computer renders it to the screen. To understand how to get smooth animation with no artifacts, it is important to understand a little bit about how the computer draws images to the monitor.

Monitors draw the screen image based on the image in video RAM from the upper-left corner to the lower-right corner. As an electron beam moves in a zigzag pattern, as shown in Figure 3.2, the dark lines are the beam drawing to the screen and the lighter lines are the beam moving back to the left side of the screen to draw the next raster line. The movement from the right side back to the left side is called the horizontal retrace.

image from book
Figure 3.2: The order in which a monitor displays the screen.

The length of time it takes the monitor to draw a complete frame to the screen is called the refresh rate for the video mode. A refresh rate of 60 Hz means the monitor is redrawing the screen 60 times per second. Generally speaking, higher refresh rates are better, but not always, as will be seen later. When the electron beam reaches the lower-right corner of the screen, it moves back to the upper-left corner to begin drawing a new frame.

Image Overview

The ships, bullets, and enemies that are drawn in a starship combat game are classified as images. Much like screens, each image has a height, width, and bit depth. When selecting the resolution for images, be careful to consider the total memory being used when storing images. A number of image file formats are supported on the Java platform. Some of the more common ones are .gif and .png. Review the Java documentation to find other supported formats.

When images are linked to Actor classes, they become sprites. Sprites contain the x- and y-coordinates for the location where the image will be drawn. When the time to render comes, the coordinates are retrieved from the sprite and copied into the screen memory. This topic will be discussed more fully later in the chapter.

Screen Modes

Games that are built using applets and AWT windows are limited because they are rendered the same basic way as GUI components for any typical application. This methodology is less consistent and less useful for applications that require performance. Games that are turn-based or have infrequent updates can be built using the standard AWT or Swing tools presented without issue. Puzzle and card games are perfect for this structure, but to get performance, developers need full control over the screen memory.

The Java 2 SDK 1.4 introduced an exciting new feature of special interest to Java game developers in the form of the full-screen exclusive mode API. This new feature allows developers to create games that can take control of the entire screen memory. Until full-screen mode was introduced, developers were constrained to a small section of the screen in a window or perhaps an applet in a Web browser. It was possible to create a window and maximize it so the entire screen would be encompassed. Such presentations retained the ugly window decorations such as the title bar and system buttons. There aren’t many triple-A game titles on the market that use the operating system’s default window decorations as part of the interface.

Another issue was the inability to change the screen resolution to match the desired resolution for games. If a game is designed that needs a display area of only 320 pixels by 200 pixels at a bit depth of 16 bits per pixel (320 x 200 x 16 bpp) and the only choice is a window, then there are some real problems to face. What if the person playing the game has the desktop display set to 1024 x 768 x 8 bpp? The game is going to show up as a tiny window on the display and may be hard to see, making it impossible to play. The opposite situation causes even more trouble—if the game needs a display area of 1024 x 768 and the player has the display set to a lower resolution, the player won’t be able to see the entire window on screen.

The second problem is the display color depth. If a game is to use a color depth of 16 bpp but the user has the display set to 8 bpp, the graphics that took months to render at 16 bpp will look horrible. The system has to dither the colors because the user’s display has only 256 colors available for the game to use, causing a frustrating loss of quality.

Thankfully, these issues have been solved primarily through the use of the full-screen API. The majority of this chapter will use the full-screen techniques to render 2D images to the screen.

The Full-Screen API

The full screen API provides direct access to the screen memory to speed rendering for applications that need this performance. Most games want access to the direct memory so that they are not burdened with other events or delays that might cause slowdowns in the game’s execution. This section discusses at length how to use the full-screen API to render.

The GraphicsEnvironment Class

The first step required to set up the desired display for a game is to understand what video resolutions the computer on which the game is running is capable of. For instance, the game may be set to run on a display resolution higher than the computer’s video card is capable of using. The GraphicsEnvironment class can determine what modes are available. This class provides access to the collection of GraphicsDevice objects available on the computer. The GraphicsDevice class is described a bit later.

To create an instance of the GraphicsEnvironment class, do the following:

GraphicsEnvironment gfxEnv =GraphicsEnvironment.getLocalGraphicsEnvironment();

Now the GraphicsEnvironment object can be queried as to what devices are available for the game to use.

The GraphicsDevice Class

A GraphicsDevice object can describe many devices types, such as display screens, printers, and image buffers. It is key to know what screen devices are available. Use the GraphicsEnvironment object obtained in the previous code to request a list of the display devices.

GraphicsDevice[] screenDevList = gfxEnv.getScreenDevices();

The getScreenDevices method returns an array of GraphicsDevice objects that describe display screens on the system. On a computer with a single display, this array will contain only a single element; however, it is becoming more common for computers to have multiple display screens. If the game will use only the default display screen, the getDefaultScreenDevice() method can be used.

GraphicsDevice defaultDevice = gfxEnv.getDefaultScreenDevice(); 

The rest of this chapter assumes the use of only the default display screen device.

The DisplayMode Class

The next step is to request the capabilities of the display device. The DisplayMode class contains the information for the bit depth, width, height, and refresh rate of a GraphicsDevice object for a given video mode. It may become necessary to adjust a game to the capabilities of the current computer. To do this, the display modes available are needed for the current display device. Use the getDisplayModes() method of the GraphicsDevice object.

DisplayMode[] displayModes           = defaultScreenDevice.getDisplayModes();

This method returns an array of the display modes available for the specified display device, in this case, the default display.



Practical Java Game Programming
Practical Java Game Programming (Charles River Media Game Development)
ISBN: 1584503262
EAN: 2147483647
Year: 2003
Pages: 171

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net