Android to BlackBerry Game porting guide and Tips: Stakes and Opportunities for Developers

This is a guest post from RIM Blackberry (the Gaming R&D team).
Connectikpeople has decided to publish this post, as part of, the upcoming BlackBerry 10, operating system.

Tools: as an Android NDK developer, the first thing you will notice is that the BlackBerry 10 Native SDK is an Eclipse based, fully Integrated C++ Development Environment, as opposed to only command line tools provided by the Android Development Tool (ADT). The IDE comes integrated with console, debugger and several BlackBerry 10 OS specific optimization tools. If you are command-line and scripts kind of person, you can use the command line tools available in the $QNX_HOST/usr/bin folder under the installed directory.

Programming Environment: Android NDK allows writing C/C++ code as part of a Java® application in a crude way. Occasionally, the native code is required to call the Java APIs to accomplish certain tasks. On the other hand, the BlackBerry 10 Native SDK provides you with a pure C/C++ environment that works nicely with Open Standard and Open Source software.

Application Lifecycle: Typically, an Android NDK game will comprise of a NativeActivity, and the OS provides the Activity with a native handle to the Android Java App android_app* through android_main() function. The handle can then be used to retrieve the Android application life-cycle events in native. Registering a callback function to the android_app*‘s onAppCmd and polling the eventQueue for events lets you receive all the application lifecycle events.

Graphics and Windowing : Both Android NDK and the BlackBerry 10 Native SDK allow access to OpenGL ES 1.x and 2.0, and that makes the game rendering code run seamlessly on both platforms. However, OpenGL ES is ultimately rendered on a native window surface that will be displayed on the screen, and the way to acquire them is different on the two platforms.

On Android, when an application is initialized, a native window is created for the default configurations by the underlying JVM. The native window handle can be obtained from the android_app* application state available through the call back function associated with the onAppCmd. The native window format can be chosen using the ANativeWindow_setBuffers utility function as per the needs of the Application.
On BlackBerry, applications have access to the BlackBerry Platform Windowing System that facilitates creation of Screen Contexts (represents a connection to the windowing server) and Screen Windows (represents an OpenGL ES renderable surface). First, a screen context is created that enables the native windows to be created and lets the application control some of its properties such as pixel format, size, location, etc. Once a Screen Window is created, the EGL API can be used to render the content into the native windows for display.

Audio

Android supports and recommends OpenSL, whereas BlackBerry supports its arguably more widely-accepted cousin OpenAL. Currently, BlackBerry SDK does not support OpenSL, and it is worthwhile writing the audio code using OpenAL. Once ported, you can use the open source implementation of OpenAL for Android and use the ported audio code for Android.

Video

Many games add cut scenes to engage the players in a story mode, and unfortunately in Android NDK there is no straightforward native video API out of the box. Developers porting their games to the BlackBerry 10 Native SDK will be very happy to use the native video multimedia API (mmrenderer) to play a video inside their games.

Reference code: if you are looking for reference code and design ideas to make your game cross-platform, take a look at the Gameplay3D framework. It is an open-source and cross-platform gaming framework that currently supports BlackBerry, Android, iOS and desktop environments.

A detailed Android to BlackBerry Game porting guide will be available very soon at http://developer.blackberry.com.