|
|
 |
 |  | | | | |  | |||
 | ||||||
          |  |  | ||||
|
Games on the Run: BREW and J2ME
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.
________________________________________________________
|
|||||||||||||||||||||||||||||||||||||||||||
|
|
Resource
Guide 
