Nerd Club is on the move again

Updates have been few and far between recently. But that's because of some exciting news (well, it's exciting for us anyway). After six months in Wales, we're heading back to the digital centre of the UK - sunny Brighton!
That means hooking up with the cool kids at dotbrighton and BuildBrighton again, working on some cool group projects, as well as advancing our haXe development and mobile games learning.

Check back for updates as we put all this moving business behind us (arranging visits to view properties, travelling up and down the country, loading and unloading equipment as well as moving houses) and get back to nerding about and making more cool stuff!

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?

Fuzz Face with NPN transistors (MPSA18 amplifiers)

After amending our FuzzFace design to use a positive power supply, we've had a couple of enquiries about the schematic. Mainly that a few readers weren't familiar with the PNP transistors used (nor seeing them drawn "upside-down" in the circuit) so we've found a design that uses NPN transistors and different resistor values (including a potentiometer/variable resistor to adjust the amount of "fuzz")

FuzzFace with NPN transistors

Here's the PCB layout. We've not had chance to try this, as we're still waiting for some 20uF capacitors.

That said, we've a few 22uF caps lying around here (large black barrel electrolytic types) and since 22uF is just within the range of a 20uF with +/- 10% (and 20uF is within the range of a 22uF with +/- 20%) then it may just be a suitable replacement. We hope so, since 22uF caps can be easily found all over Farnell and eBay for just a few pence whereas the cheapest 20uF rated capacitors are about £3 each.

FuzzFace NPN pedal PBC layout
(print the above at 100% no scaling to create your own press-n-peel image for toner transfer)


Since simplifying the design (using 22uF instead of 20uF capacitor for example) we've managed to source all the components needed to make this pedal, so it's off to the nerd cupboard now to crack open the Ferric Chloride and get etching!

Painting Blood Bowl miniatures

I've been trying to spend some time away from my computer lately - which is quite difficult since it's not only my work, but my hobby and most of my other hobbies (electronics, music etc) use a computer somewhere along the line too.

Since working on my Blood Bowl electronic clone, I've been looking at miniature-based war games. I never understood them, nor was I particularly interested in the whole dragons-and-wizards games, even when I was a teenage nerd-bag baby (listening to Iron Maiden, baby). But I always thought that Blood Bowl was a good game in it's own right - or rather, it could be, if it wasn't for all that pesky dice-rolling and looking up results.

One thing I have found, however, is that I can wield a tiny 000 paintbrush quite well. I'm not up to Games Workshop Golden Demon, professional painting standard, but I do seem to be able to blob colours in roughly the right places on a miniature. So I'm trying to develop my own painting style. I can't be bothered with all those washes and blending and teeny-tiny details, but I do quite like my thick black outlines and the "toon shading" finish on these models

So this is going to be my signature style. Van Gogh had his, Escher and Matisse had theirs. This is mine. Two-tone shading and thick black outlines; miniatures that look like they've been coloured in using a set of children's felt-tipped pens. I'm still building up my range of paints, so I've a couple of miniatures on the go while I'm waiting for different shades to arrive in the post. Here's an Orc "thrower" started in my new "toon shading" style:

(the colours on the actual model are much more vivid and vibrate - my camera-phone obviously isn't very good with garish bright colours!)

While I'm actually enjoying regressing back to my 14-year-old self doing this sort of painting, I still can't wait to get the models painted and actually see them being used in an electronic Blood Bowl game!

Investigating capacitive sensing

The results from our earlier testing for a multi-plexed capacitive sensing grid are in and...... it's not good. The idea just didn't work. It seems that to use "simple" capacitive sensing - ie energising a pad then checking to see if an input is present a few moments after shutting off the power - the pad has to be directly under the top "plate" of the capacitor (i.e. your finger).

We were hoping that putting power onto a plate immediately to the side of what would be the bottom "plate" would suffice but the only way we could get an inputs to activate was to introduce a "real" capacitor and make a mechanical contact to the plates.

This got us thinking about alternatives for our cap-sensing board (and if it would even be possible). While an RC network on each input pin is immediately obvious, converting this into a grid also gives us a few headaches. So we're now investigating how to use rows and columns of pads and our working cap-sensing prototype

.We already know that we can activate/deactive single input pins one-at-a-time and detect if a piece is above it. But when it comes to multi-plexing, re-using the same inputs for different "rows" of pads is quite tricky. But we've come up with another idea which keeps the same (working) technique and builds on it:

We're going to make strips of pads, all connected in a line. At 90 degrees to these, we'll have strips of pads on the other side of an insulating material. We can then send an entire row high, flip the pin to input and check for a signal on the input pin - just like before. What we're hoping to do is to use the pads running perpendicular to "mask out" some of these pads, so if we get an input high, we know which of the pads in the strip triggered the input.

Let's say the lower (darker) pads in the diagram are on the X axis, and the paler (higher) pads are on the Y axis. We can send row X1 high and check for a high input back. But it could have been any of three pads in that row which triggered the input. BUT - if we send columns Y1 and Y2 high, when row X1 flips to input mode, only capacitance from X1,Y3 will be detected (since when row X1 goes low, Y1 and Y2 stay high, so if your finger is over X1,Y1 or X1,Y2, it won't actually "discharge" until these columns go low as well).

That's the theory anyway.
Once again, it's a bit late to try the whole thing from start to finish, but here's as far as we got:

We started by drawing 1" squares onto a strip of 1" wide sticky copper tape. In the centre of each square, draw around a penny coin. Draw lines to connect all the dics in a row and cut them out using a sharp knife

As we're going to have rows and columns running in opposite directions, we'll need some insulating material and to stick the strips of pads on each side. Ideally we'd have preferred to use tracing paper or tissue paper - but in true "hacker" style we used whatever was to hand; these paper towels were quite thin:

Stick the rows of pads in one direction, and the "columns" at 90 degrees. If we'd used tracing paper, we would be able to see where the pads had been placed on each side - we couldn't and had to guess, which is why they're a little bit out of alignment. We're not even sure if this idea is going to work - let's hope this doesn't prove critical when we come to try it out!

Rather than spend all night making a large grid of pads, we're after proving that the idea works (or, if it's anything like last time, whether it doesn't).  So we've marked the four pads in this arrangement that have pads in both the X and Y axis on opposite sides.

All that's left to do is to write some new firmware and try the idea out!
Unfortunately, it's gone midnight now and with work in the morning, this will have to wait until tomorrow.....

Multiplexed capacitive sensing board(s)

This is yet another proof-on-concept idea, but if it works, it'll be perfect for our intelligent/electronic board game. Following our earlier instructions, here are two multi-part boards for testing.

As you can see, each pad is split into two large rectangles. One half of each pad is connected to a common "power" pin and the other to an input pin on the microcontroller. The principle is to make one half of the pad "live", shut down the power, wait a uS or two, then check the input pin. Hopefully the pad size will be sufficient to allow the coin to act as a capacitor, even if the two plates of the capacitor are different sizes.

There's no real way of knowing for sure if this idea will work or is just crazy wishful thinking - except, perhaps, to build it and see!