Basic4Android

One thing we've been keen on over the last 12 months or more, is making our own USB devices. These can be anything - we've made miniature instruments and servo controllers amongst other things, but the idea that you can create a device, plug it into a PC and it just works has been really exciting.

Out in the real world - not Nerdland - the rest of the world is busy getting on with mobile phones and tablets and cool things like that. And leaving us PC lovers behind as we look so archaic, sitting hunched over a notebook/laptop in the local coffee shop. The cool kids are too busy swooshing and swishing on their touch screens to worry too much about a few motors chained to piece of rapidly-becoming-obsolete piece of technology!

So we've had a bit of a change of heart here at Nerd Towers recently.
Rather than trying to continue denying mobiles and mobile computing, we're slowly learning to love it. By which, of course we mean, slowly learning to love Android (installing iTunes on a PC is akin to pouring cold tea down the back of the air vents, shudder, Apple, shudder). But developing for Android means getting messy with Java.

Unless you're already quite proficient with Actionscript (AS3) - then haXe is probably a great place to start. But haXe libraries are pretty limiting. We've not found anything that, for example, allows you to communicate with the USB port. So once again we set off looking for a development suite that would compile for Android, and give us access to the USB stack.

Step forward Basic4Android.

Not only is this a brilliant IDE, offering VB-style syntax and a familiar looking environment (you even hit F5 to compile and run your code for goodness sake!) it also compiles to native Android code - so no pesky AIR runtimes and making your apps incompatible with a large share of the market (AIR only runs on devices with ARM7 or better processors - most mid-range phones are still shipping with ARM6 in them).

And the best thing? USB support!
So far, we've only got a simple "hello world" app working, but it's a start.
But already Basic4Android is looking to be quite a powerful bit of kit that could really kit-start some interesting ideas (a bit like Oshonsoft Basic did for our PIC microcontrollers). It's so great, in fact, that the author is offering a special deal for all of us:

If you like the Basic4Android software, you can buy it from http://www.basic4ppc.com/

Put in the voucher code - coxvau - and you'll get a massive 50% off!

And we'll get a year's worth of free support and upgrades. So everyone benefits! But no-one more than you - when you've compiled and released your first app, who knows where it could lead.......

Creating a simple sprite-based game with haXe

The first thing to note, when using haXe for cross-platform development is that not all platforms are the same. That's fairly obvious, but can lead to un-optimised code for different platforms, so it's important to understand the nature of your target device.

One of the first things that got us excited about haXe was the ability to write code once and deploy with relatively little effort to Windows (exe), Flash (web/swf), Android (app/apk) and iOS (app/ipa). We started by targetting Flash, since this was a platform that most of us were already familiar coding for.

Already we've discovered that not all Android devices on the market support AIR, so using native Flash assets and just compiling to apk isn't an option with Flash CS5.5. But something that became apparent after a bit of digging around - and may not be immediately obvious to the first-timer - is that even if we could just deploy from Flash to Android, movieclips are not very good resources to use anyway. Placing a movieclip on a stage immediately puts extra work onto the CPU - maintaining it's appearance, checking for and responding to events and so on, all mean that a movieclip comes with a pretty big overhead.
Movieclips are also drawn using the target device's CPU, not a GPU. On a PC this isn't a great issue, but for mobile devices, where every CPU clock means a little more battery life is ebbing away, it's not great!

So we're looking to build a sprite-based game, but to manage everything in code;
That means no movieclips, no timelines, no doing anything the easy way! We're going to load the bitmap data, then display it on-screen ourselves, in a custom-built rendering routine.

It's almost like going back to game-coding from the early eighties.
Forget all your fancy event-driven object-oriented development of the last thirty years and strip your code back to three simple procedural loops, called using a single timer. It's the basis of almost every game, ever:

get user input
update sprites
draw scene

That's it.
We're going to try to build a simple game (space invaders clone) using these techniques here, in Flash and haXe and compare the two. Unlike most game development guides, however, we're going to do things the way a programmer would do in the real world.

Most tutorials will teach you about defining your game states, abstracting the data types, planning your code and so on. These are all very valid and useful game-development strategies. But in truth, most of us write games back to front when starting out with a new set of tools. Instead of worrying about the planning and the design, we tend to write games in a slightly different order:

• get something to display on the screen
• move it about a bit
• create some "proper" sprites
• animate the sprites through a recognisable sequence
• move multiple sprites around
• write some rules for the sprites to follow
• make one or more sprites respond to user input
• go back to the drawing board and design our game!

So here goes.
Assuming you've a working haXe environment (good luck with that one - it took us over 16 hours to get something working, and even now we're not sure we could repeat it successfully!) here are some examples of how to get some sprites onto your device:

Mobile development with haXe NME

Once again real life and work got in the way of nerding about - only this time we managed to combine the two for a while; a few of us are learning mobile development for Android/iOS and the most obvious way forward, as experienced Flash developers, was to go for Flash CS5.5 with it's built-in AIR support.

We've been asked to make a simple app for a tablet (originally an iPad2, but most likely an Android tablet) or a smartphone/hybrid (something like the Samsung Galaxy Note springs to mind) so we've been learning all about tool-chains and cross compiling. Ideally we'd have liked to have stuck with Flash/CS5.5 and AIR, which is ideal for cool kids with the latest smartphones. Creating an app in Flash CS5.5 is a doddle and creating an .apk file is as easy as hitting "publish". Copy the .apk file onto your phone via a usb lead, then use My Files to install the app. If your phone doesn't already have it installed, the app will prompt you to download Adobe AIR (one-time only).

But this is where things started to wrong for us!
We'd only got as far as installing the app when a message popped up to say that our handset wasn't compatible with AIR...

It seems that many smartphones (and tablets) on the market are still running ARM6 processors (such as our Galaxy Ace handsets) and AIR doesn't run on these. We could just ignore these, concentrate on making apps for handsets nearer the top-end of the market and go back to Flash. But there's something about cutting out a large proportion of users, many of whom will be getting Arm6-based handsets (because they are free) on two-year contracts, that doesn't sit right with us. So we've been looking into AIR-free compilers....

It's been a bit of a nightmare!
There have been loads of suggestions, tips and recommendations and we're indebted to the guys at dotBrighton for keeping us going. One thing we're keen on doing is keeping CPU usage to a minimum (with a view to extending battery life while running our apps). Of all the set-ups we've seen, haXe NME looked like it offered what we were looking for - and, it uses an AS3 type syntax with familiar libraries, so the learning curve shouldn't be too steep.

It took over 16 hours to get haXe installed and working properly. There are no easy-start guides on the 'net - we should really have been a bit more organised, written down exactly what we did and how we did it and created one for others to follow. But the truth is, it was so convoluted and we ended up downloading massive 600Mb+ files two and three times (first manually, then allowing the installer to try, then uninstalling and trying again) that we'd only end up with a guide on how not to set up a programming environment!
Something still doesn't ring true that we've used up over 20Gb in disk space just getting this lot working...

But in the end, after installing Java runtimes, Java SDK, Android SDK, Android NPK, Flash Develop, haXe NME, C++, Visual Studio Express, Cygwin and a whole heap of other crap we didn't fully undesrstand, we managed to get and environment working that allowed us to compile the Actuate example from the haXe NME website

Here's our end result. The video shows up to fifty sprites (filled shapes) of differing degrees of transparency with a couple of pngs we added ourselves, to try out the png support.

[video here]

With alpha-support for pngs, and the ability to draw moving objects at different depths, things are quite exciting. A tile-based sprite-blitted game can't be too far away, surely?