J2ME: The next major games platform?

Do you think that Java has become a little staid and unexciting? As a language matures and your experience with it grows, does it not naturally become less interesting? Well, that’s what I tend to tell myself.

I have a theory about what really sells a language — that is, for those developers who are lucky enough to choose the paradigm they work in. My theory — completely unscientific, of course — is that developers base their decisions on two simple factors:

1. The coolness factor
2. The “what’s-in-it-for-me” factor — in other words, how many jobs will it generate, what kind of work will I do, what sort of career path does it offer and, most importantly, what is the likely salary?

In Java’s early days, the applet drew developers to the emerging language. When I read about Java in a magazine article in 1996, I was interested, but it was not until I saw my first applet that I became hooked on the idea — the coolness factor clearly at work.

Since then, other client-side Web technologies have grown popular — without completely replacing Java in the browser — and consequently, developers now choose a language for what’s-in-it-for-me reasons. As the demand increases for Java developers, salaries continue to head skyward.

Eventually the coolness factor cooled, as did general excitement for the language, until Java 2 Micro Edition (J2ME) came along.

Smaller is better?

If you believe industry analysts, who sometimes rival movie critics in their accuracy, embedded computer usage will grow by enormous percentages over the next three to five years. Mobile phones and PDAs are just the tip of the iceberg. Home networking, wearable computers, and more hover in our near future. What better platform to power the applications on those new devices than Java?

All the reasons for using Java on the desktop and server apply to smaller machines as well, and the most important reason, of course, is platform independence. With the possible exception of Palm, no single operating system rules the world of embedded devices at the moment, at least not compared to the desktop world. Some argue that portability is not an issue for embedded devices; speed and stability take precedence. While it may not be essential to operating system or hardware manufacturers — who, after all, want more products for their systems than are available for their competitors — I believe portability remains a concern for developers. The more market you have, the more money you can make.

The killer app

So what will be the first killer applications for cutting-edge mobile phones that sport color screens and broadband Internet connectivity? The answer: games. What sort of games? Answering that question exposes a slight inadequacy with J2ME: as opposed to the original Java killer app, the applet, it’s difficult to demonstrate J2ME’s potential and thus difficult to demonstrate J2ME’s coolness.

To see an applet in action, you just launch a Web browser and point it in the right direction. But because of the lack of real hardware available for developers to experiment with, demonstrating a MIDlet (an application written for devices supporting the Mobile Information Device Profile) on a mobile phone is a difficult proposition, particularly outside the United States and Japan. Worse yet, a mobile phone CPU may run at less than 20 MHz, a Palm Pilot at 16 MHz to 20 MHz, and a high-powered color PDA at 200 MHz. Mobile computers such as Cell Computing’s Plug-N-Run Modules can run at 500 MHz and over.

You could feasibly use all of those devices to deploy J2ME applications. But which processor speed do you develop for? Which market is likely to be the largest? Some of those devices are popular now, but which will be popular in the next few years?

The proliferation of emerging devices and those devices currently in development exacerbate the problem even further. And don’t forget the growing number of companies developing Java on the metal — running Java bytecode directly on the CPU — which promises an increase in speed and perhaps entices more consumer electronics manufacturers and their products into this ever-expanding device market. ARM is one such company that has recently announced Java support on its processors (see Resources for more information).

Even putting aside those technical considerations, a final — and arguably fundamental — complication for the moment is that you cannot describe the technology as approachable with respect to the nontechnical public at large. That is, until John Q. Public is able to wander down to the local electronics store, pick up a mobile phone or PDA with Java already built in, and try out the technology without having to download or install anything.

Ultimately, if you have faith that those issues will sort themselves out as the technology matures — look at the features and performance improvements of the standard JVM to realize that it will take a while to iron out any wrinkles in J2ME — your choice of game type will depend on what approximate processor speed you decide on. For example, if you target mobile phones, the games will be simpler, as will the graphics. However, those games that will really make an impact will be graphic intensive. Imagine a massive multiplayer role-playing game (RPG) with basic 3-D graphics, running on a PDA. While it is not exactly the most original idea, it is a suitable example and a good starting point for this discussion. The big question: Can you build that type of game with Java?

MIDP or PersonalJava: The battle of the midgets

The two major players in J2ME at the moment are the Mobile Information Device Profile (MIDP) and PersonalJava. Does one or both of these provide the facilities and performance required to develop a 3-D game?

The MIDP is at the bottom end of the ladder: a redesigned version of Java intended to run on the simplest devices. Because of its limited processor speed, limited memory, and low resolution, you are restricted in what you can do with the MIDP. 3-D is entirely possible on MIDP devices; for example, vector graphics can use the standard Java graphics primitives, such as line and polygon drawing, to produce 3-D shapes. However, the lack of ability to directly blit — copy raw pixel data — to the screen from a pixel buffer, for example, makes life rather difficult for anything more advanced, such as particle effects or simple texture-mapping (see sidebar, How Not to Blit).

So if not MIDP, what about PersonalJava? PersonalJava has been around much longer than MIDP and supports a larger subset of the standard JDK, which means that working with raw pixel data is quite simple. In addition, specifications have been accepted for development in the Java Community Process that more tightly integrate PersonalJava into the J2ME framework: the PDA Profile for J2ME and the Personal Profile Specification.

The PDA Profile describes “…a standard platform for small, resource-limited, handheld mobile information devices…” (from JSR #000075 PDA Profile for J2ME). In hardware terms, that means a memory capacity from 512 KB to 16 MB, and “…a resolution of at least 20,000 pixels” (see Resources for more information).

The Personal Profile defines its targets as having a minimum of 2.5 MB ROM, 1 MB of RAM, network connectivity, and the ability to run applets. In addition, it “will also provide a smooth transition for those utilizing already-existing versions of PersonalJava technology” (from JSR #000062 Personal Profile Specification). Once products emerge based on those two profiles, PersonalJava as we know it now will begin to move into the mainstream of J2ME.

Moore’s Law and the game development life cycle

One of the more quotable theories in the information age, Moore’s Law states that processor power will almost double every 18 months. At its present pace, the computer industry exceeds that estimate.

Currently, the low end of the processor scale for PDAs averages around 20 MHz, like the Palm IIIc. The higher end would compare to the soon-to-be-released Yopy — with a Linux-based operating system — which has a 206 MHz processor, or Compaq’s iPaq, which also has a 206 MHz processor. Thus, according to Moore’s Law, you could expect high-end PDAs on the market in 18 months to have a processor speed of around 400 MHz, which is in line with the laptops and even desktops that many people currently use.

With large development teams, it can take anywhere from 12 to 36 months to develop PC and console games. Some of the more complicated games are pushing that upper end of the scale; however, you would expect a game for a PDA or mobile device to be at the bottom end.

Possibly then, a good rule-of-thumb in constructing a J2ME game would be to aim for the processor speed expected at the end of the estimated development time.

My imaginary friends

Back to the original question of feasibility. In the tradition of 8-year-olds all over the world, I have invented an imaginary team of experienced Java developers. I estimate that my team can complete development of my revolutionary multiplayer 3-D RPG in about 15 months, with the target platform being high-end PDAs. Being a tad conservative, I am unwilling to take Moore’s Law entirely at face value, so I’ll anticipate that by development’s end, processors between 280 MHz and 320 MHz will be available. Luckily, despite the absence of devices on which to test, it is still easy enough to buy laptops with approximately that range of processor power; my team can test on those. In addition, an iPaq running PersonalJava will hopefully provide an adequate platform for compatibility and below-baseline performance tests.

The screen real estate available on PDAs differs from machine to machine, so the game engine will have to be scalable depending on processor performance and screen resolution. A good minimum size would be equivalent to Nintendo’s Gameboy Advance, which has a 240-by-160 pixel display.

The next step is to find out whether the intended CPU range, coupled with the minimum display resolution, will be enough to provide a reasonable frame rate for 3-D graphics.

The test

To determine a possible frame rate — without writing a 3-D engine to play with — the simplest test is to calculate how long it takes to dump a random array of pixels to the screen X number of times.

Methodology

Java provides a number of ways to convert raw image bytes to an image. The most common is to use a MemoryImageSource along with a PixelGrabber to obtain the pixels from any image with which you want to start. After that, it is fairly simple to manipulate the bytes and refresh the display for animation.

However, I have found that the most efficient approach is to implement the ImageProducer interface and set the image’s pixels directly. That eliminates one or two steps in the MemoryImageSource option and seems to be about 10 percent to 20 percent faster on average.

For my test, I modified an applet developed as part of the TinyPTC framework (see Resources for more information). The new applet, BlitTest, displays a test pattern and calculates the number of frames per second (fps), based on the amount of time required to deliver 500 frames of animation. (Thanks to the guys at Gaffer.org for allowing me to use their code.)

The following figure is what you will see when running the test applet — what looks roughly like TV static.

The projected frame-rate figure will not directly correlate with the frame rate on the final 3-D engine, which, after all, has not even been written. That is because most 3-D projects probably have a number of loops and inner loops, whereas BlitTest contains only a single loop, but it offers the highest performance available. From there, we can estimate the probable engine performance.

You can try the test applet out here: BlitTest. Please note that this is not a nice applet; there is no Thread.sleep() on the graphics loop, which means it will eat up any available CPU resource. In other words, it will use 100 percent of the processor on some machines. So use it at your own risk.

Results

Running on a high-end machine, such as a dual-processor Pentium III 800 MHz using a JDK 1.1 appletviewer, the test runs in just 1.36 seconds. It provides over 367 frames per second, which is more than enough processor power to do whatever we could want. (Although that test applet is not meant to be a performance benchmark of JVMs, as a matter of interest, the appletviewer for JDK 1.3 performs the worst at 275 frames per second, while Internet Explorer 4’s VM performs the best at 400 frames per second.) Unfortunately, we are unlikely to see a PDA on the market offering that sort of performance for a number of years.

A Pentium 266 MHz laptop, with 64 MB of RAM and the JDK 1.1 appletviewer, provides a more realistic trial. The test takes 8.46 seconds, providing around 59 frames per second. The minimum frame rate for smooth animation is generally acknowledged as 24 fps. So with 59 fps, we could expect to render a simple 3-D scene and still have a number of processor cycles left over for the other computations typically required in a game.

The PersonalJava emulation environment (PJEE 3.1) running on the same machine is disappointing: 75.85 seconds, a frame rate of just under 7 per second. And interestingly, on the 800 MHz machine, the results improve little for PJEE: 44.17 seconds and 11.3 fps, which is not encouraging until you read the text hidden in the user’s guide:

Because it is a software test tool, the PJEE has not been fully optimized for performance (Using the PersonalJava Emulation Environment, Sun Microsystems, 2000).

That means that the emulator tells us nothing about the likely performance of PersonalJava on our target device.

Thus, we are left with the below-baseline performance test: iPaq’s 206 MHz processor. That device produces terrible performance: 176 seconds for 2.8 fps.

If we assumed that the architecture of the Pentium 266 MHz processor was equivalent to the StrongARM 206 MHz in the iPaq PDA (which we cannot, but we will for simplicity’s sake), we could say that the iPaq has approximately 77 percent of the laptop’s power. Therefore, calculating 77 percent of the 266 MHz frame rate, we could expect to get around 45 fps — not 2.8 fps. Even if the iPaq processor was only 30 percent as fast as the Pentium, we could expect around 17 frames per second, which suggests that the problem is probably not in the actual speed of the processor. In any case, the “PersonalJava Runtime Environment for Windows CE” FAQ explains why the results are less than optimal:

Q. Is this implementation optimized in any way?

A. This implementation has a smaller memory footprint than the Beta 1 implementation. However, the PersonalJava runtime environment for Windows CE is not intended to be a fully optimized product.”

That is, rather obviously, an understatement. In addition to not being a fully optimized product, according to a contact at Sun, the PersonalJava VM does not contain a JIT (just-in-time) compilation, which also helps to explain the substandard performance.

So taking the upper processor speed for our target platform (320 MHz), which is 55 percent faster than the 206 MHz CPU, means a paltry 4.35 frames per second for the current Sun JVM. You certainly won’t be able to develop the mobile version of Quake in that environment.

At that point, I fire my imaginary team of developers and throw my imaginary plans out the window — and the imaginary venture capitalist firm, who was going to provide the money, shreds the contract before I can purchase a house in Barbados.

Conclusion

With the proliferation of Java across virtually every device, a seemingly endless stream of new markets is opening up for developers to explore and exploit. In the early days, PersonalJava was less viable; however, with the increase in processor speed on embedded devices, it seems a more attractive option.

The disappointing conclusion is that a great deal of work must still be completed on PersonalJava VM performance before Java becomes ubiquitous as an embedded games platform for anything more than simple games. You just can’t develop the type of 3-D games described in this article on the current crop of embedded products available from Sun.

There is reason to be optimistic though. Companies such as ARM, who embed its processors into virtually every type of device you can think of, are adding the ability to execute Java bytecode directly on their processors, so sluggish speed may become less of a problem. Other companies, such as IBM (see sidebar The IBM Alternative), Insignia, Tao Group, and NSICom, have developed PersonalJava-compatible VMs, some of which may offer better performance than the Sun products. While it might be nice for all JVMs to perform at an approximately equivalent speed from a cross-platform development point of view, a JVM that completely outperforms the rest could possibly turn into the de facto standard. In the meantime, the lack of a clear leader means that PersonalJava will remain a hobbyist’s platform for higher-end games development.

As a games developer or, indeed, a developer in general, why should you target a device that limits what you can do with it? When everyone else can use virtually unlimited processor resources and memory, why should you be stuck with 8 MB to 16 MB of RAM and a processor that’s been available on the desktop for two years?

To answer that question, I could quote statistics until I turn blue in the face. Various sources predict that more than 80 percent of European users are expected to have mobile phones in 2005 and that over 1 billion people worldwide are expected to be using some form of mobile Internet connection by 2003. Whether those forecasts come true or not, because the worldwide games industry has grown larger than the movie industry, the games market for handheld devices could conceivably grow just as large.

The best reply I can offer to the question above is that unlike PC and console games development, where teams of 20 and up are the norm, small teams (even one- or two-person teams) could still be a viable option for that emerging market. It will undoubtedly be easier to get your foot in the door in the games market than in the current industry. Since PC and console games require such large teams, enormous expenditures, both in manpower and equipment, are required to get started, which may not be the case for the mobile games market. Also, as with any new industry, there will be a shortage of people with the requisite skills to launch the new technology.

Better yet, the challenges involved in developing games for a restricted platform harken back to the old days — relatively speaking — of games programming: small independent developers produced games that pushed the limits of the machines and left the rest of us wondering how on earth they did it.

While the result of my testing was hardly encouraging, if we have faith that Sun and other JVM providers will sort out performance problems, and keep in mind the veritable explosion of Java-enabled processors, J2ME has the potential to be an exciting and rewarding environment for games developers to work in.

Source: www.infoworld.com