Games on the Run: Comparing J2ME and BREW for Wireless Gaming

Games on mobile phones are nothing new. With NTT DoCoMo's famous iMode service, Japan has gone mobile-game crazy, and even we Stone Age Americans and Europeans have been able to squeeze some entertainment out of primitive text WAP games on our handsets.

A new generation of phones similar to those available in Japan is approaching Europe and the Americas, however, and two major platforms are vying for supremacy over these new handsets. Sun Microsystems' Java 2 Micro Edition (J2ME) and Qualcomm's Binary Runtime Environment for Wireless (BREW) emerged in the last half of 2001 as the leading development environments for mobile gaming.

J2ME

The concept of Java on embedded and small devices has been around for some time. Sun's efforts to provide a slimmed-down Java have taken many forms over the years, including the Java Card API and PersonalJava, a predecessor of sorts to J2ME; the Japanese handsets used with iMode have a customized version of Java developed before Sun could finalize a J2ME standard.

When we speak of J2ME for mobile phones, we really mean J2ME using the Connected Limited Device Configuration (CLDC) and the Mobile Information Device Profile (MIDP) running on top of the K Virtual Machine (KVM). Essentially, the CLDC and MIDP define a set of Java services and language features available for a family of related devices, in this case, mobile phones and other similar technologies. These Java features are implemented on top of a special virtual machine, KVM, designed to be compact and portable to many small devices. Applets developed for MIDP are called MIDlets. This article uses CLDC/MIDP as the platform to compare with Qualcomm's BREW.

The development environment. Most Java IDE vendors have made J2ME/ MIDP support a prominent feature in their new Java development tools. However, Sun's free J2ME Toolkit, available at http://java.sun.com/j2me, has just about everything you need to begin developing a MIDlet.

Among the most useful tools in Sun's J2ME Toolkit is KToolbar, a simple project manager that allows you to load, compile, and run MIDP projects through a clean, elegant GUI. KToolbar also allows you to run your MIDlet in Sun's standard device emulator while seeing debug output and error messages in its main window.

However, the emulator doesn't accurately represent how your code will behave on the real device. First, the emulator doesn't reflect the handset's performance; the emulator's speed depends entirely on your computer's CPU. Your applet will run much slower on actual hardware.

Sun's emulator is also inaccurate in other ways. In the case of Motorola's i85 iDEN handset, simple operations such as the placement of "soft buttons" (tool tips for function buttons on the handset), the behavior and display of GUI components, and basic graphics operations vary wildly from emulator to handset. Even the screen resolution on the emulator is wrong (1113100 on the handset, 105378 on the emulator). In the end, there is no substitute for testing your MIDlet on an actual handset.

So, how do you actually test your MIDlet on a real handset? This is not part of the J2ME Toolkit, but depends on tools provided by the handset manufacturer. In the case of Motorola, their Java Application Loader (JAL) can be found on the iDEN developers' web site, www.motorola.com/iden. This tool allows you to upload .JAR files containing your MIDlets to any of their iDEN handsets.

It's worth mentioning that there is some effect that Java itself has when developing for such small hardware. Java's language conventions make it somewhat difficult to keep code size small. However, using Java also means you generally don't have to worry about strange memory errors and pointer math. Also, the phone OS handles a lot of housekeeping issues for you, such as suspending your applet when an incoming call is received. And MIDP includes handy collection classes such as vectors and hashtables.

Overall, working with the J2ME development environment is a real pleasure. Whether you are using the included KToolbar application or the J2ME editions of any major Java IDE, the process of programming and running MIDlets on hardware is a snap. There are plenty of issues with emulation performance and accuracy, but given the scope of the average mobile game, they are relatively minor. With every release, Sun continues to improve their tools.

Graphics features. The structure of J2ME's graphics system is similar to that of the Java 2 Standard Edition (J2SE). The familiar image and graphics classes are available, but with less functionality. J2ME's native file format is .PNG files, with devices commonly supporting 1- to 8-bit color. Palettes are hard-coded in most handsets, so colors are mapped to the closest match. Pixel transparency, often thought to be impossible with MIDP, is actually an optional part of the MIDP standard, but it's up to the handset manufacturer to support this option.

The usage of the image class allows for off-screen images and, therefore, double buffering. Many handsets have double-buffered displays by default, requiring no additional programming. Although it's possible to create an image from an array of bytes as pixel data, it's impossible to do the opposite. This means pixel-level access to bitmaps is impossible, or at least extremely annoying. Aside from images, the graphics class supports the drawing of different geometric primitives such as boxes and lines as well as text.

GUI. MIDP has done away with the Abstract Windowing Toolkit (AWT) package and replaced it with a package called LCDUI. This package has a set of GUI control classes that are suited for the display of a mobile device.

MIDP's GUI components are grouped into two types: items and screens. Items are GUI controls in the traditional sense: components that can be added to a screen to build an interface. For instance, you can add a text field, a static text string, and a bitmap image to create a screen of several different GUI components. Or, you can use GUI controls that are screens themselves. For example, the list screen is a simple menu of selectable items. Since this takes up the entire screen, you can't combine the control with bitmap images or other custom graphics. The screen system can be rather inflexible, and both types don't allow you to explicitly position controls in pixel coordinates.

Cost. Aside from the cost of a phone, you can begin J2ME development without spending a dime. The prices vary on the different commercial Java IDEs such as Metrowerks' CodeWarrior, Borland's JBuilder, IBM's VisualAge, and others. Sun's J2ME Toolkit also integrates with their own free Forte IDE. The real cost comes with getting your MIDlet tested with each carrier for distribution. These testing runs can often cost thousands of dollars. Considering the myriad of carriers who support or have announced support for J2ME, this can get expensive.

Documentation. J2ME comes with extensive documentation in the form of HTML files. Sun's J2ME Toolkit comes with many sample programs which display features such as GUI controls, graphics, and network communication. There are also a few great books out on the market about J2ME.

Support. There are several developer mailing lists and web boards for most J2ME handset manufacturers. With these resources, you will find company representatives and helpful developers answering questions and posting news on new tools, hardware, and events.

Final comments. J2ME and MIDP are a relative breeze to get started and develop with. MIDP, while basic, gives enough functionality to develop games. However, the Java language makes writing compact code somewhat of a chore.

J2ME handsets vary in performance. Motorola's iDEN hardware is impressive: with a reasonable blitting speed, it's possible to squeak out about 12 frames per second for a simple action game. Unimpressive perhaps, but I have seen competing J2ME handsets with frame rates in the single digits.

Because J2ME is an open standard, each carrier and handset manufacturer is free to add its own custom packages to the default installation. However, porting code between different flavors of J2ME is relatively painless. Each carrier also has its own testing guidelines and billing standards, so you need to set up a billing relationship and get your applet tested by each carrier before being distributing on their network.

BREW

Qualcomm introduced Binary Run-time Environment for Wireless (BREW) technology in early 2001. A C/C++ programming API for a specific kind of hardware platform, BREW is also a certification and distribution model for getting mobile phone applications out to your audience.

Qualcomm invented the CDMA standard, widely used in the United States for digital mobile phone communications. Qualcomm once manufactured CDMA handsets for various carriers, and the internal programming API used to develop software for these phones lives on in the form of BREW.

BREW is more than just a programming API, it also includes a distribution system whereby Qualcomm offers your application to all participating BREW carriers and manages billing services to collect subscription and purchase fees. Once your application goes through the compatibility-testing process with NSTL (an independent testing lab), it's then priced by the developer and made available to BREW carriers, who, having agreed on the pricing and accepted the application, then make it available for users to download. Qualcomm's singular control over the BREW standard may be a real advantage if they can get more carrier support.

The development environment. The BREW API can be used natively with either C or C++. The vast majority of the included sample programs are written in C using a bizarre set of macros which seem to convert C++ object references to C macros masquerading as API function calls. Most of these alleged functions take an interface pointer as the first argument, which would be the implicit pointer in a C++ environment. The C++ examples in the SDK still use these macros instead of the objects themselves. However, at least you can encapsulate your own code in an object structure when using C++.

Getting started in BREW is a bit more complicated than J2ME. You simply can't start coding immediately. After retrieving the SDK from www.qualcomm.com/brew, you must create a project from scratch or edit one of the existing example projects for a framework (BREW 1.1 adds the AppWizard to get started more quickly). Then there are a few other files associated with a BREW application that must be generated. The first is the BREW ClassID (BID) file. This is a simple C source file that contains a definition of a unique ID value that is included as a way to distinguish your application from others. It's possible to create your own BID value by using a number not present in any of the example application BIDs. This will allow you to run your application locally.

For final release and to pass Qualcomm's QA requirements, you need to create a genuine BID using the BREW developer web site. Another file you need to create is the Module Information File (MIF) using BREW's MIF tools. A MIF contains the icon that is seen on the phone's desktop and the application name, copyright information, and permissions. Once you begin testing your application on a BREW handset, you need to generate a test signature file for your phone using the BREW developer's web site.

Programming for the BREW platform is similar to writing most event-driven C/C++ applications. However, BREW has a few guidelines you must follow: no floating point calculations, no static data or global variables, and no standard library calls. Also, keep the paucity of memory on the average BREW device in mind; some common BREW handsets have a mere 500 bytes of stack space.

Much like J2ME, BREW has an emulator. When you compile a BREW project in Visual Studio, you create a Windows DLL. This DLL, as well as the MIF and any associated files, is then run through the emulator. The performance of the emulator is also directly tied to the CPU speed of the host PC; developers basing their application performance on the emulator are in for a shock when they compile a native binary.

To compile a native ARM binary, you must spend $1,500 on the ARM Builder software (which includes the compiler, linker, and assembler components of the ARM BREW developer suite). You will also need a $400 yearly subscription to Verisign's Authentic Document Service, which allows you to generate up to 100 BID and signature files annually. Larger subscription fees give you more files. You must also obtain the BREW AppLoader, which allows you to upload your compiled application to the handset.

Once you set up the ARM compiler, it's time to test on a real phone. In doing so, you will often find your application crashes or responds with some error message that you didn't get in the emulator. Tracking down hardware bugs is a nightmare descent into medieval debugging techniques; there are no tools included for debugging on actual hardware. You can't so much as get a simple printf from the phone to your host PC's console window. I also found some handsets had various bugs in their implementation of BREW: the Kyocera 3035 handset, for example, would not send resume messages after certain events, and other handsets were not properly interpreting arguments to certain function calls. Because Qualcomm is constantly revising BREW, it's unknown whether these bugs will still be present in the versions of BREW carriers decide to use.

Though the development and debugging process on a handset may be the ultimate in pain, the ability to use C/C++ and Visual Studio, not to mention the freedom of programming without Java's sandbox security model, makes BREW a very game programmer friendly environment. One major complaint I have, aside from hardware debugging, is that Qualcomm doesn't currently provide support for the free GNU GCC ARM compiler.

Graphics features. BREW is a bit more gamelike in its graphics functionality. Much like J2ME, BREW provides mechanisms for displaying shapes and vector graphics as well as bitmap images. BREW currently lacks some critical features such as double buffering and low-level pixel access to bitmap data, but Qualcomm promises these and other improved graphics features in future releases.

In version 1.0, only Windows BMPs can be loaded and displayed; 1.1 adds PNG and BREW Compressed Image (BCI) support. BREW contains a high-level image class thatcan load and display BMPs; it can also animate BMPs that include multiple like-sized frames. However, converting a BMP to a device-dependent bitmap and then using BREW's own bitblt function to copy native image blocks to the frame buffer is the fastest method.

BREW supports four color systems: 1-, 2-, 4-, and 8-bit graphics. Both 4-bit and 8-bit graphics provide color, but only through hard-coded palettes. BREW's hard-coded 8-bit palette is rather garish and makes it quite a challenge for most artists to make use of its rather mismatched array of colors. Also, much like J2ME, manipulating the palette is impossible. Special colors are reserved in the 4- and 8-bit palettes for pixel transparency; masking must be used with 1-bit.

GUI. BREW has many of the same GUI components as J2ME. Individual controls can be created in code and positioned in absolute screen coordinates for the ultimate in flexibility, or laid out with the included resource editor.

BREW's ability to position and size GUI controls makes it easy to display graphics and GUI components at the same time. This feature is useful if you want to have a title graphic over the main menu of your game or display a simple menu control on top of the current gameplay screen. However, J2ME's controls are encapsulated in easy-to-use objects, whereas BREW requires a lot of fumbling around with SDK calls and message handlers to get your components to behave.

Cost. BREW's basic tools are free to standard authenticated BREW developers, with additional development costs mentioned previously. You also have to use Microsoft's Visual Studio for compiling on Win32 for use with the emulator. You can also opt to pay for higher levels of developer access which can gain you quicker payment cycles, access to beta SDKs, marketing support from Qualcomm, and various other perks.

Documentation. BREW comes with extensive documentation of the SDK and all related tools in a series of PDF files. BREW also comes with quite a few examples demonstrating most major portions of the API. These include a few complete games as well as examples of GUI, graphics, networking, and sound.

Support. Qualcomm maintains a series of mailing lists and message boards that provide invaluable help from fellow developers and Qualcomm representatives. The mailing list is archived on Qualcomm's own developer web site. Although you can pay for higher developer status that gains you better technical support, Qualcomm provides excellent information through its own free e-mail support service and official representatives on the mailing list.

Final comments. Overall, BREW is a more difficult and expensive platform to develop with than J2ME. Creating a bug-free native binary is a torturous process hindered by a serious lack of tools. Because BREW is currently only used by Verizon Wireless domestically and by a few carriers overseas, handsets are rather uncommon. However, Verizon Wireless is the largest wireless phone carrier in the U.S., and BREW's continuing roll-out in Korea and Japan could be huge.

The BREW API itself has a bit more functionality with graphics and GUI components than J2ME. BREW has great features such as MP3 playback and SMS messaging just waiting for carriers and handset manufacturers to take advantage of them. Because BREW uses C/C++, it's much easier to write compact code using structs and preprocessor tricks. And, with no Java sandbox security model, there's more flexibility in memory and file access.

For game developers, the current BREW hardware is rather unimpressive. The Kyocera 3035, the standard monochrome handset, can barely manage two full-screen 1-bit blits per second. The Sharp BREW color handset is also rather slow; however, Qualcomm continually releases revisions of BREW with faster graphics performance.

It's Qualcomm's distribution and billing system, though, that may push BREW over the top. If Qualcomm can convince more carriers to adopt BREW technology (to date, 17 carriers have announced BREW support), then Qualcomm's centralized billing and certification process not only saves publishers money in testing fees, but makes collecting royalties from various carriers much easier.

The Last Word

Based purely on API features, BREW has more options, and the low-level C/C++ access to the phone's features is a more familiar environment to the seasoned game programmer. Additionally, Qualcomm continues to update BREW with new SDK and tool releases at a faster pace than J2ME spec revisions.

As a development environment, J2ME is far easier to get started with and much simpler to implement than BREW, but J2ME has been around far longer than BREW. This year will be critical for BREW - if Qualcomm can sign more carriers, produce more powerful handsets, and refine the toolset, it will be a major rival to Sun's early lead in mobile application development platforms.

________________________________________________________