Developing Mobile Game Graphics for Intel® Architecture-Based Android* Tablets, Part 1

Introduction

The market for games and other graphics-intensive apps for mobile devices is exploding, and important new developments are accelerating it. With better hardware, software, and ecosystems, the opportunity for Android* game developers has never been better. But where should you start? In this first of a two-part series, I explore recent developments in game engines, graphics software development kits (SDKs), and other middleware that will help you get your game or graphics-intensive app up and running on Android quickly and provide a richer, more compelling user experience with all those new pixels that tablets have available.

This first installment introduces essential concepts and categories of game engines and middleware to help narrow your choice, including SDK versus Android Native Development Kit (NDK) development. The second part will detail the strengths and weaknesses of specific game engines and middleware that are good options for 2D and 3D graphics development for Android tablets, including some you have probably never heard of. An incredible wealth of software is available for game development, but I focus on solutions that are well suited to Android tablets.

Better Hardware

The new generation of Android-based tablets with Intel® Atom™ processors are game changers. With longer battery life and large, high-resolution displays, it’s easy to see why these devices are displacing laptops running Windows* for many users and apps. Of course, it takes a serious graphics processing unit (GPU) to push a million or more pixels, and the integrated SGX544MP2 GPU on Intel platforms (codenamed Clovertrail) is up to the task. On Intel new platform codenamed Bay Trail, the latest Intel HD graphics GPU is provided to support up to OpenGL ES 3.1. It may surprise you that more than 99 percent of all Android devices in use today have GPU acceleration of the OpenGL ES* 2.0 application programming interface (API) built in. But what about the software? Android still has a graphical user interface (GUI) designed for phones, and most mobile games still look like the console games of 10–15 years ago. Games that exploit all those new pixels well will stand out from the crowd. That is the opportunity, but it’s also the challenge. Success will require exploiting the latest software middleware and tools.

Better Software

Large, high-resolution displays demand better graphics. What was once cool on a 4‑inch phone looks really dated on an 8‑inch tablet without improved software. You need to exploit all of those available pixels to provide a more visually compelling user experience. For example, simply replacing solid colors and gradients with images that are rendered with animation or lighting effects can dramatically improve the look of a UI. Fortunately, many graphics SDKs, game engines, and other middleware recently ported to Android can help, but there are several options from which to choose, and deciding on one isn’t trivial. It’s a critical decision because any middleware can require a substantial time investment to learn and will directly affect the look and performance of your app. So, in this article, I hope to help you narrow your decision—or at least detail some of the better options you might not have considered, yet. But first, let’s define some important terms and middleware categories.

Android* Graphics APIs

Two graphics APIs are built into Android that most apps use today: the Canvas API and OpenGL ES. The Canvas API is part of the original Android framework and is limited to 2D (although some 3D effects are possible) and Java* technology. Support for OpenGL ES has also been in Android from the beginning but has improved dramatically since the Froyo release, with the addition of OpenGL ES 2.0 and support for C/C++ with the Android NDK. The Ice Cream Sandwich release brought a major redesign of the Android internal graphics system, which now relies heavily on OpenGL ES 2.0 as more than 99 percent of all Android devices now have built-in GPUs that accelerate it. The Canvas API has also been improved to use OpenGL ES acceleration. Developers now have the choice of using OpenGL ES 1.1 or 2.0 from Java, native C/C++, or both in addition to the Canvas API.

The SDK and the Android NDK

The Android framework SDK requires that app development be in Java, but the NDK for C/C++ is also available. Of course, you can use Java and C/C++ together through the Java Native Interface. Because most of the Android platform’s functionality is available only from the SDK, Google recommends that you implement as much code as possible in Java, but there is a trend for developers to implement graphics-intensive apps on Android partially in C/C++ with the NDK. Such a hybrid design may not be the most elegant or easy to implement, but it’s necessary if you want to use some of the best middleware available and get the best possible performance. Some middleware options are available only in C/C++, which is why Google decided to open the NDK to app developers: to use the large pool of existing software available for OpenGL*, which is typically in C/C++. Good all-Java options are becoming available too. Some of these attempt to provide native code performance while allowing your development to remain entirely in Java.

Intel® Atom™ Processors

Intel Atom processors provide outstanding support for the Canvas and OpenGL ES APIs on Android, with OpenGL ES acceleration and faster floating point than other processor types. Intel’s software support includes x86 system images for Android Virtual Device emulation, the Intel® Hardware Accelerated Execution Manager, and Intel® Graphics Performance Analyzers. These tools make it faster and easier to develop apps for Intel Atom processor-based Android tablets, and you don’t even need Intel Atom processor-based hardware to get started.

Authoring Tools

If you have worked with OpenGL, you have seen books and web tutorials that show how to draw a triangle or a textured cube. But what about more complex shapes? Constructing complex geometry programmatically is tedious; fortunately, there’s a better way: authoring tools. Professional game developers use tools like Autodesk 3ds Max*, Autodesk Maya*, or Blender to construct 3D geometry complete with texture maps, animations with physics, and lighting effects.

Some game engines and SDKs provide a specific authoring tool or integrated development environment (IDE) that is tightly integrated, particularly for 2D development. Generally, 3D engines support the major stand-alone tools, with plug‑ins for tighter integration, because that’s what game developers expect. A full description of authoring tools is beyond the scope of this article, but it’s essential to understand that this is where modern graphics content creation begins, and these tools are more accessible, easier to learn, and more widely used than ever. The cost of these tools varies widely. Blender, for example, is open source and free; hundreds of video tutorials are available online to help you learn how to use it. Content you create with these tools can be exported to a range of file formats that game engines use to render your graphics on Android devices.

Most game engines and other middleware assume that you’re using an authoring tool to create geometry in 3D scenes with animation and lighting effects. These tools run on a workstation to produce content that will be copied to Android devices and rendered by a game engine or other middleware. Therefore, your choice of authoring tool can determine which game engines or middleware are available to you (although most middleware support multiple authoring tools).

You might think you don’t need an authoring tool or game engine if your geometry is simple. Say you just want to animate some rectangles around the screen. That’s easy to do entirely with code, right? Well, do you want them to move with simulated inertia? Friction or gravity effects? Detect when they collide? Authoring tools create the key frame animations for rotation and scaling and apply those physics effects for you. How about some 2D images on those rectangles, with reflection and specular highlight effects? Authoring tools also automate the generation of texture coordinates and surface-normal data that OpenGL ES requires to render geometry with lighting effects. Game engines import this data from the authoring tools and render it as well as detecting collisions and handling audio, touch input events, and more. This is why using authoring tools has become so important for modern app development.

2D Game Engines

Why use a 2D game engine when the 2D Canvas API is built into Android?…because game engines provide much better graphics performance, most being built directly on OpenGL ES and bypassing the Android Canvas API. Even though the Canvas API also uses OpenGL ES, its performance doesn’t compare with the directly accelerated game engines that are available. Many of these 2D engines on Android are quite mature. In fact, many published titles and integrated features can save you a lot of development time, including 3D audio, networking, and physics. Some have tightly integrated authoring tools or IDEs and simulators to test and debug your game on a workstation before testing on Android, which also accelerates the development cycle. Finally, game engines provide platform abstraction, so you can easily port and publish your game to other platforms, as well.

Game engine licensing and pricing vary dramatically. Some 2D engines are open source and completely free, such as Cocos2D and AndEngine, but support is limited to online forums. Others offer tiered pricing models, so you can start developing for free, and then pay subscription or royalty fees when you need more technical assistance, advanced features, or are ready to publish your game. Some allow publishing at no cost if you can tolerate their logo splash screen or limited features. Generally, subscription costs increase with the number of different platforms for which you want to publish and the amount of technical assistance you need. Table 1 shows the popular 2D game engines and available SDKs.

Table 1. 2D Game Engines and SDKs

Conclusion

The new generation of Android-based tablets with Intel Atom processors; large, high-resolution displays; and OpenGL ES 2.0 acceleration have created a fantastic opportunity for app developers to exploit these devices by tapping into the wealth of 2D and 3D game engines, authoring tools, and middleware that have recently become available to provide more visually compelling user experiences on Android. Games and other apps that target this new hardware can stand out from the crowd by exploiting these new middleware and authoring tool solutions well.

Part 2 of this series will detail the best 3D game engine and middleware solutions available for Android tablets, including free, open source, and proprietary software. You’ll also discover which have native support for x86 Intel processors.

For More Information

• Get information about screen sizes and OpenGL ES versions used on Android devices.
• Learn more about Porting OpenGL* Games to Android* on Intel® Atom™ Processors.
• Displaying Graphics with OpenGL ES, a Google tutorial.
• Check out Game Engines for Android by Nathan Totura.
• See Intel® Demonstrates New Advancements in Mobile Graphics by Jerry Makare.
• See Intel for Android* Developers Learning Series #11: OpenGL ES* Support, Performance, and Features for Android on the Intel® Atom™ Processor by Clay D. Montgomery

About the Author

Clay D. Montgomery is a leading developer of drivers and apps for OpenGL on embedded systems. His experience includes the design of graphics accelerator hardware, graphics drivers, APIs, and OpenGL applications across many platforms at STB Systems, VLSI Technology, Philips Semiconductors, Nokia, Texas Instruments, AMX, and as an independent consultant. He was instrumental in the development of some of the first OpenGL ES, OpenVG*, and SVG drivers and applications for the Freescale i.MX and TI OMAP* platforms and the Vivante, AMD, and PowerVR* graphics cores. He has developed and taught workshops on OpenGL ES development on embedded Linux* and represented several companies in the Khronos Group.