But as David Britten, vice president of technology at mobile developer/publisher Superscape, pointed out in his case study of the company's development of a 3D-accelerated version of its Ducati 3D Extreme game, the consistency of hardware remains a problem. Some devices still don't support OpenGL ES, while other cause problems because hardware manufacturers don't always ship product with standardized firmware.
"The industry needs a certification program for 3D hardware acceleration and drivers," he said.
As for Ducati 3D Extreme itself, prior to working on the 3D-accelerated version, Superscape developed 3D software versions of the game both for Java and BREW handsets, as well as a 2D Java version.
The 3D Java release used Superscape's JSR 184-compliant technology, which produced a game that ran at about 10 frames per second. The reason was a lowest common denominator approach had to be taken, despite the potential of some of the higher-end phones. In turn, this lead to design limitations; notably the fact that only two pieces of track could be displayed at any time. This resulted in what Britten called a 'rolling carpet' model where all the game's tracks had to be built out of a combination of two simple segments.
The BREW software version of game offered more options, as the height of the track could be varied, textures were higher resolution, and the polygon count of the bike and the animations of the rider were also of higher quality.
As for the 3D-accelerated version, this was designed around Qualcomm's MSM6550 chipset, which is currently deployed in five Verizon-branded handsets. The architecture features an ARM9 CPU, a DSP4, and dedicated 3D hardware, and outputs on a QVGA (240 x 320 pixel) resolution screen.
Ducati 3D Extreme
Written using the OpenGL ES Common Lite v1.0 API, the game work was split with the CPU dealing with the gameplay logic, the DSP4 running the geometry, lighting and audio, while the dedicated 3D hardware did the rasterizing and Z buffering.
"Because everything's on chip, you get well balanced performance between the different components, and we used 10-15 percent less power per frame than the software-version," Britten stated.
In terms of porting the game, the process took about 30 man-days, although Britten revealed this consisted of port Superscape's underlying engine. "Now the process only takes a couple of man-days per title," he said.
Equally, he claimed many of the changes undertaken could be consider best practices that should be included for all mobile development, although noting they are more important when it comes to 3D hardware-accelerated games because of the more sophisticated content involved.
Examples of these included minimizing the number of OpenGL ES calls, by welding meshes for objects, such as the bike, that would always be onscreen, and minimizing state changes by sending associated textures and geometry at the same time. However, this had to be balanced against the constraints of the 128 x 64 texels texture cache.
The result was a game that ran at 14.5 frames per second in hardware-accelerated mode, compared to 9.5 fps in software. "It doesn't sound like much compared to theoretical figures but this is a real world game doing 20,000 textured triangles per second, which is double what we'd expect from a typical BREW app," Britten said.