I am happy to announce that I’ve just published my first mobile game on the Android Market. I have experimented with creating games earlier, especially targeting the PC platform, however I never accomplished to release such one due to lack of resources, especially in the domain of artwork. Hence I turned to mobile platforms as there even a one-man-show game can bring loads of fun time to the players. So here we are now: after loads of abandoned PC projects, here I have my first published game called “Pocket Soccer”.

The game itself is a reinterpretation of a classic board game called button football that is very popular in my home country. The key difference is that the game does not contain the many rules like the original one to provide a smoother and more fast-paced game-play. Each player has three buttons that they control by grabbing and throwing them in the desired direction. If one manages to push the soccer ball into the opposite player’s goal then he or she gets one point. The first one to reach ten points wins the match.

The game is turn based so each player has five seconds to move with one of his/her buttons. While, in my opinion, the game is more fun in two-player mode when two buddies can play against each other on the same device, the game also features a pretty smart AI with three difficulty levels. But that’s enough talk, maybe some screenshots say more:

Starting lineup in a match between Spain and Portugal.

Besides the possibility to choose between more than sixty countries to play with, the game has also other changeable assets like different soccer fields and balls. These also come with different physical properties that slightly change the game-play. While some of these assets come out-of-the-box, some others are only accessible if you unlock them. You can do so by playing and/or winning a number of matches in the various game modes. The prerequisites of each asset can be checked in the appropriate menu and you can also check your current accomplishments by tapping the statistics button in the main menu.

Another match between Peru and Uruguay. The player with Uruguay is about to move.

The game should work well on most Android devices. It requires only API level 4 (Android 1.6). I’ve mainly tested it on my Samsung Galaxy S, which of course runs it smoothly, but I tested it also on other devices like the Motorola Droid, ZTE Blade (San Fransisco) and Samsung Galaxy Spica. The game worked well on the Droid and especially smooth on the Blade, which surprised me a little bit for such a cheap phone. In case of the Spica, it already felt that the phone was not made for gaming, however, at the end I managed to optimize the game enough so that it provides a good user experience on that phone as well.

The main menu. You can scroll left and right to access the additional menu items and you can check your statistics anytime by tapping its icon in the bottom-right corner.

I tried to make the game look like the least possible like “programmer art” and I home I managed to do so. In order to have a fast time-to-market with my first game, I’ve chosen to use a game engine framework first, rather than writing my own. Having a lack of native game engines for Android, I settled down with AndEngine as it looked to have a fast learning curve and actually it has (other option was libgdx). While I’m not a great fan of pre-cooked solutions, AndEngine worked out pretty well with its native Box2D accessible over JNI, however, I also had some bad experiences. I will write another post about my development experiences with Android and AndEngine.

Summary

To sum it up, I managed to publish my first game and I hope you’ll like it. The game is ad supported, so you can download it for FREE from the android market:

Many things have changed since the first time the public put their hands on the first mobile phone device as these days the end user rarely makes their choices when buying a mobile equipment based on their telephony capabilities. In fact, nowadays these devices are one of the most popular entertainment platforms out there. The main problem for application developers is that these platforms tended to be very heterogeneous from point of view of hardware architecture as well as that of API support. Meanwhile things have changed. While the underlying hardware still varies a lot from device to device the work of application developers has been eased by having cross platform mobile operating systems and open standards. In particular OpenGL ES that is an embedded version of the popular graphics API. In this article I would like to talk about some of the big players of the mobile OS industry and about using OpenGL ES for creating impressive mobile applications.

The first version of the OpenGL ES specification has been released in order to provide a lightweight API for embedded graphics using a well-defined subset of the functionalities provided by the desktop version of OpenGL. While the specification is already out quite for a while, the wide adoption in the industry and the interest of application developers for it became strong only in the recent past. Currently, we have several mobile platforms that are bundled with 3D accelerators and provide a set of features via OpenGL ES that makes developers capable of creating games that weren’t possible even on desktop platforms about ten years ago.

Going 3D on mobiles

Those who know me, know that well that I was always interested in graphics, especially when using it for entertainment purposes. In particular, I was about to develop video games since the first time I’ve put my hands on a computer. This is no different now as well as now I’m writing about OpenGL ES and mobile platforms because I got interested in creating games for mobile phones.

As I’ve already mentioned before, the problem with developing for mobile equipments is the variety of hardware and software platforms that they are built on. As being somebody who is already familiar with desktop OpenGL, having OpenGL ES in the tool-set already eliminates some of the burden that I must face with.

Also when talking about application platform things have also changed a lot. Nowadays, we have just a few big players in the mobile OS industry thus easing the work of the developers. More precisely, if an application developer plans to go mobile and would like to grab the biggest market audience, can limit their efforts on the following platforms:

• iPhone OS – This is the one that drives Apple’s iPhone mobile devices as well as the iPod Touch. It provides an application platform similar to that Mac developers got used to. It can be said that this platform is the most popular in the industry, especially when dealing with gaming applications.
• Android – This is the newest player in the field, brought by Google. While it’s a newbie in the industry it already captured the attention of tons of developers. We can say that currently Android and iPhone are dictating the direction of mobile entertainment.
• Symbian OS – Symbian has the largest share in most markets worldwide, still not that popular in the mobile gaming industry. It is the operating system running most of today’s Nokia phones.
• Windows Mobile – Microsoft’s product built on Windows CE, the company’s embedded operating system.
• RIM Blackberry OS – Operating system primarily designed for the business industry.

While most of these mobile operating systems are built on the same design conceptions it is very difficult for the developer to create cross-platform applications for all these platforms as they vary on the language and tool-set support that minimizes the possibilities for code reuse. Unfortunately this is against the one of the most important rule of mobile development as to maximize portability.

It is not 100% true that there is no way to provide optimum portability for all these platforms, but if we choose this direction we are limited to two possibilities: cross-platform Java applications and web-based applications. While these seem to be excellent alternatives to native programming of the platforms, they severely limit the developer in creating applications that fully take advantage of the underlying hardware. This is when OpenGL ES comes into picture as all these platforms have API support thus providing at least some form of code reuse possibility when dealing with entertainment applications.

Now, I would like to continue with talking about the two platforms that I’m most interested in.

iPhone OS

I started to get involved in iPhone game development because one of my friends pushed me to after seeing the great success of his brother-in-law, zhooley who had some great titles. Currently I don’t have a Mac yet to develop on, but already read some stuff about iPhone development. This is where the following information come from.

iPhone is currently is the most important platform for mobile application developers. It became such an important factor in the industry thanks to Apple’s AppStore. Previously there was little to no way for the end users to extend their mobile software base so easily. While this is good for the end user, it is maybe even better for application developers as AppStore provides them quite a large market audience.

The secret why iPhone is an excellent gaming platform lies in the palette of features that the phone hardware and the software frameworks provide. Just to mention the most important ones:

• Touch screen control with support for multi-touch events capturing the movement of up to five fingers.
• Three accelerometers for tracking the spacial movement and direction of the device in all axes.
• MVC inspired GUI framework for enhanced productivity.
• Support for several industry standard APIs like OpenGL ES, OpenAL and much more.

But that’s enough from the general speaking, let’s see what’s about OpenGL ES support on the iPhones…

As far as I can tell, not being an iPhone owner, the graphics hardware bundled with the mobile comes in form of PowerVR accelerators: MBX and SGX.

The PowerVR MBX has OpenGL ES 1.1 support, that is roughly equivalent to OpenGL 1.5, running a tile-based deferred renderer that is suitable for most 3D applications. That means it has only fixed function capabilities, however that is usually enough for most mobile applications. Also note that it has very limited amount of texture memory of 24MB.

The PowerVR SGX is a more powerful processor that also supports OpenGL ES 2.0, roughly equivalent to OpenGL 2.0, but has optimized fixed function shaders that provide flawless backward compatibility for OpenGL ES 1.1 applications.

The most important thing is still that all iPhones are able to do floating point maths natively and efficiently that is an important factor when dealing with OpenGL applications as the usage of the fixed point types can be quite a burden for developers, especially for those migrating from desktop development.

Additionally, the OpenGL ES implementation on iPhone provides some nice extensions like GL_OES_framebuffer_object, GL_OES_compressed_paletted_texture and GL_OES_point_sprite. Also, thanks to the iPhone simulator that comes with the SDK it is easy to test the application during development without an actual device. Still, one important hint to mention is that the iPhone simulator has different OpenGL ES capabilities than the actual hardwares and also the performance characteristics measured on the simulator should not be taken as valid measurements because the simulator does not really simulate the graphics hardware but only the software platform.

iPhone development is done using the Cocoa API and preferably Objective-C, however C, C++ and Objective-C++ can be also used for development. One just has to interface somehow the Cocoa API and the rest can be done almost in any native programming language. That is one of the key advantages of the iPhone platform that one can develop native applications and no need for Java or web-based solutions.

While iPhone may seem to be a perfect choice for mobile game platform, we should not forget about one big disadvantage of it, in particular that one cannot develop legal iPhone applications without owning a Mac.

Android

The Android platform was suggested by one of my workmates who just brought a Droid. That phone is actually a device capable to compete with the iPhone from both features and performance point of view.

Android is the big hit of the last year and my forecast is that it will be one of the most relevant platforms of the upcoming years. Google adopted the idea of Apple and they also created an open market for the softwares that the end user can easily download and install on their devices. This is the AndroidMarket that can easily become a powerful competitor of the AppStore.

While, as I said earlier, the Motorola Droid, as an example, does support about the same feature set that makes the iPhone an excellent gaming platform, this cannot be said about most of the phones running Android on them. This is maybe one of the biggest disadvantages of the Android platform. However, we can take this also as an advantage as it makes it possible for more phones to adopt this operating system.

As the Android operating system is running on various phones from different vendors with different hardware capabilities, there isn’t too much to talk about the graphics hardware capabilities except that some devices not just don’t have a graphics accelerator but they also lack of floating point support. This is another disadvantage as it forces developers to stick to fixed point math in their OpenGL ES applications to maximize portability or they have to maintain two different rendering paths.

Originally, Android supported only OpenGL ES 1.0 that is roughly equivalent to OpenGL 1.3. However, since NDK r3 there is also OpenGL ES 2.0 support for Android as well. The feature set here varies much more from both hardware point of view and extension support.

Development for Android is done in Java using a proprietary SDK for accessing the Android API. The SDK comes with a simulator that works fine, except the long initial boot time that I was really surprised about when first trying it out.

One advantage of the SDK that it can be used in virtually any operating system so application developers can work on either Windows, Linux, MacOSX or other platform. There is also a nice Eclipse plugin that makes application development for Android even easier. That’s why I started with this one.

Just to illustrate how easy to put together some working demo with a good SDK, I’ve created a simple box rotating app to demonstrate OpenGL ES usage on Android. From installation till having a working application it took no more than two hours. You can find the download links for both the source code and the binary release at the end of the article.

Why mobile games?

I am a person who was, is and will be interested in developing computer games. Previously, I was working with desktop platforms and at the time when I was 10 years old it was satisfactory to put together some simple 2D game but not now.

I had always planned to create a state-of-the-art game engine and use it for some game, like most people like me do, but the efforts of one is simply unsatisfactory to compete with the players in the industry out there. Even if I feel the capability to be able to write such an engine but it would take that much time that I simply don’t have since I am working. Even if I would manage to accomplish it in a year or two then the problem with content creation comes into picture. For an AAA PC game content creation takes several times more than the actual programming and here I even lack the knowledge to achieve it. On the other hand mobile game creation is a much shorter process when you can get to actual results in a matter of weeks that is far better compared to PC game creation.

Also, I would never use third party game engines, except some basic libraries like OpenGL, a physics library and things like that because otherwise I wouldn’t feel the results being my own creation.

Having game development as a hobby works well during high school and university but it gets quite difficult after you are out there in the world having a job and responsibilities. Maybe I should have been already taking my time before to develop something concrete for PC but, as most fellow hobbyist know, you usually end up having hundreds of unfinished projects.

While I would never forget about desktop platforms and I will actively keep myself up with the evolution of the industry, mobile application development opened another world for me where I can unfold myself.

HelloAndroid Demo

Source code: helloandroid_src.zip
Binary release: HelloAndroid.apk

Previously I talked about how one can easily take advantage of multiprocessing using OpenMP. Even if the C pragmas introduced by the parallel programming API standard is very straightforward for simple programs, it simply doesn’t fit nicely in a complex C++ application that is built from the ground with the OOP in mind. To smoothly introduce OpenMP into such projects one need higher level constructs that hide the actual implementation details. This is the first article of a series that will try to provide reference implementations of such an abstraction. First, we will start with synchronizable primitives that try to reflect the functionality provided by the “synchronized” statement of Java.

This article is highly inspired by an article written by Achilleas Margaritis and is mostly equivalent with his thoughts. My article tries to provide a portable reference implementation of a slightly modified version of the trick presented by Margaritis that uses OpenMP as the multiprocessing API back-end.

Motivation

According to the OO paradigm, classes and consequently objects provide an abstract interface to the underlying internal data or services of the modeled entity or entity class. When it comes to parallel programing we should provide facilities to enable concurrent access to shared resources that are in this case objects. Using plain OpenMP can be satisfactory, however when used extensively the OpenMP pragmas and API function calls introduced can greatly affect the readability and the maintainability of the code. Nevertheless, there can be platforms that use other APIs for handling race conditions. It is obvious that we need to encapsulate these facilities and provide an abstract tool-set instead.

Implementation

The very first building block of such a framework can be a mutex class that provides mutually exclusive access to certain resources. In the world of OpenMP this should look like something similar to the following:

class Mutex {
public:
    Mutex() { omp_init_lock(&_mutex); }
    ~Mutex() { omp_destroy_lock(&_mutex); }
    void lock() { omp_set_lock(&_mutex); }
    void unlock() { omp_unset_lock(&_mutex); }
private:
    omp_lock_t _mutex;
};

This seems already enough for us to make our Java-like “synchronized” statement, however we would like to create a framework that makes usage as easy and safe as possible. In order to get closer to this goal we apply the RAII (Resource Acquisition Is Initialization) design pattern to create our lock class:

class Lock {
public:
    Lock(Mutex& mutex) : _mutex(mutex), _release(false) { _mutex.lock(); }
    ~Lock() { _mutex.unlock(); }
    bool operator() const { return !_release; }
    void release() { _release = true; }
private:
    Mutex& _mutex;
    bool _release;
};

Our goal is to provide an inheritable interface for such objects that needs synchronization. However, this step has to involve severe considerations regarding to the provided interface as we explicitly need to conform to the following requirements:

• The interface shall not expose the interface of the underlying synchronization primitive, in our case the mutex class methods.
• The interface shall be available only to the synchronizable objects but not for the external world as we would like to not just hide the implementation details of our abstract entity but also prevent the users to synchronize our objects as it should be the responsibility of the object itself.
• The interface shall expose methods which are less prone to name collision, for convenience.

If we take care of the presented conventions we end up with an interface similar to the following:

class Synchronizable: protected Mutex {
protected:
	void enterSyncBlock() { this->lock(); }
	void exitSyncBlock() { this->unlock(); }
};

Now we are almost at the finish line. We just need to inherit this class in order to have the needed facilities for an object that needs synchronization. However, using this interface directly is not the most comfortable and safe. If we would like to have a Java-like “synchronized” statement we have to call for additional help. Fortunately, we have our not so well respected C macro language coming to rescue us as we can use it to make some pseudo-language extensions. The simplest way to define our new statement is using the following line:

#define synchronized(obj)  for(Lock obj##_lock = *obj; obj##_lock; obj##_lock.release())

From now, we can really use object synchronization in C++ as easy as in Java, we just need the following syntax in the method of our shared objects:

synchronized(this) {
    // some code that needs synchronization
}

Now it is clearly visible how handy the RAII pattern became in our case. Beside that it is now very straightforward to use this statement it provides additional benefits:

• It makes the code more readable and as a result it is easier to maintain.
• No need to call inconveniently named methods and use lock variables.
• The synchronized code has it’s own scope inside the code.
• It is exception-safe as the mutex is unlocked upon destruction.

Additionally, we can also take advantage of the inherent problem in C++ regarding to multiple inheritance. If we inherit our object from other two synchronized objects then using a simple type casting we can explicitly specify which ancestor we would like to synchronize in a particular block. Also, to ease this we can define our synchronization statement instead of the Java-like one using the following line:

#define synchronized(cls)  for(Lock obj##_lock = *static_cast<cls*>(this); obj##_lock; obj##_lock.release())

In this case we pass the class name instead of the object pointer this. Using this later construct we can easily specify the correct ancestor that we would like to synchronize in case when we deal with multiple inheritance situations. Personally I prefer the later syntax as it is much more customized for C++ use cases.

As from now we don’t need a direct interface for entering and exiting our synchronization block we can simplify our synchronizable interface to the following chunk:

class Synchronizable: protected Mutex {
};

This is enough from now to provide the facilities needed for a synchronization block but still complies to the requirement that we would like to hide the synchronization primitive related details.

Beside this, Jörg came up with the idea today to replace the for loop in our macro with a single if statement. This seems reasonable as we don’t have to sacrifice any scoping and safety related benefits of our framework. This simplifies our lock class to the following:

class Lock {
public:
    Lock(Mutex& mutex) : _mutex(mutex) { _mutex.lock(); }
    ~Lock() { _mutex.unlock(); }
    bool operator() const { return true; }
private:
    Mutex& _mutex;
};

This definition of the lock class is satisfactory if we redefine our synchronized macro to use an if statement instead:

/* Java-like synchronized statement */
#define synchronized(obj)  if (Lock obj##_lock = *obj)
/* alternative synchronized statement to support multiple inheritance */
#define synchronized(cls)  if (Lock obj##_lock = *static_cast<cls*>(this))

Thanks to the useful comments we even managed to further optimize and minimize the support code needed for our new pseudo-language extension.

Conclusion

We have seen an example how one can implement an easy to use synchronizable interface for C++. Also, we’ve provided a concrete implementation that is based on OpenMP. This library is still far from an API that provides all the necessary constructs that one needs for using parallel programming in their C++ projects, however we made our first step and I will recap on the subject in subsequent articles to further extend this framework.

Credits go to Achilleas Margaritis whose article inspired me to write mine and to Jörg for the useful improvement ideas.

Full source code

Language: C++
Platform: cross-platform
Dependency: OpenMP
Download link: omp_sync.h
Comments: In order to use it as it is, you will need a C++ compiler supporting OpenMP like GCC 4.2 or Visual C++ 2008.

Those who know me know it well that I am not a big fan of languages which produce managed code. In this article I would like to cover the reasons behind my skepticism. Also I would like to dispel the myths around such languages and try to prove them with facts (we will see how well I manage to achieve this). If you disagree with me, you’ll most probably hate me because of making this post but please, respect my personal point of view.

As I’ll mostly talk in this post in general about managed code I would like to emphasize that I have worthwhile experience only with Java and have barely used C# and other managed languages so my primary arguments maybe apply directly only to Java but still would like to present my arguments in general as they still apply in some way to all such languages.

Without the intension to insult anybody, I would like to start with a citation from one of my friends, who often says that “Java is just a pseudo-language”. Mostly I agree with him and it’s not just because I have my not so delightful experiences with the language but also because it introduced a brand new way of coding style that is a complete nightmare for an old-school coder like me. As I don’t want to start another religious war, I’ll stop my preposterous arguments here as I would like to prove my concerns with facts that nobody can disclaim.

“… nowadays Java is almost as fast as native code…”

This used to be a common myth in the last few years. For those who are still arguing by shouting this loud on forums and blogs, I would like to draw their attention to the fact that Java is still an interpreted language no matter if the latest JVM versions do some on-the-fly compilation of the code and as such it is inherently slower than any language that generates native code.

As my hobby is computer graphics I have to talk a bit about the case of PC games. Have anybody seen a game fully written in Java or any other interpreter based language that produces state-of-the-art graphics which competes with the best professional games and it also provides the same performance? I think not, and this is not a coincidence.

GPUs are getting more horsepower in a much faster pace than CPUs. That is what resulted in the batch crisis lately. It’s already happening for several years that the CPU is simply not powerful enough to feed the GPU with enough data in complex real-time rendering situations. There have been already tons of different software and hardware technologies which already targeted this issue a long time ago but as a perfect example that is the reason which resulted in the appearance of the completely redesigned DirectX 10 API and which emerged the need for a cleaner architecture for OpenGL as well. That’s why there are no advanced games written in interpreted languages as they waste those very valuable CPU cycles which would have great benefits otherwise.

“… Java has a much greater expression power…”

I tend to agree with this one. As these languages are interpreted by a virtual machine they provide great room for such features that would be impossible or simply very inefficient in a native language. That’s why one of my favorite programming language is PHP as an example. It is even more flexible then Java, for example, but never forget that PHP never meant to try to replace native languages as instead it is used in a totally different domain.

There are many language features that are not available in native languages but they weren’t left out unintentionally. Their lack is primarily justified by the fact that most of these features are rather inefficient and they simply not fit in the philosophy of a performance oriented language like C++. However, the most important ones like reflection, delegates and most OOP related facilities are present for example in Delphi, which is one if not the best OOP language that doesn’t make too much trade of between flexibility and run-time performance. Also, even if most of these features are not present in C++, Objective-C and other popular native languages, they can be made available with a little programming knowledge in the particular language (maybe not just little).

“… you don’t have to care about resource deallocation as there is the garbage collector…”

This is one of the most annoying “features” of managed code based languages. I understand that the prevention of memory leaks can have a great impact on development effort, however the unpredictable behavior of garbage collectors is simply unacceptable in certain situations. The issue of lost references has been already addressed in almost all native languages with the use of reference counted objects so I simply don’t get it why is this still an important feature. For efficient resource management you need much finer control over the time and way how resources are released.

“… you just have to care about the basics and Java will make you the rest…”

While I strongly support the idea of COTS, the way how Java and friends interprets this concept is simply unacceptable for me. Sometimes you need to know what is going on under-the-hood. This is basically the same issue like that of the garbage collector. Beside that, according to my personal taste, I don’t like if the compiler tells me how to do a particular thing. I rather do it in my way and even if I tend to agree that the compile time static analysis what the Java compiler does can be very valuable in some situations, simply denying code generation even in the case of a very minor semantic problem is simply makes me angry.

“… Java eliminated almost all unsafe features inherited from C++…”

This is one of the things that hurts me most. While Java really managed to achieve this, it sacrificed flexibility, ease of use and the fun of programming to make this possible. One such removed feature is operator overloading. I love them! As an example a linear algebraic library, which is often used in graphics programming, or the string library is not just makes the coding more natural, it eases the reading of code which is written with these in mind and that greatly effects the maintenance cost of a particular software as the code is read ten times more than modified. Java in this domain seems too verbose for me and it is much harder to read the long method invocation chains, that is not just used to be used by the developers, but is the recommended way how to code in Java.

This post already ran wildly long so I will close the topic for now. As a conclusion, I have to point it out that this article presented the subject from a rather subjective perspective at the end. Sorry for that, I will recap on the topic in a later post where I will try to be more detached and I’ll present actual use case examples but for now, this is all that came from my heart so please, don’t be very harsh with me if I was very biased. I hope you enjoyed the article anyway.