Porting J2ME games to Flash Lite

Differences in Porting Flash Lite 2.0 and MIDP 2.0

When porting a game from J2ME to Flash Lite, you may also encounter differences between the two technologies, which can add some complications to the process. The differences and issues you may encounter are outlined below.

Vector verses raster

The biggest difference between the two platforms is the format of graphics supported by both these technologies. While J2ME supports only raster graphics, Flash Lite supports a combination of vectors and rasters. It is recommended that developers recreate the graphics for use in the Flash Lite game before porting. Only raster images from the J2ME version of the game can be used, and although they can look acceptable, the graphics will look clearer if they are recreated as vectors.

To illustrate this point, I've included screen shots from two versions of the same game. The J2ME game uses raster graphics, which are legible but look faded and blurry (see Figure 7).

Figure 7. A screen shot from a J2ME game	Figure 8. A screen shot from a Flash Lite game

The Flash Lite version is definitely enhanced when compared to the J2ME version, because the vector graphics look crisp and bright (see Figure 8).

Garbage collection and heap memory

All Series 60 devices come with a default heap memory of 1.5MB for applications to run smoothly. A Java or Flash developer has to optimize the code to make it device friendly, while keeping this heap memory in mind.

One characteristic that makes J2ME a programmer-friendly language is the use of automatic memory allocation and de-allocation. When the programmer instantiates a variable, the JVM finds and allocates the memory without the programmer calling a malloc () or new (). Likewise, the JVM de-allocates that memory when the variable is no longer used, or goes out of scope. The process of reclaiming memory is called garbage collection.

In J2ME, a developer can try flushing the memory by using the System.gc () method, but this will only slow down the application performance. Ultimately, it is best for a game developer to let the application handle its own garbage collection.

When developing games using Flash Lite, there currently isn't a method which a developer can use to guess how much of the heap memory is being used. Optimizations are done based on experience and assumptions. However, like Java, Flash also has its own garbage collection. According to the Flash Lite documentation, the garbage collection in Flash runs automatically every 60 seconds (or when the memory exceeds 200% of the current memory usage). That all sounds great, but sometimes a Flash application will crash anyway—causing the developer to wonder why.

Playback via the Flash Lite Player compared to the JVM

A Series 60 device comes embedded with the JVM, (also known as KVM) for smaller footprint devices. When a J2ME game is run on a device, it launches in the JVM and uses its underlying APIs to perform.

Conversely, the Flash Lite Player must be installed on the device to play a Flash game. Most of the older Nokia Series 60 Second Edition phones don't support Flash Lite 2.0 (they only support Flash Lite 1.1). The newer Nokia Series 60 Third Edition phones come with the Flash Lite 1.1 player preinstalled, however the latest version of Flash Lite still needs to be installed if it is required.

Comparing vectors on the stage to drawing graphics on the canvas

When developing in J2ME, the game developer has to deal with drawing sprites or images on a canvas. In the code example below, the screen appears to clear by drawing a rectangle the size of the screen and setting its color to white. Then, two more objects are drawn on screen, (a line and a rectangle):

import javax.microedition.lcdui.*;

class DrawingDemoCanvas extends Canvas {

  public void paint (Graphics g) {
    g.setGrayScale (255);
    g.fillRect (0, 0, getWidth (), getHeight ());

    g.setGrayScale (0);
    g.drawLine (0, 0, 100, 200);
    g.fillRect (20, 30, 30, 20);
  }
}

Now pretend you are developing the same game in Flash. If you need simple graphics like those used in the code above, you can use the drawing tools in Flash to achieve the same effect during authoring. Using Flash Lite 2.0, you can choose to write code using the Drawing API to achieve this as well. Personally, I feel it is much faster and easier to use the drawing tools, rather than add more lines of code to my script. The drawing tools are a definite advantage to developing games in Flash (see Figure 9).

Figure 9. Simple game graphics can be created using the drawing tools in Flash Lite 2.0. When developing in J2ME, the same graphics must be generated programmatically

Working with fonts

When developing with Flash Lite, it is easy to work with fonts because you have complete control over the design of your content. Text Boxes can be drawn on the stage using the Text tool, and text properties are controlled using the Properties Inspector (see Figure 10).

Figure 10. Using Flash Lite, you can control where you place the text and how the text will be displayed

It is a common misconception that developers should avoid embedding multiple fonts in a game, in order to keep a small file size. In my experience, when your content can have a file size of 300K, it is feasible to use several good pixel fonts for your content.

In contrast to the above, the text in J2ME games must be drawn using the drawstring () method. This method requires you to define four parameters: The character string, the x and y coordinates, and an integer determining the horizontal and vertical alignment of the text.

If you are using a canvas based application you can create the necessary graphics using your own customized fonts, then save the text as an image file along with your other graphics images. You could then theoretically use the customized fonts wherever desired in your game. But it is not quite that simple. If you use customized graphics for your text, you will need to know the coordinates of every character of the image file.

In the next example, a customized font image is displayed on the left side. The right side shows how the characters are displayed on the device (see Figure 11).

Figure 11. The custom font image appears on the left while the right side shows how the device displays the text

Here's how this works. The top-left and bottom-right coordinates of every character from the image are fed into the game program. During run-time the game program reads the string, picks the character from the image and then draws it on the canvas. As you can imagine, this is a very tedious process. These days when I think of using custom fonts, I cannot help but smile and be thankful that I'm using Flash Lite as a mobile development tool.

Where to go from here

In this article I've covered some techniques and considerations for porting J2ME games to the Flash Lite platform. In my personal experience, porting projects always begins by thoroughly reading the Game Design Document. Once I have a complete understanding of the game logic from the previous J2ME development team, I start collecting the useful code snippets (such as conditions, the game AI, etc.), and begin translating the game into ActionScript (using the Flash syntax).

A Flash Lite developer porting a game from J2ME to Flash Lite has some advantages that will make their job easier. The first advantage is that the game assets are already available. Additionally, a Flash Lite developer does not have to spend too much time working on the game logic or designing compelling game visuals. When it comes to porting an existing game, the entire content has already been created. It is a simple matter to reproduce and test the ported game before distributing it.

Expand your knowledge about S60 development by reading the detailed information on the Nokia S60 documentation forum. Also, in-depth articles and tutorials about using Flash Lite are available at the Adobe Mobile & Devices Developer Center. I hope this article has sparked your interest in porting game content. Although porting is easier than developing a brand new game, you'll find the process will be easiest if you invest time in learning about the original development, recreate the game graphics as needed, and define your porting strategies ahead of time—especially if you are porting across different technologies.

Page 5 of 5

Previous Page