So you have an Android™ Native game and wondering what does it takes to bring your game to BlackBerry® 10 for the launch of the platform? You will be pleasantly surprised how much easier it is to develop a native game using the BlackBerry 10 Native SDK. I have been there myself; as part of the Gaming R&D team, I extended the Open Source and cross-platform Gameplay3D framework support to Android using the Android NDK. In this post, I am going to share my experience working with the two platforms side by side from a game porting point of view.
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.
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.
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_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.
On the other hand, the BlackBerry 10 Native SDK provides you with a much simpler application model — it runs inside a native QNX process. BlackBerry 10 Native SDK games receive the application lifecycle events through the BlackBerry Platform Services (BPS). To start receiving the events, the BPS system needs to be started at the game startup. The BPS events can be polled in the run loop similar to the Android event handling mechanism and does not require a callback registration to retrieve the events. Once an event is received, handling is straightforward and maps nicely to the Android NDK Game 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.
Registering a callback function to the
onAppCmd and polling the
eventQueue for events lets you receive all the input events that the game or app receives. Similar to the BlackBerry application life cycle events, screen events can be obtained through the same BPS service and is straightforward to use.
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.
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.
Android NDK game’s internal and removable external data paths can be obtained from
externalDataPath variables respectively in the native_activity.h.
In a BlackBerry 10 Native SDK game, the files are copied inside the application sandbox under the app/native/ folder and the path for the game itself can be found with the
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.
BlackBerry’s team of experts is here to help you discover how to get most out of your BlackBerry smartphone.