Up until now, the majority of Android devices have been mobile phones. That is changing. A large number of tablet devices are coming to market powered by the NVIDIA Tegra 2 processor. These devices offer new user experiences and a chance for developers to engage with users in new and exciting ways. We are encouraging developers to prepare their applications and games for these new devices.
Many tablets use screens that have physical sizes larger than mobile phones. They range from diagonal widths of 5" to 11" and over.
While the physical size of a device is not a huge concern for developers, you should keep it in mind. Be sure to include some logic in your application so that a user is not presented with a stretched or crammed experience. For instance, adjust the font size such that fonts are not stretched over a larger screen or too tiny to read on a small screen.
For a more in-depth discussion of screen size, please check the NVIDIA GameSauce 2010 presentation.
Screens are not only getting physically larger, many of the smaller screens are packing more pixels into the same space. This is of particular concern for UI elements that can be incorrectly aligned and scaled if screen densities are not considered. We suggest studying Google's guide to screen densities and note the new extra large screen size used by tablets.
Along with larger screen sizes come larger screen resolutions. For 3D applications resolution impacts fill-rate, the amount of shader processing, and ultimately the performance of the application.
Screen Resolutions and Pixel Counts
|Name||Width||Height||Total Pixels||Increase from 480p|
So for example, if there are two devices with the first using 480p and the second having a screen resolution of 1280x800, there are almost three times as many pixels to render on the second device. If your 3D application only averages 40fps on the first device, the framerate will likely fall under 20fps and deliver a poor user experience on the second device.
Developers should profile their applications using tools such as PerfHUD ES and perf (or oprofile). Look for hot spots in your code that you can optimize. Further, provide fallbacks in your code; should framerate get too low, fallback to a less complex processing option. Finally, look at your artwork; is there a way to optimize the number of objects or polygons being rendered by splitting or combining assets? Can you batch render calls together?
If you have a Tegra 250 Developer Kit, you can start running Android at different resolutions now. Check this guide for details.
Textures & Texture Compression
Tegra 2 supports uncompressed and compressed textures (DXT1, 3 & 5 and ETC1). Which texture compression to use is a fairly subjective question but we suggest:
- If trying to minimize the size of your application (and thereby decrease your users' bandwidth usage), use DXT for all textures.
- If size is less of a concern and your application has less than 25MB of assets, use ETC1 for opaque textures and uncompressed textures for those with alpha.
- If your application has 25MB or greater of assets, use DXT for opaque and alpha textures.
Many developers will be familiar with DXT textures but should you need tools and further details, please check:
- NVIDIA GPU Accelerated Texture Tools
- NVIDIA texture tools for Adobe Photoshop
- NVIDIA legacy DXT tools
Texture Compression by Vendor
Unlike the desktop and console space, mobile GPUs do not share a common texture compression format that supports textures with an alpha channel. NVIDIA's Tegra GPU uses much technology from its PC cousin and so supports DXT texture compression. DXT was developed by S3 Graphics about 10 years ago and became the de facto industry standard when Microsoft used it in DirectX. All vendors in the PC graphics and game console arenas use DXT. Unfortunately the mobile space is different as shown below.
|Mobile GPU||TC Support Without Alpha||TC Support with Alpha|
|NVIDIA Tegra||ETC1*||DXT1, DXT3 and DXT5|
When building your application, you should take this into consideration and build appropriate resources for the different mobile GPUs.
* ETC1 is part of OpenGL ES 2.0 so is supported by all OpenGL ES 2.0 GPUs but unfortunately does not support an alpha channel so can only be used for opaque textures.
Threads are key to responsiveness in Android (see for Google's discussion for example). For both Java and NDK (native C/C++) based applications, Android provides mechanisms for spawning multiple threads. In Java, generate threads through the use of classes such as GLSurfaceView and Thread. When using native code, the NDK supports PThreads.
For more information, please see:
- NVIDIA's GameSauce 2010 presentation discussing some of the caveats and "best practices" for using threads in NDK applications.
- Google's "Writing Zippy Android Apps" from Google IO 2010
Android mobile phones and are held in a natively portrait manner. The accelerometer in the phone is aligned with the Y axis along the long side such that when you hold the phone for normal use, Y is about +9.8. Similarly, if the phone is held in a landscape fashion, X is about +9.8.
Many of the Android tablets are natively landscape and so have a different accelerometer alignment.
Due to "Y being up" but "up" being different for different devices, developers need to take the device's default orientation into account when using the accelerometer; you cannot assume that if the device is in a portrait orientation Y will be +9.8.
For more information and example code, please see the Android Accelerometer Whitepaper.