Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Channels ▼
RSS

Mobile

OpenGL and Mobile Devices: Round 2


Richard is a developer for Software Bisque, lead author of The OpenGL SuperBible, and a professor at Full Sail University in Winter Park Florida where he teaches OpenGL programming in the game design degree program. He can be reached at [email protected].


In my June 2006 Dr. Dobb's article "OpenGL and Mobile Devices" (www.ddj.com/mobile/187203532), I examined OpenGL ES, a subset of OpenGL for mobile devices. Since then, the world of mobile devices has radically changed. Mobile devices with 3D graphics are readily available, as are downloadable SDKs from Sony, Nokia, and others. And then there's Apple's iPhone and iPod Touch.

When first announced, what caught my attention was Steve Jobs saying that the iPhone was running a version of OS X. Like every other Mac developer, the first thought that ran through my mind was "I can write software for that thing."

The second thing that went through my mind was "If it's OS X, then it has to be using OpenGL" because OpenGL,the de facto standard for cross-platform real-time 3D graphics, is an integral part of the Macintosh operating system. All we needed was an iPhone SDK. Well, the SDK is finally available and it's a complete XCode suite—compiler and debugger, performance analysis tools, a desktop simulator, sample code, and really good documentation. Frameworks are available for all the core OS X technologies, plus iPhone/iPod Touch specific features such as a touch interface, camera, accelerometer, and (my favorite) OpenGL ES.

The iPhone and iPod Touch both support OpenGL ES 1.1. Of particular interest to me are Vertex Buffer Objects, a minimum of at least one user-defined clipping plane, point sprites, some point parameters (distance attenuation), mipmapping, vertex skinning, and an extension for using a texture as a background image. This is a very capable and feature-rich graphics API, and it's 100-percent hardware accelerated.

The Hardware

The graphics hardware behind the iPhone and iPod Touch is a PowerVR MBX Lite, which uses Tile-Based Deferred Rendering. (Sony Ericsson uses this same chip for some of its cell phones.) In addition to Apple's SDK, you should get the PowerVR developer's notes that include useful performance tips (www.imgtec.com).

There are a few limitations you should know from the start:

  • There is no stencil or accumulation buffer.
  • There are only two texture units.
  • The maximum texture size is 1024×1024 (use power of two only).
  • The maximum space for textures and surfaces is 24MB.
  • Only 2D textures are supported.
  • There is no software rendering fallback.

The PowerVR chip uses a full floating-point pipeline throughout. The OpenGL lighting model is fully hardware accelerated, and there is no need to use fixed-point values for either lighting and material values, or vertex data. For best performance, use directional lights instead of point lights when possible, and try to always use indexed strips for geometry submission. To minimize bandwidth, you can use unsigned byte values for colors, and either unsigned byte or shorts instead of floats for texture coordinates.

Mipmaps (optimized collections of bitmap images accompanying main textures that increase rendering speed) were not available with OpenGL ES 1.0, but are with 1.1. On the PowerVR hardware, bilinear filtering is considered "free", but you should limit the mipmapping mode to GL_LINEAR_MIPMAP_NEAREST for best performance. Loading textures with an internal format of 565 instead of 888 speeds things up, and (if possible) you may want to make use of the PowerVR's native texture compression formats of either PVRTC2 or PVRTC4.

One of the more interesting aspects of the PowerVR chip is that it uses Tile-Based Deferred Rendering (TBDR), in which all rendering commands are queued and no actual rendering occurs until all commands for a given frame are given. The rendering commands are then analyzed, geometry is sorted, and converted into strips. Rendering then occurs. You still need to sort by alpha for transparency, but sorting front-to-back to eliminate overwrite is no longer necessary. (This is somewhat like the "early-z" feature some desktop graphics hardware supports.)

While this has many performance advantages, there is one performance gottcha for desktop OpenGL developers coming to this platform—state changes can be very expensive. While reducing state changes has always been a staple of OpenGL performance techniques, many desktop systems only moderately benefit from excessive texture or other state changes. Nongaming applications typically ignore this advice completely, yet are still able to maintain relatively fast and interactive frame rates.

Not so on the iPhone. One of my personal rendering "magic tricks" involves swapping between mipmapped and nonmipmapped texture modes using the same texture object. When I tried this on my iPod Touch, it ran so slow at first that I thought I was getting a software fallback (which, it turns out, does not exist).

To get best results in a complex rendering (especially if you are making a game), you should architect your rendering code to sort geometry based on rendering state, and not worry about front-to-back sorting as is typical on desktop systems.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.