Working with Images
This article will focus on how to use images in MIDlets, specifically as it relates to game programming. We will look at how to include image files in your JAR file, creating Image objects from resources, support for transparency in MIDP, as well as usage of the Graphics.drawImage() method.
MIDP implementations are only required to support a single image format, PNG or Portable Network Graphics, so any graphics you include with your application should be in this format. The PNG format is extremely versatile; it supports transparency, loss-less compression, a wide variety of color-depths, and is free of pesky licensing issues. All of these reasons make it an excellent format for Java ME development.
One of the easiest ways to include image files as resources is to simply place them in a subfolder under the “src” folder in your NetBeans project. By default, any file under the “src” folder that is not a .java file will be included in your JAR. In your application code, you will use the relative path to your image file from the “src” folder to load the resource. For example, the following code will create an Image object out of an image resource I’ve included in my JAR file:
Image spriteImage = Image.createImage("/com/dbarnes/Demo/sprite.png");
MIDP supports the drawing of images via the Graphics.drawImage() method. The following is an example call to the Graphics.drawImage() method:
g.drawImage(spriteImage,100,100,Graphics.LEFT | Graphics.TOP);
The first parameter is the Image object you wish to draw. The second and third parameters are the X and Y coordinates, respectively. The last parameter is the anchor point. The anchor point describes where the image should be drawn relative to the supplied coordinates. In the example above, the supplied coordinates represent the top and left point of where the image should be drawn. In another example, the following code would center the image at the same coordinates:
g.drawImage(spriteImage,100,100,Graphics.HCENTER | Graphics.VCENTER);
Earlier, I mentioned that the PNG format supports transparency. For game developers, this feature is important if you want to move sprites over a background, or allow sprites to overlap. Support for proper rendering of transparency (or alpha channel) is optional, according to the MIDP 1.0 Specification:
All color types are supported, although the appearance of the image will be dependent on the capabilities of the device’s screen. Color types that include alpha channel data are supported; however, the implementation may ignore all alpha channel information and treat all pixels as opaque.
In practice, the vast majority of MIDP 1.0 devices do in fact support fully transparent pixels. For example, my Sanyo PM-8200, which is a couple of years old, handles it correctly. However, I would not recommend depending on alpha blending (i.e. partial transparency) support, unless you are specifically targeting a device that you know supports this feature.
The MIDP 2.0 specification is a little more helpful. In MIDP 2.0, every implementation must render fully transparent pixels. However, rendering of alpha blending is still optional. From the MIDP 2.0 specification:
Implementations must support storage, processing, and rendering of fully opaque pixels and fully transparent pixels in immutable images. … The required treatment of semitransparent pixel data depends upon whether the implementation supports alpha blending at rendering time. If the implementation supports alpha blending, a semitransparent pixel in the source data must result in a semitransparent pixel in the new image. … If an implementation does not support alpha blending, any semitransparent pixels in the source data must be replaced with fully transparent pixels in the new image
Also note that mutable images are always fully opaque. This is explicitly laid out as required behavior in the MIDP 2.0 specification, and you can safely assume that MIDP 1.0 implementations won’t support it either. From the MIDP 2.0 specification:
Every pixel within a mutable image is always fully opaque.
Therefore, don’t try to break apart an image with transparent pixels into multiple images at run time, because the alpha channel data will not be preserved in the resulting image objects. If you have a set of sprite images, for example, you’ll want to store each frame as a seperate image file, rather than combining them into one.
Bookmark this article: del.icio.us Digg Furl Reddit blogmarks Google Spurl StumbleUpon Technorati Yahoo!