Sunday, January 23, 2005

Article of the Day

A New Dimension for Java Games: Mobile 3D Graphics API
By Tomi Aarnio, Nokia Research Center

Market analysts predict that downloadable games will grow into a multi-billion-dollar business within a few years [1]. Java is the most widely deployed platform for third-party applications in mobile devices thanks to its vendor-neutral status, hardware independence, and built-in security, among other things. However, an important piece of technology that has been missing from Java until now (and that would benefit games tremendously) is interactive 3D graphics - the capability to synthesize images from descriptions of three-dimensional objects in real time. The Mobile 3D Graphics API now makes that possible [2].
Not only does 3D graphics make games look more impressive, but it also enables new genres by giving more freedom to designers and artists. It even helps to bring down costs: being inherently scalable, it allows games to be easily targeted at different display sizes and color depths.

The Java bottleneck

On Symbian, anyone with the necessary skills can make a 3D engine and expect it to run as fast as an engine made by the device manufacturer. Unfortunately, writing a competitive engine in Java is not possible. To see why, let us delve into the internals of Java for a while.
Symbian applications are compiled into so-called native code that is executed directly in hardware. Java applications, on the other hand, are expressed in hardware-independent bytecode that is executed by a virtual machine. This imposes a varying performance penalty that is tolerable in ordinary applications, but prohibitive for real-time graphics.
Indeed, our measurements on representative graphics tasks show that Java code runs up to twenty times slower than native code. The situation will improve with Java hardware accelerators, as well as new virtual machines that compile bytecode into native code, but even then the performance barrier remains.

Because efficient graphics engines cannot be written in Java, it follows that one must be implemented in native code (or even in dedicated hardware) and made available as part of the Java platform. This insight forms the foundation of the Mobile 3D Graphics API.

Game development made easy

For those familiar with graphics, the Mobile 3D Graphics API (M3G) can be described as a unified immediate/retained mode API with a configurable rendering pipeline at the low level and an animated scene graph layered on top of it. For a special twist, it includes a file format as an effective means to import content from 3dsmax™ or other modeling tools.

For everyone else, this means that M3G is optimized for productivity, performance, and flexibility.
Productivity is enhanced by separating content from the application logic. Thanks to the M3G file format, game characters and environments can be changed without affecting the source code at all. The API also has built-in support for several sophisticated tools, like vertex skinning and morphing (to account for character animation and other deformation effects) as well as keyframe interpolation (for smooth animation of object positions, colors, and other properties). These tools must normally be implemented by game developers themselves. That, in turn, requires a lot of expertise and hard work, and thus increases development costs significantly.
A number of measures were taken to maximize performance. For example, the underlying graphics engine can be written almost entirely in native code, with only a thin layer of Java on top. The design also facilitates preprocessing in the setup stage, as well as extensive caching of intermediate results, to attain higher throughput when rendering. Furthermore, the API is designed to minimize garbage collection - an irritating operation that cleans up the Java memory space and freezes the game while doing so.

Flexibility is guaranteed by exposing a rich set of parameters for configuring the rendering pipeline. There are dozens of mutually independent parameters in the pixel pipeline alone, yielding billions of unique configurations - and roughly the same number of subtly different visual effects that can be applied to polygons. This is more than adequate for developers' needs today, and will suffice for years to come.

Rapid and effective implementation

The history of 3D graphics is littered with standards that were designed on paper and later proved to be unworkable in real life - take VRML or MPEG-4. Reference implementations and prototypes are often unable to reveal critical design faults.
To avoid making yet another standard that only looks good on paper, the 3D graphics team at Nokia Research Center began to write a production quality implementation of M3G very early on. This, combined with similar efforts at other participating companies, allowed the standardization group to quickly validate design choices - and sometimes reverse them. The parallel implementation approach has also shortened the time-to-market substantially: the first Nokia device to implement M3G, the Nokia 6630, will be on the market less than a year after the standard was completed.

References:
[1] U.S. Wireless Gaming Forecast Update. IDC, December 2003.
[2] The Mobile 3D Graphics API specification, http://forum.nokia.com/java/jsr184, http://www.jcp.org/jsr/detail/184.jsp
[3] The CLDC HotSpot™ Implementation Virtual Machine, http://java.sun.com/j2me
[4] ARM Jazelle™ Technology, http://www.arm.com/products/solutions/Jazelle.html
[5] OpenGL ES, http://www.khronos.org/opengles
[6] OpenGL, http://www.opengl.org

(http://www.nokia.com/nokia/0,,62395,00.html)

0 Comments:

Post a Comment

<< Home