Category Archives: Android

Conduit – A NativeScript RealWorld Example App

Lately I stumbled over a really cool project – The RealWorld full stack demo tutorial by

I was looking for some framework/library tutorials and found that site and source giving away a real-world scenario tutorial with source code and demos for so many technological stacks. I was impressed by the amount of implementations and their quality. An easy way to see frontends and backends work out in a real environment and not just some “Hello World” ^^

So, I went ahead and did my part 🙂 I contributed a NativeScript (Angular) RealWorld Example App!

Based on their starter kit I created a full stack mobile app illustrating how to develop a NativeScript app connecting to a service backend providing and pushing data.

It has been implemented against the API & specification and works with a productionready API provided by as well as any other backend URL, as you can change the URL in the app itself. By that, you can check your own backend implementation.

You can go and checkout the source at or try the open beta app on the Get it on Google Play

The spec & API has been implemented completely to illustrate all different types of models, plugins etc. But I will continue to improve on the translations, UI, styling and additional options custom to the mobile environment.

I hope this helps as a real-world tutorial showing how a real app could work. Nevertheless, this codebase does not claim to be the best-practice or anything similar in that direction but just one way of achieving a result.

There are no Casual Games…

…but Casual Gaming (and Casual Gamers)! Wait, wait… Before you stop reading and ask yourself why I would make such an offensive proposition, please hear me out.

My Origin
I have a very tense relation to the terms Casual and Core Games that found on three things: 1) I am getting older and my best “Gamer” times are over ^^’, 2) I develop Browser Games and 3) I develop in Java! A very bad combination to go into a Game Developer discussion… trust me!
I am a Gamer for over two decades now, started with Pong and played a high percentage of every mentionable game ever made. Studying Computer Science and developing Games was a reasonable step and I like what I am doing now, I am good in what I do (yes, I am ^^), developing Games and I am proud of what I achieved until today. But nowadays if I mention that I develop Games, I get asked:

  • “Oh, very cool. What Games?”
  • “Browser MMOs”
  • “Ahhh…*pause*… Casual Games!”

Even with swallowing the bitter taste of that sentence I somehow feel unvalued for being part of one of the largest Browser Games around, over four years old, still growing and established way before Facebook. A massive simultaneous multiplayer game, relying heavy on PvP, time intensive and based on a very technical Story. All features that are normally related to so called “Core Games”. But if a Browser Game features such elements why is it that the term “Browser Game” is instantly related to “Casual Game”? And why in general is “Casual Game” leading to the idea of “not a real game”?
In my specific case Browser and Casual is not the only evil term. The dialog above often continues as follows:

  • “Why do you think I develop a Casual Game?”
  • “It’s in the Browser… probably Flash.”
  • “I am Java Developer.”
  • “I think you said you develop Games. How can you develop Games in Java?”

But that is another story I will cover in another post ^^’.

My Problem
Another thing that leads me to my “new” thinking was the evolution of my own gaming habits. As mentioned, I am a Gamer, a Core Gamer you would say, played Games from Wolfenstein 3D to Call of Duty: Black Ops, from Half-Life over CS to TS2, from Zork to The Whispered World. I owned and own Handhelds, Consoles and PCs. I spent ages playing through games each day after school, alone or with friends. But over time my gaming habits changed through studies and now a whole lot of work. I am still a Gamer, just tested the newest Crysis 2 and Bulletstorm Demos… but the actual gaming sessions changed!

I am part of the working community now. Most of the day I am sitting at my work desk and if I get home I have some commitments to do or just want to get some peace. Nevertheless, my Civilization is teasing me to conquer the world, while Snake is asking me to finally complete the Mission, besides Kane & Lynch still arguing. Everything becomes a Quest that Puzzles me and I get Angry like the Birds outside my Windows (couldn’t find a transition to my iPad here ^^).
So, every evening I really have to decide what I do and IF I play. And even if I play, the time a playing session takes reduced a lot nowadays. For example, I played Plants vs. Zombies as well as Dead Space. I played Mirror’s Edge as well as Angry Birds. All four games would be categorized into Casual and Core Games, but the way I played them somehow did not fit the definition. I played Plants vs. Zombies for hours straight but Dead Space actually in 15-20 minutes chunks until the end (not only because it was scary). Mirror’s Edge I played through in one session but Angry Birds just 15 minutes some evenings.
Now, with the advent of all this classification that somehow does not fit my overall love for games of every type that “entertains” me, I questioned myself: Am I doing something wrong? Or is the classification not practicable?

The Definition
With that many inconsistencies in my general understanding of Browser and further more Casual Games I tried to find a conclusive definition. During the search of a definition I had to notice that I never read so many different ways of defining something, especially as most definitions come down to attitudes of the writer. Because of that, let’s start with a “not so ideal” example from the Urban Dictionary:

Casual games are any kind of game that is over hyped and over rated or just the exactly same thing as a previous version that was over hyped and over rated, these games are known by gamers as “crap” because even with all the perfect scores the games still have mediocre graphics and shitty plots that casual gamers think are good. Usually the only thing that makes a casual game not-total shit is the multiplayer; otherwise these games would get ratings lower than dirt.
With shitty graphics and a generally horrible campaign mode, the halo series is the indisputable king of casual games.

But all jokes aside, for a more serious definition from the IGDA Casual Games SIG from 2005/2006:

The term “casual games” is used to describe games that are easy to learn, utilize simple controls and aspire to forgiving gameplay. Without a doubt, the term “casual games” is sometimes an awkward and ill-fitting term ““ perhaps best described as games for everyone. Additionally, the term “casual” doesn’t accurately depict that these games can be quite addictive, often delivering hours of entertainment similar to that provided by more traditional console games. To be sure, there is nothing “casual” about the level of loyalty, commitment and enjoyment displayed by many avid casual game players ““ just as there is nothing “casual” about the market opportunity and market demand for these games.

That is an interesting definition. Let’s have a look at some more. Wikipedia describes:

Most casual games have similar basic features:

  • Extremely simple gameplay, like a puzzle game that can be played entirely using a one-button mouse or cellphone keypad
  • Allowing gameplay in short bursts, during work breaks or, in the case of portable and cell phone games, on public transportation
  • The ability to quickly reach a final stage, or continuous play with no need to save the game
  • Some variant on a “try before you buy” business model or an advertising-based model

The CasualGameWiki as well as extend the definition with specifics about the price point and the platforms:

  • Style Of Play: Casual Games are now considered “games for everyone” – with a special emphasis on whether your mom can play it.
  • Distribution: Casual Games are frequently distributed with a “Try Before You Buy” model. Where a person can play for an hour for free and then decide whether to purchase or not. This model of play grew out of the Shareware distribution model.
  • Casual Games are usually sold for $19.95.
  • Platforms: Casual Games can now be found on Cell Phones and Consoles such as XBox 360 via the Xbox Live system.


Casual games are most often played via a Flash or Java based platform on a PC, but are now appearing in larger quantities on video game consoles and mobile phones.

The definitions often come with a timeframe of around the millennium or 2001.

An Interlude
Let’s move away a little from the term “Casual Games” and the definitions given and have a look at the last sentence: The Year! If we take a look on what happened and was released around that time that is somehow “defined” as the origin of the term we will find things like the Playstation 2 (2000) and the Xbox (2001). While the Playstation 1 was still a child of the “old” console generation especially the Playstation 2 as well as the Xbox introduced the “new” generation of consoles, away from old Entertainment Systems we adored. More important is that with the new generation the games from the “old world”, the Personal Computer, and the consoles were starting to congregate. Complexity from the PC moved to consoles and simplicity of the Consoles moved to the PC.
On the PC Flash was released in version 4.0 in 99 and one year later in version 5.0. These introduced and extended Flash’s own programming language ActionScript. From here on Flash was not only a way of playing frames off a timeline but introducing conditional actions onto these. More and more Flash Games started popping up. Around the same time Java 1.3 was released introducing the HotSpot VM and building the foundation for JavaME (J2ME at that time) that brought gaming very heavily to normal phones.
This interlude is important to understand how Games opened up to a larger community (yes, long before the Wii) away from the nerdy PC hardware geeks that “pimped” their autoexec.bat to play games as of today these build a large majority of the people defining and mostly complaining about “Casual Games” (no offense).

The Ambiguity
If we sum up the definitions the following list could be seen as a general understanding of Casual Games:

  • Easy to learn/simple gameplay
  • Simple controls
  • Forgiving Gameplay/quickly reach a final stage
  • Gameplay in Short Bursts
  • Games for Everyone
  • Up to 20$
  • Try before you Buy
  • Flash and Java Games on the PC side/DLGames on XBoxLive, PSN, etc.
  • Since 2000/2001

This list looks pretty decent doesn’t it? As you can guess from the headline the list is not as decent as I hoped it to be. I often refer to these hand full of games that somehow should fit these rules, are named casual but do not really allow a distinct identification of what a casual game should be.

Let’s start off with Plants vs. Zombies (one of my favourites over the last years). This modified Tower Defense game is a success on every platform. First released in 2009 it sold and sold and people rated it effusively. It’s a great game that just brings a ton of fun. If we look at our list we can see that it looks pretty good: It costs under 20$, the controls are simple and it is downloadable on PC, iOS and XBoxLive. Regarding the gameplay, it is simple and easy to learn… because of the many tutorials, and can be hard to master. This makes this game attractive to be played for just some minutes or for hours fiddling on the new strategies and therefore attracting Casual Gamers and Core Games as well as hybrids like me. It provides Casual Gaming and more, for Casual and Core Gamers. So, is this a Casual Game?
My second example would be Super Meat Boy (and N/N+ in parallel). This 2010 hit platform game has gone through different stages of the list. It was a Flash Game first, ported, tuned and extended for the PC and Consoles. Over 300 mostly short levels (short bursts) with a very gory portion of simple gameplay. It is also cheaper then 20$ and has some very simple controls. But it is extremely hard to master forbidding the slightest error ending in a pure gore fest. And actually (as PETA already noticed ^^’) this is no “game for everyone” anymore because of its scenario and its quickly increasing difficulty level. Hardly a Casual Game, isn’t it?
My third example is Prince of Persia (the one before the crappy Movie Game). Not a typical Casual Game and was more expensive then 20$. But if we look at some definitions it fits as much as the previous two examples: It has forgiving gameplay (yes, I mean you Elika), had a Demo, was easy to learn but had not the easiest controls. The save points were pretty frequent and it had a scenario that even my casual sister was able to relate to. Still Core or did it become Casual?
My fourth example is Lara Croft and the Guardian of Light. A franchise that may have brought many women to gaming, featuring intense 3D platform gaming and 3rd Person Shooting Gameplay. With GoL it became a DLG with a strict isometric perspective. It’s on PC and Consoles, downloadable, costs under 20$ and has (in my opinion) simple controls to master the fine placed action and puzzles. Now, are Tomb Raider and Lara Croft becoming casual? Is it just that game? Or does Lara Croft not count?
My fifth example (to use the full hand) would be every Wii Game. Nearly every gaming site and every “Core Gamer” defines a Wii Game as a Casual Game. Why? Because your Family got into “your hemisphere”?

In general if we just take some of the bullet points, some of the definitions describe things that nearly every game, no matter if Casual or Core, wants to achieve nowadays or is a general gaming tradition:

  • Try before you Buy

Demos, Shareware, … Nothing new to the experienced Gamer and Games in general.

  • Gameplay in Short Bursts

Actually, this is something popping up more and more since the advent of consoles. PC users are used to saving games, being able to use up space on their hard disc. For console gamers this was no natural thing to use so developers very often used stages with manual and automatic save points that were not separated too far away from each other to not enrage the player if he dies. I mentioned Dead Space and my very tight gaming sessions playing through it. This was only possible because of the very “controlled” stages and their save points that I could reach in the given time frame.

  • Forgiving Gameplay/quickly reach a final stage

This as well is something that especially First-Person-Shooters nowadays provide to the user. “Old” Gamers remember a time when it was a necessity to know where the next HealthPack is. Today, we rely on a regenerative system, often presented with the argument to be more accessible to more gamers (“games for everyone”). Becoming casual? And regarding the second part, I could get heretical now but games such as Modern Warfare do not really provide that much gaming time to the user anymore. 5-6 hours are some times normal.
The problem is that gaming following the definitions given is way older. This is why gameplay elements can hardly be used to define the games themselves. What is left are technical definitions, prices as well as hardware to describe the so called “Casual Games” and these obliterate more and more.
So, with all this ambiguity coming from the point of defining the Game, wouldn’t it be better to define the interaction?

Classic Classification
We tend to define things based on their surroundings and the “object” using the “subject” (“People Playing a Game” in our case) because that is what we visually perceive. And as it is easy for us to define unknown things from what we know, we derive the Browser into our experience of Casual Games as the Browser was never a dedicated environment for games but so many things that so many people do, not only gamer. Therefore, it is very easy for “Core Gamers” to define games such as Plants vs. Zombies as Casual Games as their Moms or Dads are playing them.
The problem with the classification and the according definitions of Casual Games is that they try to really define constraints where these games may fit in. In a time where it becomes harder and harder to “just” define the Genre of a game (e.g. Puzzle-Survival-Horror Adventure-Games) it is even harder to define an umbrella term of games in general. But my personal strongest point regarding the definition of “Casual Games” is that most of the people that play “Casual Games” do not even know that these are “Casual Games” (or did your Mother or Sister ever talked about Casual Games when playing Wii or DS?).
The classification normally is given by “Core Gamers”, Developers or Game Editors that want to separate themselves from these “unappreciated” games (in many cases). But what we were able to see from the definitions normally used to describe Casual Games is that these do not fit the real world anymore. Especially as they evolved over the last years, away from most simplistic Flash Games to the best gaming experiences of the last decade (e.g. Darwinia, Braid, Limbo and more)
What is required is to divide not only Games but the interaction, the gaming. For gameplay we have genres. Now, we need a new graduation for Facebook, Flash, Indie and everything else that evolved our gaming experience (and will in the future). To what this New Classification could be, I can give you no answer. This needs a long discussion and a broad overview of everything gaming has to offer nowadays.
But what all Gamers need to do is to be open minded to new possibilities and not argue with the term “Casual Game” anymore, especially those that call themselves Core Gamer. I think we all do not want to hear another: “Epic Mickey is a Casual Game. It’s on the Wii!“

My Conclusion
My intention was to make a polemic assertion, presented with my experience, many questions and concluded with my own ways of thinking. If you were looking for THE definition of Casual Gaming, this post does not deliver. It just brings up some things that do not work out in our current scheme of games classification and with the ever growing amount of releases that qualify to our current definition of Casual Games we should quickly start thinking about a new way of filtering, fitting all modern characteristics such as Facebook, iOS and Android, Unity/Shiva/…, Steam and all the other new ways of developing, presenting and distributing games, challenging the “old way” of games development.
I started off with arguing that there are no “Casual Games” but “Casual Gaming” and I tend to support this even if I give away no new definition because such a broad definition of games cannot be made, if the gamers that count are so broad and different themselves. I agree that I only presented arguments for my theory but as long as it is possible to oppugn the current definition that easily it is in our hands to discuss and define better definitions for our most beloved games… that are changing pretty quickly right now!

Written for #AltDevBlogADay

New Android OpenGL ES Port – Stencil Shadows

Greetings to all of you. Unfortunately long time no “port” see! I had a lot on my mind (something got posted beneath ^^) and a lot to do (many travels, many projects, new horizon). But now I am back in full glorious “in”sanity to enhance your (Android) imagination ^^#

So, first let’s recapture some things about my NeHe Android Ports: To my surprise they were accepted good and got some publicity. I am happy about that… not so much that I had too little time to continue the series like I hoped for. But now I am back and will continue to translate as many NeHe lessons as possible.

But first, I uploaded another port but no NeHe Lesson. The new port is based on code from Apron and his OpenGL tutorial codes and deals with Stencil Shadows. This is definitely something interesting and missing besides what is covered by the NeHe tutorials so far. Therefore, I decided to do this first and then continue with other ports. So, head over to the new section of general Android tutorials and ports under Projects and check out finest stencil shadows on your phone.

PS: I will continue with the NeHe lessons but I will also keep an eye open for other feature/functionality tutorials that could be interesting to know about and are relevant for 3D development on mobile phones.

Android and the (OpenGL) issues

As most people know I pretty much dig Android. I also have been a friend of OpenGL. As I come from the Java side (we have cookies ^^’) and there are two good wrapper implementations with JOGL and LWJGL, I found the perfect combination in OpenGL on Android, hence the tutorial ports.

Over the time I did some tests on Android. Not only with OpenGL but mainly overall to see what could work and how. Unfortunately Android is far from perfect (what ever is?) and has some issues also affecting OpenGL development on Android.

3D Games on Android…
Ravensword - Town BlacksmithGames are probably the main market working with 3D on Mobile Phones nowadays. On the iPhone we have some great examples of cool and nice looking 3D games such as Ravensword and many others. They look good and also run very smoothly (especially on a 3GS, loading times are most of the times much better).
Now, for Android we also have some good Game examples with the just announced winner of the Android Developer Challenge 2 in the category of games: Speed Forge 3D. The really beautiful WipeOut clone gives you a nice 3D game example on Android. Another example is Mystique by Bendroid. The 3D Ego-Survival-Horror in the style of Silent Hill and The Ring is sure to give you some creeps if you play it in a dark room, at night, feeling lonely.

…and the issues!
Now if you compare Speed Forge 3D or Mystique with Ravensword or Gameloft’s upcoming N.O.V.A you probably will get jealous and drool all over the videos. No question: SF3D and Mystique are great, Kudos to the developers, but compared to the iPhone they are far behind.
The big question should be: Why? And the answer is neither simple nor a single one in my opinion.

1. Heterogeneous Phone Market
One big thing coming up with the release of new Android handhelds is the inconsistency throughout the phones. Android itself is a specification and a referential implementation. Now, most phone manufacturer alter some things or add their own implementations of something such as OpenGL. Therefore, it is already the case that with every new release of a mobile phone based on Android you see updates of many Apps popping up because of problems or even crashes on the new device.
Let’s have a look at Speed Forge 3D: I have a HTC Magic and it runs… OK. Not absolutely fluently but playable. Now, a friend of mine has a Samsung Galaxy (or i7500) and he can barely play it until it crashes. Now the Droid from Motorola entered the market with another graphics chip and a larger screen. Many new “properties” to test against and to deal with. The iPhone on the other side may have been updated over the time but the environment stayed nearly the same. And something that runs on the 3GS will also run on the 3G, just load a little longer. So, as time goes by more and more Android devices will come out and will further diverse the market.

2. The Dalvik VM
As always when it comes to Java you will hear people say:

It’s slow because it’s Java!
Java will always be slow!
Forget Java, use the NDK!

(just saw the same posts pop up on the newsgroups and forums again)
They will argue that a Virtual Machine can never give the speed you need (some also tend to forget that .net is a VM interpreted environment). They will argue that the Garbage Collector slows everything down. And if we look back about 10 years they really had a point, but nowadays that may not be total crap but is just not that easy to say.

Poisonville by BigpointFirst of all let’s have a look around at Java-based 3D games, based on the very popular, updated and fast libraries JOGL and/or LWJGL. There would be the experiment Jake2: A Quake2 clone made in Java based on JOGL and LWJGL to have a comparison. If you have a look at the benchmarks you will see it is hard to argue that Java is that slower over the native implementation. And engines such as jMonkeyEngine support the Java faction. The demos over there such as Spirits and other games like Trible Trouble and Poisonville on the other side show that there are very good possibilities to use this object-oriented programming language as your development base.
The thing is that not Java per sé is the problem but as with every programming language the code optimization and the execution environment, in this case the Virtual Machine. Even Tim Sweeney from Epic Games suggests that functional programming and Garbage Collection is the future. The newest Sun Java VM and other VM implementations show what is possible to do with optimization within a managed environment. A good Garbage Collector (GC) and a very good Just-in-Time (JIT) Compiler such as in Suns current Java implementation speed up not only the application but also development itself because of less time spending for the memory management.
But why still the speed problems? As already said, even if Java is interpreted and helps with the memory management you still have to think about what is happening beneath. Most applications tend to just create one instance after the other and do not really care about memory management. This may work on a desktop system but will bring problems to you on Mobile Phones. Things like weak references, caches, volatile and transient are forgotten but highly important terms in Java development. Especially Mobile Applications still have to really care about memory even with all this technically highly fledged phones. Care about the memory more than about computation on modern smartphones.

Nevertheless, even with these more or less “simple” tricks Android still has some problems that you need to remember during development. Most of these result from the Dalvik VM. The current Dalvik implementation on Android phones does not support JIT nor is the Garbage Collector any good.
As no JIT is available all code is interpreted on time and not pre-compiled or anything. On a limited device such as a mobile phone this results in slowdowns. Therefore, it is important to pre-load everything you need and cache as much as you can to have a fluent gaming experience during e.g. a level.
Another thing is the current GC in Dalvik: Avoid it ^^’ Sure, you cannot really avoid the GC directly but try to not release too many objects during gameplay (or fire it by yourself) as the GC will slow your phone so down that even the OS will need time to react. This is also something that can be managed with caching and a good manual memory management. Currently, up to Android 1.6 an application may use up to 12MB of memory. With Android 2.0 this has been upped above 20MB, but as a game should support many platform versions (the issue why I am posting this), 12MB will probably be the limit for a while.

3. The Android OpenGL ES implementations
Another thing that bothers the development of OpenGL ES applications on Android is the again heterogeneous availability of specifications. Android itself by SDK supports OpenGL ES 1.0 and 1.1. The official current OpenGL ES version is already at 2.0. While 1.1 is backwards compatible to 1.0, 2.0 has no backwards compatibility. OK, its to note that 2.0 is somehow pretty fresh and you cannot ask for the newest technology in Mobile Phones. But most Android phones at the moment only support 1.0, for example the HTC Magic whereas the Motorola Droid should be able (hardware-based) to support 2.0.

As 2.0 introduced programmable shaders to the hardware the step is a large one. That is probably also the reason why OpenGL ES 2.0 is the foundation for WebGL, the upcoming and already beta-available 3D JavaScript interpreter for Browsers such as Firefox and the WebKit Engine. So, even if you argue that the newest technology may not be always available in Mobile Phones, as 2.0 is progressing so fast at the moment the diversity between 1.0 on current phones and 2.0 on more and more platforms can result in “support” or portability problems of applications.
The support/portability problem is one of the issues. But more relevant is the functionality available in 1.0 and 1.1. The iPhone is based on OpenGL ES 1.1 and by that it has a big advantage over most Android phones: Vertex Buffer Objects (VBO)! As posted before my tutorial ports, OpenGL ES does not support primitive rendering (glBegin/glEnd). This is good as it will nevertheless be dropped out of the OpenGL standard. In OpenGL ES you have to use Vertex Arrays and/or Vertex Buffer Objects, which are faster anyway. BUT 1.0 only supports Vertex Arrays and no VBOs. This is one big disadvantage not only in speed but in development. You can argue that it is possible to program an application that supports both with tagging the sections but as it comes to mobile development you always try to comprehend everything as much as possible without acting on too many specifics.
Two other important things when it comes to game development are that 1.0 does not support multi-texturing on its own (there are ways, but those are tricks) and it does not support the automatic mipmap generation. Both are necessities if you want to do such nice things like Ravensword or N.O.V.A.
Another thing are the phone specific OpenGL ES implementations. Not only versions but also manufacturers provide different implementations with their phones. For example the Samsung Galaxy has a known very weak OpenGL implementation. There are already several published articles on how to add the HTC implementation to a rooted Galaxy. And as more and more manufactures will enter the Android market in the coming month this will probably get worse.

So, what can be concluded from this? Actually not much but 1.0 <= 1.1 < 2.0! There are some tricks here and there to deal with some things under 1.0 but overall you just have to accept the fact and optimize around what is missing. Or you limit your development to 1.1 (at least for now). But by that you will loose many phones such as the Magic or G1, which probably are the most widespread Android phones at the moment.

4. General and Specific OpenGL (ES) Paradigms and Tactics
As with every programming language or library there are several Best Practices that should be remembered during development. The same thing applies to OpenGL. There are many posts in the net on how to optimize your OpenGL code and you should definitely use Google to keep you up-to-date. I just want to point out two important things (in my opinion) for mobile development.
The first thing is to reduce your draw calls! This is not limited to mobile devices but OpenGL in general. But because of the limited hardware versus a Desktop system, this is even more important. Each draw call is not necessarily bad but in sum are slow. Now, most people do enormous, cool architectures with self-drawing objects that are instanced over and over again. This is nice from an object-oriented point of view but is bad on a mobile device. If you want to do something good and fast for Android work with overall handlers. This relates to what I said about caching. To have super classes, handlers or factories that collect all changed elements or all objects that need to be drawn and only that Object fires the draw call is the way to go. This may look like a limitation but this is not only good for the speed of your application but also reduces the possibility of asynchronous errors when instances of deep objects are computed while the rest already handles another request.
The second thing correlates with what I said about memory handling and caching: Reduce your texture binding calls! To rebind your textures again and again and switch them back and forth is also bad for the overall performance. I know that it is tempting and Android with its nice resource loader somehow invites you to have hundreds of single texture files and load them again and again. But this will get you into trouble really fast. First of all, reduce the calls by utilizing again a super class, a texture handler with some kind of caching mechanism. Another possibility is to merge several textures into one large texture and offset the texture mapping coordinates accordingly. This is easy to do and just requires a small asset pipeline but the advantage is huge.

Both things suggest some very important points that have to be taken into account in the architecture and early development. Therefore, always tend to fulfil the mentioned points already while you are planing.

5. General Mobile Development Paradigms
As well as for OpenGL there are some rules regarding Mobile Development in general. There are also several posts on the net about this topic but just to sum up what I already coped in the above text: A Mobile Device is no Desktop!
Many people come from the Desktop development and are real geniuses there. They make the best applications, fast, functionality perfect and have wonderful graphical user interfaces. BUT what works on a Desktop does not necessarily work like that on a mobile device.
JavaME made it necessary to go back to Java 1.3.1 programming style; To forget about Generics; To forget about Enumerations and just use the “old ways”. Now, with something like the Android SDK, which allows to use nearly the full Java5 specification people just copy their desktop applications into the Android projects and this will make problems. All the things I pointed out above result from that premise as the desktop is the more forgiving (because more powerful) platform.
Things like creating hundreds of instances, using hundreds of different files, not working with in-memory data but reloading everything over and over again are bad… bad… and even worse, really bad! Do not get fooled by all the technical specifications of the mobile devices. You cannot compare the CPU and the RAM with the desktop pendent. I recommend to have a look “back” at the JME development and the experience people made there. Do not copy it one-to-one but use it as a guideline and convert it into a comprehensible Android project. Most problems, most errors, most failures that are posted and reported result from the unused experience made in that mobile development area. Reuse that knowledge, reuse their principles, their ideas and you will avoid many problems. And as there are enough “new” problems do not trip into the old ones.

In conclusion
Please do not get me wrong: My opinion about Android is high, I have one on my own and I love it. Love developing on it, love the SDK updates. The only thing I want to point out is that development on Android phones and Android itself has to start to keep these five things in mind. The next three to six month mark an important state with Android where to go and with at least the noted points you should be good to go.
So, go out there and really work on it to do the best f***in’ 3D Android game of them all (and comment about it here ^^’)!

The first 10 NeHe Android tutorials

Finally! This is again a short but important post. The first 10 NeHe Android ports have been completed. You can find these over at the project page.

This is an important Milestone of the porting, because now you can get a complete overview of the most important things you need to build your own application. I will continue with the porting. Also, I am currently looking at some other tutorials I have learned OpenGL with besides NeHe, and I will try to find time to port these too, as they focus around other specifics (e.g. Models, Animation, Camera, etc.).

So, stay tuned for more and head over to the current ports.