Gavin Pugh - A Videogame Programming Blog

About six weeks ago I moved into that club which everyone else seemed to be part of, but not me. I joined the ranks of smartphone owners! No more 90’s flip-phone; I picked up a recent-ish Android handset. I’d never really been too into the whole concept of smartphone, but was starting to feel a little left behind. I must say that after those few weeks I’m sold, these things are pretty cool.

So, what’s a programmer to do? I think I may have actually downloaded the Android SDK before I even received the phone. Yeah, just a little bit eager! It’s actually the second handheld device I’ve tried to code on. The first being the Tapwave Zodiac, also with an arm processor and touchscreen. I never really got anything worthwhile going on it, my excuse being a job hunt and subsequent move to the United States. But nonetheless, it was a fun little handheld to code for. I was certainly looking forward to coding on a much more popular device.

Total Eclipse of the IDE

Now if you’ve ever tried to write anything for the Android, you’ll know the preferred development environment is Eclipse. If you’re writing your stuff completely in Java, you have everything you’d ever need in Eclipse. It seems to do all the nice syntax highlighting, and intellisense-like functionality that Visual Studio offers. Of course the shortcut keys are completely wrong, and must have been setup by a madman ;), but it does seem a pretty good IDE to develop in. Better yet, it’s free!

But is it for me? Nah. It’s not for me.

I just couldn’t get on with it. Primarily I want to write my code in C/C++ too. So I started to convince myself that I needn’t bother with Eclipse. I can get all the highlighting and quick-reference stuff in Visual Studio, and I could run batch files to build my code. After all, with C++ under Eclipse you still have to install Cygwin and effectively build from the command-line. (or setup batch/makefiles as you would with Visual Studio).

I’ve used Visual Studio for a very long time now, since it’s older guise as simply: ‘Visual C++’. Was version 4.0 I think that I started with, when I moved from DOS to Windows programming. Now it’s my primary coding IDE; I’ve used it at both games companies I’ve worked at in the past decade. It’s an odd one to admit, but it’s too hard to let the thing go.

Makefile Project

So I set off and started a ‘Makefile Project’ in Visual Studio. I could update the system include paths under Visual Studio 2010 (something I think was trickier with earlier versions, or at least not set on a per-project basis, I forget). This meant I’d get properly working intellisense of the Android NDK headers, the ‘External Dependencies’ list in my solution was all completely correct too. All in all, a pretty nice setup.

I put together a batch file, which invoked a cygwin session running ‘ndk-build’. I then setup some further ones which would build the entire package using ‘ant’, and then install and run the application on the Android device connected to my PC. Not much to argue with here. For someone who was longing for Visual Studio back, after a few days with Eclipse. It was lovely.

If you want to try the makefile method, take a look at this website:

• http://ian-ni-lewis.blogspot.com/2011/01/adventures-on-android-ndk-part-i.html

His method is a little cleaner than the one I used, my batch/script files were hard-coded messes of experimentation. Check out the debugging article on his page too, he’s got a way of using WinGDB to debug Android NDK code in Visual Studio. It’s awesome.

What about when it gets big?

Unfortunately Android’s NDK build scripts under Cygwin on Windows, isn’t exactly the performer. When your file count gets into triple figures the initial dependency checks take an age. I also wasn’t too enamored with not knowing what was passed to my compiler. You get a limited set of proprietary settings you can change in your makefile, but it did feel like a black box.

Coming from a console background, I like to know what my debug and release builds actually are. I also like to setup further build variants too… Usually one specific to profiling the game, essentially release with some limited modules enabled to do the profiling. The other major one would be a variant of my debug build, with asserts on but the optimization cranked up to max.

So it did feel a little confining. My realization about the build slowdowns with lots of files came when I attempted to integrate third-party code… Specifically what I’m wanting to use is the Irrlicht engine. It’s a well-structured open source rendering engine. Very versatile, and runs on a variety of platforms. Android included, of course.

Runing ndk-build, the thing would sit there for well over a minute before even starting to compile files. I’ve a recent i7-based laptop too, so it’s no slouch. I had an itching to try and delve into a more integrated method of building with Visual Studio, and that tipped the balance for me.

Enter MSBuild

With Visual Studio 2010 Microsoft made a radical change to the way their C++ environment worked. They moved over the entire thing to use MSBuild. Having worked with a certain non-Microsoft gaming console, you could see that they had to do a little hoop-jumping in previous versions of Visual Studio. Integrating custom compilers with the older versions really appeared to be quite a task. With VS2010, it had been hinted on some preview posts from Microsoft that this would be far easier.

Unfortunately though when I started to look into this, I found next to no information on the web about it. Well, really I found absolutely nothing in the end. I found a couple of questions on stackoverflow.com about the same subject, but with no answers. I ended up searching through the Visual Studio directories to find the existing scripts for Microsoft’s compiler. From there I duplicated the directory layout and began tinkering with setting up a new platform.

I’d never used MSBuild before this. It was completely new to me, never even seen a MSBuild file before. I hear some game companies use it, but ours certainly doesn’t. I can definitely recommend it though, it’s very powerful and flexible. It does have quite a learning curve, and Google searching for documentation can lead you to very bad explanations of how it works. If you’re at all interested in it, I recommend this book:

• “Inside the Microsoft Build Engine: Using MSBuild and Team Foundation Build” by Sayed Ibrahim Hashimi, William Bartholomew.

As well as being a very good guide to MSBuild, it actually had a small chapter about exactly what I was trying to do! Something I couldn’t find at all with Google. Unfortunately I picked the book up after I’d done the majority of my scripting, but it at least showed me I was barking up the right tree.

vs-android

So, vs-android. Once I’d gotten all the features I wanted, and all the bugs I could find ironed out, I decided to release it as open-source. The regular download package just consists of a collection of MSBuild scripts, which need to be copied within a certain sub-directory of your Visual Studio installation.

Alongside the scripts is a single DLL file. When you’re working with MSBuild, you can code up custom tasks in a .NET language, such as C#. The header dependency scanning code lives here, which invokes gcc to find all the headers that the c/cpp files would be dependent on. As well as some other command-line switch manipulation code. The full source to the C# DLL is up on my Google code page.

You can download vs-android here:

• Google Code: vs-android

There’s full documentation on those pages too. Along with a step-by-step example of getting Android’s ‘san-angeles’ sample app compiling and linking. The Google Code page also contains more technical info about the implementation, if you’re interested. There’s a link on the main page to ‘tech notes’, which expands on some of the points I’ve touched on here.

One thing I’d like to mention is that you don’t need Cygwin at all any more, if you use vs-android. That in itself is a godsend! It’s been a few years since I last used it. It was compulsory for our build process a few years ago, when I was working in the United Kingdom. For whatever reason the install took far longer than I remember it taking, and it has a horrible long pause when the thing starts up. I’m definitely glad I don’t need to deal with it again for Android dev.

Finally, I’ll leave you with a comparison of the build times, versus using ‘ndk-build’ (sans long Cygwin pause). They’re pretty good, but I think with some more work I can get the thing running even faster.

What’s next?

I’d hope to continue updating these scripts in future. I’ve got a nice list of things I’d like to tackle already. For now though, I’m going to take a little break from the build scripts. I’m very happy that I can change gears back to writing game code again. Getting a ‘release’ together, with all that it entails, documentation and everything is pretty draining.

I think the last time I put something up on the internet like this was in 1997, when I worked on an editor for Command and Conquer: Red Alert. If you do click onto the garish Geocities website, keep in mind that I was a teenager at the time. 🙂