|
January 18, 2006 JBenchmark's tips for JSR 184 hardware accelerated games |
[Back] |
|
|
Hardware accelerated Mobile Java
3D graphics create a great opportunity for mobile game developers. It eliminates many of the well known limitations of current software-based implementations, but also needs new approaches to use it effectively.
In this article Laszlo Kishonti, Manager of Kishonti Informatics who develops the JBenchmark benchmarking software, summarizes JBenchmark's experiences with hardware accelerated Mobile Java 3D phones, especially the Sony Ericsson W900 Walkman mobile phone, and shares his rules to improve JSR 184 hardware accelerated game performance. |
 |
About JBenchmark
During the development of their new Mobile Java 3D (M3G) benchmark software, JBenchmark HD, JBenchmark had the opportunity to stress-test some of the latest Mobile Java 3D-enabled phones, and one of them was the Sony Ericsson W900.
"It was fascinating to see how far these mobile devices have advanced performance-wise in a relatively short time," comments Laszlo Kishonti.
"To be able to create a forward-looking benchmark, we had to examine the improvements and the limits of these new platforms. This way we could create demanding, but realistic content."
JBenchmark HD is the second 3D benchmark created by Laszlo Kishonti's team at JBenchmark and is specifically designed for the latest 3D accelerated mobile phones. It measures 3D rendering quality, not just performance, and contains performance and quality tests covering shading, texture, fill rate, filters and perspective correction. More information can be found on JBenchmark's website>> |

Laszlo Kishonti, Manager of Kishonti Informatics. |
 |
The W900 scored high in the JBenchmark HD tests and is currently leading the rankings on JBenchmark's website, receiving top marks in the rendering quality section and impressive performance grades. Read more>>
"Apart from its high speed, the most impressive property of the Sony Ericsson W900 is the high quality rendering of filtered textures," explains Laszlo Kishoniti.
"Currently the W900 is the only phone in our performance database that implements proper bilinear and trilinear filtering. And because these are all hardware accelerated, using these nice effects won't slow gaming speed." |
Performance improvementsLaszlo Kishonti points out the most important performance improvements brought by embedded graphics accelerators (GPUs) to mobile phones such as the W900.
An important consideration in any Mobile Java 3D application performance optimization, and especially with dedicated 3D hardware, is finding out where the real bottlenecks in the pipeline are. There are a few usual suspects relating to graphics:
- CPU + bus speed (application logic, geometry transfer etc)
- Vertex pipe (number of vertices, lighting complexity, transformations etc)
- Pixel pipe (shading, texturing, blending and other per pixel effects)
Of course, hardware accelerated solutions won't solve the problem of an inherently slow CPU or bus, but can widely extend the limits of certain important segments of the 3D rendering pipeline.
JBenchmark's experiences from testing today's hardware accelerated 3D phones include:
- Geometry complexity: Drawing hundreds of thousands of triangles in a second was impossible up until recently and limited to PC desktops. Now it's readily available in a mobile phone.
- Texture mapping: The most important feature of mobile GPUs is the acceleration of rendering textured geometric objects. Using the GPU's own texture memory and its hardware wired solution, rendering textured triangles has become almost as fast as rendering simple shaded ones.
- Multi-texturing: Layering two textures above each other on geometric objects enables developers to create even more realistic 3D scenes. The second texture can be used, for example, to give realistic illumination effects (without using expensive dynamic lights) while leaving the first texture to control the overall color of the object.
"It should be noted that multi-texturing is not just about making things look better. You can increase performance by creating the effect of very large 'virtual' textures via the combination of two or more small textures," Laszlo Kishonti advises.
Rendering quality improvements
Although most mobile gamers will notice the huge performance difference instantly, with the increased frame per second rates, we should not forget to mention another very important advantage of hardware-based Mobile Java 3D - the improved rendering quality. Here Laszlo Kishonti outlines three benefits:
1. Perspective correction (of colors and textures)
Early Mobile Java 3D capable mobile phones had very limited resources; many game developers were not using perspective correction at all to accelerate game-play (see Figure 1). This created geometric distortions on the rendered images. Fortunately we can forget this "optimization strategy" forever, because this is done for us by the GPU "for free". Compare Figures 1 and 2.
 |
 |
| Figure 1: The base scene. Lack of perspective correction creates geometric distortions. |
Figure 2: Without filtering the textures show visible pixelation (hand and walls). |
|
2. Texture filtering On software based implementations, bilinear texture filtering was one of the most calculation-expensive features of the 3D subsystem. Due to this, many mobile phones simply did not include these very useful enhancements.
Simple point-sampling (that's the way 3D engines work without filters) however has artifacts, which add ugly flickering to textured objects. This will change with mobile GPUs, because they implement filtering in hardware, so using them won't cost additional CPU cycles. Compare Figures 2 and 3. |

Figure 3: With texture filtering, pixelation disappears. |
3. Sub-pixel precision Less commonly discussed, but some software renderers are not sub-pixel precise, leading to geometry that "snaps" from pixel to pixel, causing all sorts of cracking, distortion and other artifacts. Hardware-based implementations tend to be sub-pixel precise when drawing 3D geometry, leading to much smoother animation.
Tips to improve performance
Besides these improvements, what are the remaining limitations?
Though every game (or mobile 3D application) has its own performance profile, there are some rules which should be taken into account.
"The following list was collected by JBenchmark in the last couple of months and is far from complete, but it might be useful for developers starting to develop for Mobile Java 3D hardware. Some of these suggestions are effective on software rendered 3D phones too," says Laszlo Kishonti.
General rules
- Mobile 3D devices are generally resource limited (even after these great developments), so if you can optimize without a big drop in quality, then do so.
- The main CPU is usually slower in 3D calculations than the GPU. Try to move the workload to the GPU.
- Minimize the number of 3D bind-release cycles per frame when mixing 2D (MIDP 1.0/2.0) and 3D (JSR 184/M3G) graphics. Mixing 2D and 3D will generate a lot of traffic between CPU and GPU copying parts of the screen buffer and will drastically slow down frame rates.
CPU based/limited 3D calculations
- Overuse of skeletal animation (too many animated joints or overly-complex animations on a particular joint) will drastically slow down the rendering speed.
- Dynamic lights in M3G (OpenGL ES 1.x) is a leftover from desktop OpenGL. It is complex, expensive and often computed using the CPU or the already overburdened GPU vertex resources. Avoid it when ever possible and never use it for computing static lighting. Using just one light source can decrease performance by 50%! Using no lights is always the fastest way with current hardware, but using precompiled vertex based lighting can also be a cheap way to go. JBenchmark lost 14% of the frame rate with vertex based lights but the result is way more realistic than the unlit scene. Compare figures 3 and 4.
- Rendering smooth shaded triangles can be faster than flat, shaded ones because GPUs are optimized for higher rendering modes such as smooth (Gouraud) shaded triangles.
|

Figure 4: Pre-calculated vertex based lighting makes the scene much more realistic. |
Texturing
- Texturing is fast only if it fits the GPU's cache. Cache-misses generate traffic on the bus and a painful drop in performance. Calculate your texture budget and decrease size according to the cache size limit.
Geometric complexity
- Geometric complexity and frame rate are not always inversely related on GPU-accelerated platforms.
"Experiment on your target mobile phones and you may be able to increase the number of vertices and triangles without hurting frame rate. Batch size, the number of triangles you can draw in a single drawing call, can often be a much more important factor in determining performance than raw polygon count," Laszlo Kishonti recommends.
Scene structure
- Rendering 10 meshes with 100 triangles each usually takes a lot more time than rendering one mesh with 1000 triangles. Sometimes it is worth to merge all static meshes with the same appearance even if they are not connected at all. This results in fewer calls from the CPU to the GPU, thus reducing the time needed to communicate between them.
- Avoid using a lot of sub-meshes (multiple shaders/Appearances inside one mesh) by trying to keep the number of different Appearances small.
- Use indexed primitives ("explicit indexing" in TriangleStripArrays), as they allow for vertex reuse within a primitive. Smooth primitives (where the position, normal and texture coordinates of most vertices are all shared between several faces) can really take advantage of indexed primitives, which have the triple bonus of reducing CPU overhead, vertex transfer overhead (memory to GPU) and memory usage.
- Optimize your triangles into strips. Using long strips will decrease both the number of calls between the CPU and GPU and the calculations needed to transform your geometry, thus greatly increasing performance. Strips take less space in memory too.
- You might also try stitching your disjoint strips with degenerate (invisible) triangles to decrease the number of OpenGL ES calls from M3G. The advantages of this last method will gradually be lost, as smarter M3G implementations do this automatically.
Development tool-chain
- As the complexity of Mobile Java 3D games grows, it's impossible to create effective scenes without a 3D modeler package and an optimizing M3G file exporter. JBenchmark use their M3GExport plug-in for Maya which is freely available from www.m3gexport.com. Plug-ins are available for other popular modeling packages too. A set of plugins and tools are available from HI Corp to allow creation and export of 3D content for use with Mascot Capsule 4 (M3G / JSR 184), and include support for 3D Studio Max, Lightwave and Maya. More>>
Concluding remarks
"I hope this list will help you avoid some game development pitfalls and make exploiting the opportunities that 3D hardware accelerated mobile phones offer easier," Laszlo Kishonti concludes, "Following hardware performance, I'm sure we'll soon see a big step forward in the mobile 3D gaming experience too."
About Kishonti Informatics
| Kishonti Informatics specializes in mobile gaming, graphics performance measurement and development tools. It's popular JBenchmark graphical test suites let network operators, developers and consumers measure and compare the strengths and limits of hundreds of mobile phones and PDAs. Kishonti Informatics products are used by leading companies like Intel Corporation, T-Mobile International and Sony Ericsson. More information>> |
 |
More information: