At Intel™The processor transplanted OpenGL * games to Android * (Part 2)

This article is the second part of the two sections, discussing the obstacles to porting OpenGL games to Google Android. Before you start a game implant project (including differences in OpenGL extensions, floating point support, texture compression formats, and the GLU Library), you should recognize these obstacles. It also describes how to use OpenGL ES to set up an Android development system for the Intel Atom processor and how to obtain the optimal performance of the Android virtual device simulation tool.

The first part of this article describes how to use OpenGL ES on the Android platform through the software development kit (SDK) or Android Native Development Kit (NDK), and how to determine the method to choose. This article also introduces various sdks, OpenGL ES sample applications in NDK, and Java * native interfaces. This allows you to use Java and C/C ++ components in combination. We also discussed how to determine whether to use OpenGL ES version 1.1 or 2.0.

Obstacles to porting desktop OpenGL games

OpenGL ES 1.1 Application Programming Interface (API) is a subset of OpenGL 1.x API. It has been used in Desktop Linux * and Windows * systems for decades. Similarly, OpenGL ES 2.0 APIs are a subset of OpenGL 2.0 APIs in a desktop system. Therefore, all game porting projects should first evaluate the OpenGL feature set used by the game code to determine the service life of the code and find the part that needs to be written again, the OpenGL version used is different from the OpenGL ES version used on Android.

The main differences between OpenGL 2.0 and OpenGL ES 2.0 are divided into three categories: geometric norms, geometric transformations, and changes in OpenGL coloring language (GLSL. OpenGL 2.0 provides four methods to describe ry: instant mode, display list, vertex array, and vertex buffer object. OpenGL ES 2.0 does not support instant mode (glBeginAndglEndBlocks) and display lists. Therefore, you must use a vertex array or a vertex buffer object to describe the ry.

OpenGL 2.0 provides functions for loading mode views, projections, and texture matrices, as well as convenient functions that combine these standards, suchglTranslate,glRotateAndglScale. OpenGL ES 2.0 does not have the above functions or projection functions, because the fixed function pipeline is replaced by the coloring program module. For OpenGL ES 2.0, standard and projection calculations should be performed in the vertex shader.

In addition, the coloring language for OpenGL ES 2.0 (glsl es) is also a subset of the desktop OpenGL 2.0 (GLSL) Coloring language. The main difference is that GLSL has built-in variables to access the declarations in the vertex shader's fixed function pipeline (suchgl_ModelViewMatrix). Because OpenGL ES 2.0 does not support fixed function pipelines, glsl es does not support these variables.

OpenGL ES 2.0 does not have the following OpenGL 2.0 features:

• Real-time mode geometric Specification
• Display list geometric specifications
• Pipeline processing for all fixed Functions
• Fixed variation and projection
• Matrix stack and Transformation
• User Cropping Area
• Line and polygon softening and dot (stipple)
• Pixel rectangle and bitmap
• One-dimensional textures and some texture encapsulation Modes
• Masked Query
• Smoke

Note: For more information about the differences between OpenGL 2.0 and OpenGL ES 2.0, see examples.

Porting from other embedded systems

Generally, it is easier to use OpenGL to port OpenGL ES games from other embedded systems to Android than to port OpenGL ES games from desktop systems, because most embedded systems use the same OpenGL ES 1.1 or 2.0 specifications as Android. When porting OpenGL ES code from other embedded systems, the biggest difference is the supported OpenGL ES extension, especially when it is related to the compressed texture format. Another noteworthy difference is the floating point support between embedded systems.

Floating Point support

The Common and Common-Lite versions provide early implementation of OpenGL ES 1.0 and 1.1. The Common version applies to processors with floating point hardware; the Common-Lite version applies to processors without floating point hardware, so fixed point computing is required. Because Android requires floating-point processors, such as Intel Atom processor, there is no need to use a fixed point. Therefore, the system images provided by Google for Android only include Common (floating point) for OpenGL ES 1.1) driver. The Khronos standard for OpenGL ES 2.0 can be used only for floating points. This is important if you are porting OpenGL ES 1.0 or 1.1 games from other embedded systems using the Common-Lite version of OpenGL ES, because you must convert all fixed points in the code to floating point (because Android only supports the Common version of OpenGL ES ). In general, the Common and Common-Lite drivers on the embedded Linux system are similarlibGLESv1_CM.soAndlibGLESv1_CL.so.

If you are porting OpenGL code from a desktop application, you may have used floating point code. However, pay attention to the use of any double-precision floating point in the code. Android supports double-precision floating point, but OpenGL ES only supports single-precision floating point. Therefore, you must first convert all double-precision values to single-Precision values, and then pass them to OpenGL ES 1.1 or 2.0.

OpenGL extension

One of the biggest obstacles is that cross-platform transplantation of OpenGL code comes from the application code's use of OpenGL extensions and embedded system graphics libraries (EGL. You should evaluate the extensions used in traditional code at the early stage of the porting process and compare them with the extensions actually used on the target Android device. Expansion is a way for GPU developers to expose specific features of their GPUs beyond the standard OpenGL rules. All extensions used in traditional code that are not applicable to the target platform require the use of new code to eliminate the need for extensions or use different extensions.

Supported extensions vary greatly in OpenGL of different versions, and the supported extensions are different even on different Android platforms due to the difference in GPU architecture. The Intel Atom processor uses PowerVR * GPU, which is the most widely used GPU architecture on mobile devices today. Android applications should not assume that any extension of OpenGL ES applies to any device. Applications with good functionality can obtain a list of available extensions by querying OpenGL ES at runtime. You can use the following calls to obtain a list of available extensions from the OpenGL ES and EGL drivers:

• glGetString(GL_EXTENSIONS); 
• eglQueryString(eglGetCurrentDisplay(), EGL_EXTENSIONS);

All functions and enumeration names required to call the extension are inglext.h,gl2ext.hAndeglext.hIt is defined in the header file. Therefore, after your application confirms that an extension is available at runtime, you can directly call it.

The Google Play website provides a useful application-OpenGL Extensions Viewer (GLview), which can be used to query and display returned information for any Android device running it. You can use GLview-like tools to personally test a variety of Android devices to confirm available extensions. In addition, Khronos can maintain the OpenGL es api registry for all known OpenGL ES extensions-important reference.

Texture compression format

OpenGL ES's most important extensions provide support for compressing textures. This is an important technology that most 3D games use to reduce memory requirements and improve performance. However, the formats used with OpenGL ES can only be defined by extensions, so they are different on each platform. Unfortunately, all Android devices only support the Ericsson texture compression (ETC1) format (except for the first generation devices, the first generation devices do not support OpenGL ES 2.0 ). ETC1 only supports 8-bit precision per pixel, and does not support alpha. Most games use compressed textures with alpha, which is a serious obstacle to porting. The Android platform that does not support alpha may use several specialized formats, but with these formats, your game will be limited to Android devices that use the specific GPU architecture. Table 1 summarizes the various GPU architectures and texture compression formats they provide for Android.

Table 1. Special compression texture formats supported by Alpha

GPU Architecture	Texture format
PowerVR	PVRTC
ATI/AMD	ATITC/3DC
NVIDIA Tegra * 2/3	DXT/S3TC

The PowerVR GPU on the Intel Atom processor supports PVRTC format and ETC1. PVRTC supports alpha and 2-or 4-bit precision per pixel, which greatly reduces the texture size of ETC1 format. PVRTC is the most widely supported format after ETC1. It can also be used in various generations of Apple iPhone *, iPod touch *, and iPad * devices, therefore, it can provide Android compatibility beyond the basic OpenGL ES standard on the Intel Atom processor, which is important for Android and Apple iOS * platforms when porting games. However, Android devices with different GPU architectures cannot be processed. If your game uses any specialized texture format, it must query OpenGL ES extensions at runtime to confirm which formats are actually available and only use textures compressed in these formats. This makes design decisions difficult. You can select:

• Android devices with different GPU architectures are not supported
• Provides all textures compressed in three specialized formats
• Do not use alpha texture Compression
• Separate the color and alpha components into a pair of ETC1 files and re-combine them in the fragment shader.

After determining the specific formats required for your game, make sure that they are declared in the list, as detailed below. For more information, see texture compression support.

GLU Database

In general, the desktop version of OpenGL provides a convenient function Library called OpenGL Utility Library. GLU includes functions that are strictly not OpenGL or are not required to use OpenGL, but they are very helpful in compiling 3D applications for OpenGL. The standard GLU library includes functions for constructing model views and projection matrices, performing general matrix calculations, calculating Quadratic Surfaces, subdivided polygon, generating bitmap and reporting error messages. Most games on the desktop OpenGL use some GLU functions, which may be troublesome, because Android can only provide the lowest implementation (only available in the SDK ). See table 2.

Table 2. Summary of Android classes that provide the GLU Function

Class	Function
Android. opengl. GLU	Create a projection matrix for OpenGL ES
Android. graphics. Matrix	Create a model view and a general matrix

OpenGL ES 1.1 and 2.0 provide support for generating bitmap. Therefore, they do not support Calculation of Quadratic Surfaces and subdivision polygon. If you need these functions, there are other open-source GLU executions, which are more complete and suitable for use with Android NDK, such as glu es.

List Declaration for OpenGL ES

Applications that require OpenGL ES should declare this fact in their list files. This will prevent your application from being installed on devices that do not support the required OpenGL ES version. The following example shows the correct syntax of the configuration parameters in the AndroidManifest. xml file.

OpenGL ES 1.1:

• <uses-feature android:glEsVersion="0x00010001" android:required="true" />
• <uses-sdk android:minSdkVersion="4"/>

OpenGL ES 2.0:

• <uses-feature android:glEsVersion="0x00020000" android:required="true" />
• <uses-sdk android:minSdkVersion="8"/>

The main change in Android 4.0 (API Level 14) Is that OpenGL ES hardware acceleration is enabled by default on all applications, which can be 14 or more advanced.minSdkVersionParameter declaration. Applications with lower API level canandroid:hardwareAccelerated=“true”Add<application>Label to enable acceleration. If your application uses new features in Android 4.0 that require OpenGL ES hardware acceleration, suchTextureViewClass, you must enable it in the list, otherwise these features will not run.

If your application usesNativeActivityClass, its list must declare it, and specify the name of the shared object library including the local Activity. In addition,minSdkVersionThe parameter must be 9 or later. Seenative-activitySample application.

If your application uses a compressed texture, ensure that they are declared as follows. This does not prevent your applications from being installed on devices that do not have these features. Therefore, you should still query the devices at run time for extensions in the desired dedicated format. External devices (such as Google Play) can use these LIST parameters to filter applications that cannot run on devices that do not support the required texture format.

LIST parameters required for compressing the texture format:

• <supports-gl-texture android:name="GL_OES_compressed_ETC1_RGB8_texture" />
• <supports-gl-texture android:name="GL_OES_compressed_paletted_texture" />
• <supports-gl-texture android:name="GL_IMG_texture_compression_pvrtc" />

Set up an Android development system for the Intel Atom processor

When you set up an Android development system, make sure that you select an Android version that includes the built-in support of the Intel Atom processor. This helps you find the Intel mobile device and use the Android Virtual Device (AVD) of the Intel Mobile System image ). Table 3 summarizes all current major Android versions and versions, including system images for the Intel Atom processor.

Table 3. Contains OpenGL ES and Intel Atom? Summary of Android versions supported by processors

Version	Name	API	Supported	Intel lingdong support
For Android 1.5	Cupcake	3	OpenGL ES 1.0	None
For Android 1.6	Donut	4	OpenGL ES 1.0, 1.1	None
For Android 2.0	Ã ‰ clair	5	OpenGL ES 1.0, 1.1	None
For Android 2.1	Ã ‰ clair	7	OpenGL ES 1.0, 1.1	None
For Android 2.2	Froyo	8	OpenGL ES 1.0, 1.1, 2.0	None
Android 2.3.3	Gingerbread	10	OpenGL ES 1.0, 1.1, 2.0	Supported
For Android 3.0	Honeycomb	11	OpenGL ES 1.0, 1.1, 2.0	None
For Android 3.1	Honeycomb	12	OpenGL ES 1.0, 1.1, 2.0	None
For Android 3.2	Honeycomb	13	OpenGL ES 1.0, 1.1, 2.0	None
For Android 4.0	Ice Cream Sandwich	14	OpenGL ES 1.0, 1.1, 2.0	None
Android 4.0.3	Ice Cream Sandwich	15	OpenGL ES 1.0, 1.1, 2.0	Supported
For Android 4.1	Jelly Bean	16	OpenGL ES 1.0, 1.1, 2.0	Supported

Android versions 2.3.3 (Gingerbread), 4.0.3 (Ice Cream Sandwich), and 4.1 (Jelly Bean) include all the support for Intel's Atom processor, including drivers for OpenGL ES 1.0, 1.1, and 2.0. Select only one version from the previous Android SDK Manager version and make sure that the system images of intel x86 lingzhu are listed as they are. In addition, make sure that you download and install the Intel hardware accelerator execution Manager (HAXM), which is located in the SDK manager under Extras. If you have not installed the Android SDK manager, you can download it from the http://developer.android.com/sdk/index.html.

The SDK manager can download the HAXM installer and save it to the Extras folder. To complete the installation, you must manually run the HAXM installer. In addition, you must enable the virtual technology feature in the rom bios settings menu of the developer. The HAXM installer is saved in…\android-sdk\extras\intel\Hardware_Accelerated_Execution_Manager. After HAXM is correctly installed, the following message is displayed when x86 AVD is started: "HAX is working and emulator runs in fast virt mode ".

Use an x86 system image containing AVD simulation and HAXM

Every embedded developer knows the acceleration effect of the Virtual Device Manager on new application development. However, using AVD on an ARM system image is very slow, because AVD must simulate every ARM command on a Windows or Linux development system. It takes 5 minutes or longer to start Android on an ordinary arm avd. With HAXM, Intel solves this problem by running the Android x86 system image directly using the virtual technology features built in the new Intel desktop processor. When you install the tool and use it with the Intel Atom x86 system image AVD, your application development will be significantly accelerated, and you do not even need to enable the Intel Atom hardware.

Google added support for OpenGL ES April 2012 in AVD simulation in 2.0 (starting from SDK Version 17 ). It converts OpenGL ES 2.0 calls to the available OpenGL 2.0 APIs on the host operating system, which makes 3D graphics run faster. However, you must enable this feature when creating an AVD. Otherwise, the call to OpenGL ES 2.0 fails. Of course, your Windows or Linux host system must install drivers for OpenGL 2.0 (or later), which usually requires independent graphics cards. OpenGL ES 2.0 can be simulated on both ARM and x86 system images, but for optimal performance, use it on the x86 system image with HAXM enabled. Performance differences are significant.

To enable OpenGL ES 2.0 simulation, select an AVD In the AVD manager and click Edit. Click New in the Hardware Properties window, scroll through the property list, find the GPU emulation, and then click OK. Finally, change the no attribute to yes and click Edit AVD and OK to save the change. Then a message is displayed.hw.gpu.enabled=yes.

For versions earlier than SDK Version 17, AVD simulation only supports OpenGL ES 1.0 and 1.1. Strictly speaking, Version 1.1 does not require GPU simulation to be enabled because it can be simulated without the help of the host system. If it is enabled, it will become slower. However, the SDK tool without the help of the host cannot simulate version 2.0, so if it is unavailable, AVD will directly close your application when trying to initialize OpenGL ES 2.0.

UseHelloEffectsThe example application is used to test whether the OpenGL ES 2.0 simulation works for the first time.GLES20TriangleRendererThe example is actually converted to version 1.1 when running on AVD. Therefore, this test is not successful. All OpenGL ES 2.0 samples provided in Android SDK and NDK are related to the original sample and should not be used for OpenGL 2.0 simulation testing.

Intel Graphics Performance Analyzer

Another important tool suite available to Android-targeted OpenGL ES application developers on Intel's Atom processor is Intel's graphics Performance Analyzer (Intel GPA ). The toolkit provides real-time Views of dozens of key system standards, including CPU, GPU, and OpenGL ES. Intel GPA can be run on a Windows or Ubuntu Linux development system and communicate with driver components running on the Android target device through the Android debugging interface. By running several experiments, you can quickly see problems in the graphic pipeline and find the best opportunity to optimize the code.

For more information and download the latest version of Intel GPA (2012 R4) for Android development, visit the http://software.intel.com/en-us/vcsource/tools/intel-gpa? Cid = sem121p7972.

Conclusion

Android's support for OpenGL ES and C/C ++ reduces the barrier for porting games and other applications that use 3D graphics extensively on Android platform devices. However, there are still some obstacles that you need to understand before starting a game porting program. The biggest obstacle is the differences in OpenGL extensions and the texture compression formats supported by Android. On the good side, Google and Intel have made great progress in improving tools developed for OpenGL ES 2.0 in recent years, today, a large number of games, game engines, and traditional game software can be used under OpenGL standards, which is a huge opportunity for software developers who have begun to develop it.

About the author

Clay D. Montgomery is the main developer who develops OpenGL-oriented drivers and applications on embedded systems. He has worked as an independent consultant in the design of cross-platform Graphics Accelerator hardware, graphics drivers, APIs, and OpenGL applications in STB systems, VLSI technology, PHILIPS semiconductors, Nokia, Texas Instruments, and AMX. He has participated in the development of Freescale I. MX and TI OMAP * platforms as well as the first OpenGL ES, OpenVG * and SVG drivers and applications for Vivante, AMD, and PowerVR. He developed OpenGL ES on Embedded Linux and opened seminars for professors. He is also a representative of many companies in Khronos Group.

More information

• Google OpenGL ES guide, "Show graphics cards with OpenGL ES": http://developer.android.com/training/graphics/opengl/index.html
• Vladimir Silva, professional Android games: http://www.apress.com/9781430226475
• Dan Ginsburg, "Finding 3D applications for mobile devices based on OpenGL ES": http://software.intel.com/en-us/articles/targeting-3d-applications-for-mobile-devices-powered-by-opengl-and-opengl-es
• Chris Pruett, "Android-oriented game development: Quick Start": http://android-developers.blogspot.com/2010/06/game-development-for-android-quick.html
• Tewdew Software, "Android texture decision": http://blog.tewdew.com/post/7362195285/the-android-texture-decision
• Jack Palevich, "porting GLES Quake-Quake to Android": http://grammerjack.blogspot.com/2009/10/gles-quake-port-of-quake-to-android.html
• Romain Guy and Chet Haase, "Android 4.0 graphics and Animation": http://android-developers.blogspot.com/2011/11/android-40-graphics-and-animations.html