ARM Community: Porting Games to Multiple Devices Made Easy - ARM Community

Many times on my travels through the world of embedded GPUs I have come across someone asking “How easy is it to port my game to Mali™?” Well.....actually it’s not difficult at all, and this is reflected in the ARM® Mali™ Ecosystem. Let’s start by looking at the Ecosystem and its growth. Having now reached a massive half a million activations a day, Android is where it’s at! Especially now the Samsung Galaxy S2 has hit the market. The S2 is a dual core ARM® Cortex™ -A9 and an almighty quad core Mali-400MP.


Here in ARM’s Media Processing Division we have been diligently testing games on devices and have come to the conclusion that when you compare like for like with Android devices the pass rate is an equal affair. What I am saying here is that we found that all GPU architectures rolled in at virtually the same pass rate, within 2% of each other, on all the 300+ games we tested. So why is that a good thing? Well it means that a vast majority of developers are already writing scalable games across multiple platforms to maximise their profits, and also tells me that there is currently a level “Ecosystem” playing field.

Ok, let’s dig a little deeper into the potential challenges we’ve identified around porting and how they can be overcome. Firstly, if it seems that the game is a non-starter, this can be down to differing versions of Android, or even customised versions for specific devices. Differing platform configurations are also a concern, i.e. memory constraints, screen resolutions, control mechanisms, etc... Ensuring your game runs across all these platform configurations is a topic all on its own and I will cover this in another blog at a later date.

Next, exclusivity of certain games for certain devices, which is usually for a set period of time (six months for example), means the game will not run on any other platform.

We have found that, once past these hurdles, there is much that we can do to help the developer to get their game up and running. It may be that the game is trying to use an EGLConfig that is not supported by the device, many configurations are available and no one platform supports them all. The solution is simple, we have some sample code that any developer can take and implement to select the correct EGLConfig for your device, the code and documentation is available on malideveloper.com here.

And then we hit the most common issue, texture compression fragmentation. The game will run, and the geometry will be rendered, but with blank textures and with various shader effects being applied.


There are many texture compression formats available depending on the GPU architecture; Mali uses the Khronos adopted Ericsson Texture Compression (ETC) standard, in fact all the current OpenGL® ES 2.0 GPUs support ETC1 as this is a core component of the Khronos standard, so developers can choose to use ETC1 on all platforms if they wish. It’s a 4-bits/pixel texture compression and is the most convenient compression for game developers as it gives the best compromise between compression and visual quality. “What about the alpha channel?”, I hear you say. This is true; ETC1 does not support an alpha channel as is. However, you can use two textures to achieve RGBA, then extract and compress RGB and A into separate channels. Again we have created sample code, which is available on malideveloper.com here.

We are now starting to see a move away from proprietary texture compression, and here are a couple of examples. Firstly, let’s look at what Google are recommending on their Android Developer site to use for texture compression, and yes you guessed right....ETC (see here). There is also an interesting comment in the Apple Developer Guide, letting the developer know that their hardware may not support the current texture compression in the future. It advises developers to check for support and to use uncompressed textures if it’s not available (see here)....therefore keeping many platforms available for the developer with little or no changes to their game.

I think it is also worth noting how developers are using the 50MB download limit on Android to their benefit. Game data can be very large, in the region of 100–600MB of data depending on the game, and this can be multiplied at least 3x to support all the Texture Compression Formats. Therefore Developers are only putting the install file on the Android Market for download, this will be small (typically 2-5MB), when this is installed on your device it interrogates the device to see what graphics hardware you have, it then goes off to the developers own server and downloads the relevant data pack for your device with the correct texture compression. This allows developers to support multiple GPU architectures with the smallest download needed.


All in all, developers see porting their games to multiple platforms as a trivial task. They are more concerned with the performance of the devices on the market, which allows them to push the boundaries of both smooth gameplay and incredible graphics. To this end it is great to see a company like Samsung wanting to use the superior performance of the Mali-400MP to create the most visually stunning graphics in any handheld today....and this is only the beginning.

Simon Hickman, Ecosystem Partner Manager, Media Processing Division, ARM. Simon has been around at ARM for more than 10 years now, remembering being a part of the team that ported Quake2 to the ARM926, then moving into management leading the Applied Systems Engineering team, and on to a Marketing role in the Mobile Computing team. Simon is now enjoying working with some of the most creative Game and Game Engine Developers throughout the world as MPDs Ecosystem Partner Manager, ensuring their content is running optimally on the many devices coming to the market with ARM Mali GPU technology.