Further adventures in android NDK

Following some good advice on forums, I've gone and got an NVidia Tegra based tablet (Nexus 7). The reason for doing this was to get access to their android tools, one-stop-shop tools for android development. It'd be nice to say that the installation was entirely painless but, unfortunately, that wasn't quite the case. Partly, this was due to our internet connection dying which, due to this being a massive ~2 GB download, wasn't very nice. Eventually, I did get it to download but there were still some troubles: The kit includes a nice visual studio integration (which is great, that means I have more options) along-side a tailored release of Eclipse.  When trying out their 'hello-world' example, I got various errors that would change each time I downloaded the NDK (which I had to do several times).
  Seeing as my co-worker managed to download and install it without problems last Friday, I think what may have happened (although I have no direct proof of this, take with a pinch of salt) is that the server has been updated in between then and now and therefore, I received a corrupted download. For one thing, his installation includes this directory:  c:\NVPACK\NVNDK , which mine does not. That directory contains another copy of the android SDK and the first time I installed the SDK, the Visual Studio template 'hello world' example project referred to that directory.
  Today, when I cleaned, reinstalled and recreated the template sample project again. This time, it didn't refer to the NVNDK directory but still referred to a tool-chain that didn't exist (4.7.2). Fortunately, you can select a new tool-chain (visual-studio10->project-properties->android directories->Toolchain version) and it all just works. And debugs!
  The next problem I had was on my Nexus 7 - it wan't appearing on my 'device' menu in visual studio or in eclipse. On my old Samsung phone, you had to enable developer mode in the settings but I couldn't find the option on the Nexus 7. After a bit of forum hunting, I found that you have to click seven times on (on the tablet) 'settings->about tablet->build number' in order to enter developer mode. That's pretty cryptic, guys.

Incidentally, if you click many times on 'android version' you get a picture of a jelly bean (on this version of android (code name: jelly-bean), anyway.) Swiping the screen gives a little 'game' where you flick jelly beans around. Doing the same on my Galaxy S II, I get this picture:

Android & gingerbread zombies by Jack Larson
Easter eggs are great.  So, anyway. I've finally got debugging working on android thanks to NVidia. One caveat is that this only really works on NVidia hardware; I can't debug on my Samsung phone right now. However, this is a big improvement on feeling utterly defeated, pulling out hair and swearing at unseen and presumably beleaguered tools developers.Thanks NVidia!

I'm busy, so I'd like development tools that 'Just Work'. Failing that, I'll settle for ones that 'Make sense'.

This weekend, I finally finished converting our game libraries to Linux - before now, they only ran on windows and in iOS. We've been converting to Android as well over the past month. There's something a little magical about seeing code all of a sudden working on a new platform - perhaps because it goes from 'not working' to 'oh look, a nearly finished project' much faster than normal development. Also, out of curiosity, I installed Clang and built using that, too. Amazingly, this compiled the whole project perfectly (save for a few tiny initialiser problems in a handful of files out of hundreds), gave really useful warning messages, compiled pretty quickly and and ran silky smooth. I love things that work better than you'd expect them to; it's like finding a tenner you weren't aware of. Also, I'm really excited by the possibilities of Clang and LLVM. The shared p-code thing allows for a lot of possibilities for domain-specific front end languages and compiler hacking.

Android, on the other hand, has been challenging - working with the NDK (Native Development Kit - it's what lets you write C++ on Android) is a lot less fun than developing pure Java code for android.  In fact, there should be a clue in the home page where they explicitly warn that this isn't for most people.  One set of people that it is for, although they don't mention this, is developers with large, well developed and tested engines written in C++.
  There's not a lot of 'it just works' in NDK-Land and I suspect that this is intentional. Google, Microsoft and Apple would rather we all use (respectively) Java, C# and Objective-C exclusively to each platform, ensuring an amount of lock-in. Of course, that's not what most developers want. Who wants to recreate the same work in three languages and then maintain three sets of code? Sounds like a recipe for a maintenance nightmare to me. Whilst using eclipse for Java was pretty good, smooth and even helpful (despite a few oddities and the ongoing struggle to migrate a workspace smoothly), C++ development (at least, in my android related experience and at the present moment in time) is less straightforward.
   I've found Eclipse to be very fragile for C++ development - I've had several show stopping GUI freezes on IDE startup and numerous cases where things mysteriously stopped working or gave entirely misleading and irrelevant error messages (be warned - you'll want to install plugins whilst running eclipse in administrator mode).
  Also, I'm never quite sure if Eclipse has really built all my data before sending it to the phone, although that was a problem with android development in Java too. That kind of spongy, floaty behaviour makes systematic debugging a non-deterministic chore. There's a lot that seems to go on under the hood in eclipse, lots of data squirrelled away in myriad different files. All of this makes predicting its behaviour rather difficult and I'm coding on edge, waiting for the next Heisenbug.  

 Fortunately, the command line tools are pretty good. You can export ANT command line java builds from your eclipse project - I recommend doing this even if you carry on building and debugging in Eclipse. Having a one-stop batch file that builds and deploys is no bad thing. Even if Eclipse has one its seizures, having the command line tools in place means that shouldn't stop you developing or shipping.   
   Debugging is still a challenge. As in: C++ android debugging doesn't seem to work. We had it working briefly (and slowly) but after restarting Eclipse, no dice. Following a tip from the NDK mailing list/google group, I've ordered a Tegra based tablet and will try out Nvidia's DevKit  which people have been saying good things about. For now, debugging is standard output and forced crashes.

Early, non-textured, shot of the game,
now running on Windows, Linux, iOS, Android and MacOS

I used to be more frustrated with Visual Studio and really, really wanted Eclipse to answer all the shortcomings with Microsoft's offering. However, since upgrading to a faster 64bit machine, Visual Studio has been on its best behaviour.  
  On Linux, I'm rather happy with CodeLite (which, unfortunately, usually Googles as COD elite) - it's simple, open source and tends to 'Just Work'.  Codeblocks is also fine.
  
  All in all, despite the inevitable speed-bumps that almost always come with development, I'm very pleased that we have our engine running on three new platforms and hopefully many more to come. My raspberry pi looks like it could do with a snazzy space game...
  That said, I'm looking forward to getting back to graphics and gameplay coding and also to revealing more details about our new game! 

The Eclipse IDE is full of magic. Unfortunately, I don't mean that in a good way. Whilst I do like Eclipse when it's all set up and running (right-click problem solving and their 'intellisense' actually works most of the time), setting up and copying projects is consistently a pain.
 Take, for example, special folders in an android project. When creating a new project and adding JNI support through the IDE, certain folders get magic attributes associated with them - right click the JNI folder and it knows that it should display C++ related options and android folders are also identified. However, you try importing or copying an existing project in and you'll find that your magic folders are gone - no, they're just normal folders now. I can't find where this extra information is stored but I'm still looking. Hopefully it's not in a binary format.
  I'd rather eclipse 'just worked'. If I were coding this, I'd write a more forgiving system that inferred metadata from standard names or folder contents (hey, you've got some C++ files in there, have some C++ options buddy!) rather than storing it in some external metadata which also has to be tediously maintained. That is, at least, how I do things in Clayworks.
  Context menus are great; if there's something that somebody conceivably wants to do to a file or folder then bloody well stick that in the context menu. That's what they're for. Programming is, in and of itself, a challenging activity. I've got my own problems to solve: I'd rather not waste too much of my time having to second guess somebody else's work. I would like my IDE to be easier than dicking around with makefiles, not make life harder by being opaque. I've wasted hours, days trying to balance delicate eclipse projects so that they work, for a while. I know it won't last: like a neighbour's car alarm, it'll be calm for a while but it'll be keeping you awake at night again as soon as something changes.


Edit:
There seems to be a file called .cproject that has CDT project information inside. However, copying that over to the other project seems to have no effect. Perhaps there's another file that tells eclipse that it has a .cproject file, rather than just inferring this from the fact the file exists.