Blog Reboot

Just a quick note to say that the blog is now back online, but sadly missing quite a few posts that were lost by my old webhost.

The last post I’ve been able to restore is from almost two years ago, when I was just starting out on the drone project. Here’s a quick summary of what’s been happening since then:

  • The drone project is still unfinished, and has fallen by the wayside a bit if I’m honest. I still plan to get it going, someday.
  • I’ve recently found time to resume work on my minimal experimental kernel, Mink. (Find it on github if you’re interested).
  • I have a new day-job – I’m now working for a small non-IT company, putting together a brand new bespoke MRP system for them using Java EE, with a Vaadin front end. In between times, I’m also the entire IT department, which is kinda stressful but also fun.

So all in all you’ve not missed a great deal, and now the blog has a new home, I’ll be regularly updating here with new posts.

The Drone Project

IOIO Board
Because I like experimenting with things, and because I love cool toys, I’ve decided the time is right to build myself a drone quadcopter. 

I’ve played around with RC ‘copters before, and my electronics knowledge is fair (if a little rusty), so I’m not too worried about the actual build (he said, naively). The bit I’m really looking forward to is the software.

I’m still very much in the planning stages (so far I’ve bought one bit of hardware – see pic right). The main goal for this drone is that it will not be radio controlled. I want it to be totally autonomous, without any onboard RC gear at all. That’s right – I even want it to handle take-off and landing all by itself. A tad over-ambitious? I guess only time will tell!

That’s all for now on the drone front, but stay tuned for updates as the build progresses. I’ll be posting here as things move on, and hopefully some day soon I’ll post a video of the maiden flight!

The sharp-eyed amongst you might already have realised how I’m planning to control my drone, but if not, then consider this: Where might I find a device that runs code, and has accelerometers/gyros, a compass, GPS, a camera and wireless network capability, all built in as standard?

Where’s RPG Maker on Mobile?

When Enterbrain released the first RPG Maker game, “RPG Tsukūru Dante 98” in 1992, they opened the doors for gamers who loved RPGs to begin exploring all the possibilities of creating their own games. Over the next few years, and well into the next two decades, Enterbrain continued to revolutionize their RPG Maker series, creating everything from 8-bit games in RPG Maker 95, to 3D, high-resolution games with RPG Maker XP, and finally circling back to 8-bit with RPG Maker VX and VX Ace.

The programs enjoy a wide audience to this date, with lively communities still creating games and swapping resources both in official and unofficial forums. Enterbrain’s decision to begin selling the program on STEAM and even collaborate with foundations like Humble Bundle has certainly helped to get their series – and most especially RPG Maker VX Ace – out there to RPG fans, but something seems amiss.

The RPG Maker series has been, for the most part, exclusive for personal computers, and the projects made with the programs are only playable on computers as well. This poses a problem, as AlchemyBet, creators of mobile gaming website, have found that only 32% of gaming time is spent on desktop and laptop computers today, with 46% being spent on mobile devices like smartphones and tablets. The mobile gaming industry is clearly plowing ahead, and Enterbrain is wasting a golden opportunity by not releasing an RPG Maker for mobile.

The lack of a solid RPG title on the mobile market is something that many gamers have lamented. While big names like Squaresoft and even newcomer Gamevil have released Action-RPG games, there hasn’t been a truly JRPG game on the mobile market in ages – let alone one that lets you create JRPGs for mobile gamers. The closest thing that’s ever come to RPG Maker is Scott Cawthon’s 8-Bit RPG Creator, which, for all intents and purposes, gets the job done… just not in a very eye-pleasing way.

The fact that users had to find a way to emulate RPG Maker games onto their phones should say something – that there’s a demand for this product out there, and Enterbrain needs to address it. Users want to be able to not just play RPGs on their phones, but also make them.

Spritesheets Revisited – Game sprites with Inkscape + Gimp

I’ve lately been doing some work with the (awesome) Unity game engine, prototyping a 2D platformer using version 4.3’s new 2D mode, and as part of that I needed to create some sprite-sheets for game-related animations and the like.

Inkscape Screen Shot
Spritesheet fodder!

As I’ve mentioned before, my tools of choice for graphical work are Inkscape and The GIMP, so I needed to  put together a workflow that would allow me to draw vectors in Inkscape and then export pixels to Gimp, where I would create suitable spritesheets for import into Unity.

I don’t want delve too deeply into the Inkscape/Gimp interaction in this post (I’m still stuck on Windows at the moment, so I just followed this post to get Inkscape’s “Save as XCF with layers” feature working – thanks to Chris Hillbig for the instructions). So, skipping over that part, what I ended up with was a GIMP image, made up of layers, each layer being an animation frame. I now needed to make this into a flat spritesheet, suitable for PNG export to Unity.

If all this sounds a bit familiar, that’s because it’s very reminiscent of this post from September 2012 (if you’ve read that post, then thanks for sticking around for this long!), when I was busy putting together and needed to easily create spritesheets, in GIMP, from layered images. Of course, I initially just used the GIMP script I developed then to create my sheets, and while it did work, it wasn’t perfect. Why? Well, to explain that, I think a little background is in order.

The way works, it’s easy (and efficient) for us to use very wide spritesheets with a single row of sprites, and so the script I wrote way back in 2012 does just that – it creates a sheet that’s arbitrarily wide, with the overall height being the height of a single sprite. For Unity, however, this is non-optimal. Like most game-engines, and anything else that works directly with video hardware to provide high-performance graphics, Unity prefers its assets to be sized by powers of two. While it will happily chomp away on an image that’s 5376 pixels by 256, and even handle the slicing for me, this can result in some odd visual artifacts, and will prevent proper optimisation of the graphics in the game by the engine. I really needed to revisit my old script, and add in the ability to create images with multiple rows, to allow my spritesheets to fit neatly into power-of-two-sized images.

And so, it was back to Scheme. As I mentioned in the old post, I’m not a Scheme programmer, but it’s always fun to play around in an unfamiliar language. I spent a little while hacking around, re-reading the GIMP script API, and generally having fun, and the end result is a new script that does everything I need. In the spirit of the previous post, here is the updated code:

; Script to convert image layers to a sprite sheet.
; Copyright (c) 2012-2014 Ross Bamford.
(define (script-fu-unityspritesheet img sheet-size-opt)
  (let* (
      (layer-count          (car    (gimp-image-get-layers img)))
      (layer-ids            (cadr   (gimp-image-get-layers img)))
      (sprite-width         (car    (gimp-image-width img)))
      (sprite-height        (car    (gimp-image-height img)))
      (spritesheet-width    (expt 2 (- 12 sheet-size-opt)))
      (sprites-per-row      (/ spritesheet-width sprite-width))   
      (rows-needed          (ceiling(/ layer-count sprites-per-row)))

      ; Create new image with appropriate size
      (spritesheet-image (car (gimp-image-new 

    ; Copy and move each source layer appropriately
    (let (
        (i 0)
        (y 0)
        (x 0)

      (while (< i layer-count)
        (let (
            ; Copy the layer...
            (new-layer (car(gimp-layer-new-from-drawable 
                                      (aref layer-ids (- layer-count (+ i 1))) 

          ; Insert, position and make it visible
          (gimp-image-insert-layer spritesheet-image new-layer 0 -1)        
          (gimp-layer-translate new-layer x y)
          (gimp-item-set-visible new-layer TRUE)

        ; Update i/x/y for next iteration...
        (set! i (+ i 1))
        (set! x (+ x sprite-width))
        (if (>= x spritesheet-width)
                (set! x 0)
                (set! y (+ y sprite-height))

    ; Merge layers and rename
    (gimp-image-merge-visible-layers spritesheet-image CLIP-TO-IMAGE)
    (gimp-item-set-name (aref (cadr (gimp-image-get-layers spritesheet-image)) 0) "spritesheet")

    ; Create view for new image
    (gimp-display-new spritesheet-image)

(script-fu-register "script-fu-unityspritesheet"
                    "Create Unity spritesheet"
                    "Create a Unity-compatible spritesheet from current image layers"
                    "Ross Bamford"
                    "Copyright (c)2012-2014 Ross Bamford"
                    SF-IMAGE    "Image"         0
                    SF-OPTION   "Size"          '("4096" "2048" "1024" "512")

(script-fu-menu-register "script-fu-unityspritesheet"

(Once again, thanks for the folks at for the syntax highlighting🙂 )

Random headache #57 – Rails 4 and Nokogiri on Windows


So I’m currently working on a rails-based internal app for a company I occasionally do some work for (and often, wish I didn’t), and for one reason or another I’m stuck developing on a Windows box. I won’t go into the reasons for this right now (suffice it to say that I blame Broadcom. Or Sony. I’m not sure…) but it is what it is – I’m stuck with Windows on x86-64.

The stack in use here is Rails 4.0 on Ruby 2.0, which is apparently known to be problematic on 64-bit Windows, and it seems there have been some previous problems with Nokogiri added into the mix. I’ve spent a few hours now chasing this one down, and googling around has turned up quite a few people experiencing similar issues. The problem is that I could not get Bundler to use the (already installed) fat binary Nokogiri 1.6.1. No matter what I tried at the (braindead) windows command prompt, it would always download the source gem and try to compile it. Which didn’t work. If you’ve ever tried to get a working libxml2 build going on Windows, you’ll understand why I wasn’t prepared to push it. I just wanted to use the pre-built binary provided by the nice folks at Nokogiri.

After putting up with an annoying develop/test cycle involving pushing every change over to an old (Linux) laptop, running tests, and then coming back to the Windows machine for further coding, I finally found a way to make it work on Windows, thanks to a read through the Gemfile manual. It turns out I can unpack the binary gem into a local path within my app, using the :path option. So I unpacked the binary gem into a new directory, and then modified the app’s Gemfile thusly:

# Workaround windows issue (quelle suprise) with nokogiri on win64
# Note: We don't actually require nokogiri (which is why there's no platform agnostic
# gem line for it) - it's only required by the other dependencies...
# Also, since we wouldn't dream of deploying production on a windows box, this is
# a development/test only dependency...
group :development, :test do
  gem 'nokogiri', '1.6.1', path: File.join('.', 'localgems', 'nokogiri-1.6.1.beta.1.mingw.1-x64-mingw32'), platforms: :x64_mingw

With this in place, I was finally able to run bundle install all the way to the end. I did run up against one other problem (an execjs runtime error, which pops up because Windows doesn’t support v8, and so therubyracer is incompatible too), which I patched up by following these instructions (this is for execjs 2.02 – YMMV with other versions, obviously). After that, I was able to run my specs, and even start the rails server locally.

Job done! Now I can get back to writing some actual code…

Edit: After sorting this, I did a bundle upgrade and moved to rails 4.0.1. Predictably enough, everything broke again, with all kinds of exceptions about missing timezone info. When the obvious quick-fix didn’t work, I gave up and moved back to 4.0.0. I’ve banged my head against this particular brick wall enough for one day!

One-to-many in ORMDroid – at last!

I’m pleased to announce that as of this morning, ORMDroid now has some basic support for one-to-many relationships between entities, thanks to Jacob Ferrero and as hinted at in a previous post. Jacob actually put this together a few months ago, the only hold-up has been me getting around to merging the code in, so it’s great that it’s finally done. It’s not in a release yet (later this week is the plan on that) but is available in Git on the master branch.

Jacob explains the changes better than I can, so here’s a quote directly from his original pull request:

Basic usage is like this:

class Person extends Entity {
    public String name;

    @Column(inverse = "person")
    public ArrayList<Hobby> hobbies;

class Hobby extends Entity {
    public String type;
    public Person person;

And then you would just use it like normal:

Person person = Entity.query(Person).where(eql("name", "Christ")).execute();

for(Hobby hobby : person.hobbies)
    Log.d(TAG, "Hobby found: " + hobby.type);

It’s worth noting that this change does break the API slightly, the most common case being that if you’ve previously used @Column(inverse = true) then you’ll need to migrate to the new form which names the foreign column.

In the unlikely case that you’ve implemented your own type mappings, you’ll also need to make some changes as the public API has changed slightly (there’s a new parameter, precursors, which if you’re not currently using you can safely ignore in your code) and there have been some minor changes under the hood (e.g. in EntityMapping#load) that you’ll need to update your code for.

All in all, some long-overdue positive movement in ORMDroid. We’re definitely moving toward a new release this week, and I promise to be less tardy in the future!



Just checking in…

Wow, so my last post was September? That’s just not good blogging, and for that I apologise… There’s been a lot going on, but this is no time for excuses – I’m just posting this to let you all know that I’m still here, still writing code (lately, not as much as I’d like, but there you go) and I’m soon going to be making a start on the huge list of Open Source stuff that’s been building up over the past few months. Here are a few highlights of what’s in store:

  • Some awesome new stuff will be going into ORMDroid very soon, with some great contributions from Jacob Ferrero including one-to-many support. I can only apologise to Jacob for the time it’s taking to get these reviewed and merged!
  • Speaking or ORMDroid, it must be about time for that 1.0 release…
  • I’m planning to finally finish up Deelang. It still needs the new parser architecture sorting out, and some bug-fixes, plus some decent documentation. It’s been sitting there for too long, it needs to be pushed out the door!
  • I have some new code to put into Mink, including some rudimentary user-mode bootstrap code, along with a basic round-robin scheduler and other basic bits that will allow development to continue. A lot of this code is written, but still shockingly untested and even-more-shockingly out of version control!

Outside of Open Source, I still have to do something with, a fact I was reminded of the other day when the domain name came up for renewal. The annoying thing there is that it’s done – I just need a reasonably-priced swag supplier who can print up cool T-shirts and the like for people to buy (any suggestions much appreciated!). We’ve also got an exciting new venture on the verge of private beta, which we hope to be launching as a commercial product later in the year.

So, all in all, exciting times. Now I just have to actually get on and do all this stuff.

Watch this space.


The “Scoring Predictions” kata

Official Ruby logo
Official Ruby logo (Photo credit: Wikipedia)

While idly surfing around earlier, I caught this post on coderbits, announcing that some of the Practicing Ruby archives are available under a free documentation license. When I saw that one of the released articles was written by James Edward Gray II, I just had to take a look.

In case you don’t know, JEGII is a “name” in the Ruby world, and for several years he ran the weekly ruby quiz on ruby-talk. At the time I was quite active on the list, and used to really look forward to the quiz as it always provided an interesting diversion from whatever I was working on that week. I even helped out by setting the occasional quiz myself (and that one won me a signed copy of James’ book).

Anyway, his article for Practicing Ruby was a great read, and proposed a problem that I’ve not specifically come across before. Just reading the intro re-awakened the old ruby-quizzer in me, so I had to have a go. Before I read any further than the problem definition, I wrote up some code. Here’s my first version:

def score(guesses, winners, scores = [15, 10, 5, 3, 1])[0, scores]) do |cscores, pair|
    guess, winner, cur_score, scores_ary = *pair, *cscores
    cur_score += if guess.eql? winner
    elsif winners.include? guess
    end || 0

    [cur_score, scores_ary[1..-1]]

This works, but it feels funky in places. Using an array to pass multiple variables through the inject loop, for example, isn’t good coding. I don’t write anywhere near as much Ruby as I once did so I tend to forget things. Sure enough, reading the rest of the article reminded me that zip can take more than one argument!

This allowed me to refine my code a bit:

def score(guesses, winners, scores = [15, 10, 5, 3, 1]), scores).inject(0) do |cur_score, (guess, winner, score)|
    cur_score + if guess.eql? winner
    elsif winners.include? guess
    end || 0

This is also using another little trick I’d forgotten about (Mathias Meyer had a reminder for me in this post) – tuple arguments. Inject passes in the current score, plus the current three-element array from the zipped array. By surrounding the three argument names with parenthesis, Ruby splats the array out into three variables automatically for me. Sweet!

This fun little exercise reminded why I love Ruby so much. It’s the little things: zip and inject, ‘if’ as an expression (notice the ‘end || 0’ line at the end of the if block), tuple arguments and so much more.

Right now my day job project is a rails-based proprietary webapp, where I’m obviously writing Ruby, but somehow it’s a lot less fun than little snippets like this. My new resolution is to spend a little time every week seeking out these little problems – if Ruby Quiz no longer comes to me, then I must go to it!


ORMDroid 0.40 released

ORMDroid 0.40 is now available from the releases area on Github. This is the first packaged release since 0.20 almost eleven months ago, and incorporates new features, reworked old features, and bugfixes. There’s a full announcement at the link above.

As well as packaging this release, we’ve now also closed the (legacy) Google Code site for ORMDroid – we’re now 100% Github!

This release marks the last call for major new features for the 1.0 series. If you’ve got any burning issues you’d like us to look at, discuss in the comments or post an issue on Github and we’ll take a look.


Creating a bootable hard-disk image with Grub2

Hard Disk Platter
Image courtesy of Wikimedia Commons.

Creating a Qemu hard-disk image that boots with Grub2 is, as it turns out, not too difficult. Unfortunately though, the steps you need to get it working are not completely obvious, and documentation is still pretty sparse (probably because Grub2 is still quite new). In this post I’ll run through how I got it working, and how I integrated it into my build.

I mentioned before how I had decided to start playing with OS development with Mink (which is now on Github, by the way). I’ve got a very simple kernel that does almost exactly nothing, and obviously I need to boot it up so I can test it as I add things. The obvious (and accepted) way to do this is to use some kind of virtual machine software to emulate the target computer (in my case, at the moment, that’s an x86 PC). I’m using Qemu.

Originally, I was using grub-mkrescue to create CDROM ISO images, and this worked fine for a while. Now, though, I’m getting to the point where I want to start implementing a disk driver, and filesystem support. To get started, I just want to implement simple IDE (i.e. PATA) support in the kernel – I don’t want to do ATAPI (which I’d need for the CDROM based setup) and I really don’t want to push off with an ISO9660 filesystem driver. I want read-write capability, so I’ve chosen to switch from the ISO build to a hard-disk image file, on which I’m using an ext2 filesystem.

So I spent much of today trying to get it to work. Googling the subject turned up a few links, but sadly nothing worked immediately, possibly because Grub2 is still being developed and has changed since the various tutorials were written. In the end I hacked up a solution based on bits from many different places, using the loopback device to mount the disk image, and then grub-install to actually install the bootloader. The configuration file I’d already put together for the ISO boot still works fine, and the final script I came up with is so short and simple, you’d never guess it took me the best part of a day to write!

Firstly, here’s, which is the script that does the actual image creation:

# Create the actual disk image - 20MB
dd if=/dev/zero of=mink.img count=20 bs=1048576

# Make the partition table, partition and set it bootable.
parted --script mink.img mklabel msdos mkpart p ext2 1 20 set 1 boot on

# Map the partitions from the image file
kpartx -a mink.img

# sleep a sec, wait for kpartx to create the device nodes
sleep 1

# Make an ext2 filesystem on the first partition.
mkfs.ext2 /dev/mapper/loop0p1

# Make the mount-point
mkdir -p build/tmp/p1

# Mount the filesystem via loopback
mount /dev/mapper/loop0p1 build/tmp/p1

# Copy in the files from the staging directory
cp -r build/img/* build/tmp/p1

# Create a device map for grub
echo "(hd0) /dev/loop0" > build/tmp/

# Use grub2-install to actually install Grub. The options are:
#   * No floppy polling.
#   * Use the device map we generated in the previous step.
#   * Include the basic set of modules we need in the Grub image.
#   * Install grub into the filesystem at our loopback mountpoint.
#   * Install the MBR to the loopback device itself.
grub2-install --no-floppy                                                      \
              --grub-mkdevicemap=build/tmp/                          \
              --modules="biosdisk part_msdos ext2 configfile normal multiboot" \
              --root-directory=build/tmp/p1                                    \

# Unmount the loopback
umount build/tmp/p1

# Unmap the image
kpartx -d mink.img

# hack to make everything owned by the original user, since it will currently be
# owned by root...
LOGNAME=`who am i | awk '{print $1}'`
LOGGROUP=`groups $LOGNAME | awk '{print $3}'`
chown $LOGNAME:$LOGGROUP -R build mink.img

Take away the comments, and that’s 15 lines… Just under two lines per hour – good thing I don’t work for IBM!

The comments pretty well explain what’s going on line-by-line, so I won’t go into much more depth here. The only things to note are that I use Fedora – on other system’s grub2-install is just called grub-install – and that on most systems, this will need to be run as root, so I added a small hack at the end to set the file ownership back to the original user once the image is created.

To integrate this into the build, I simply call it from the Makefile (I’ve included the older ISO build target here as well so you can see how it all works together):

# Generates the image staging area under build/img. This is
# the directory layout that is used to make the ISO or hard-disk
# images for emulators.
.PHONY: image-staging
image-staging: mink.bin grub2/grub.cfg
	$(MKDIR) build/img/boot/grub2
	$(CP) --parents $^ build/img/boot

# Generates the Grub2-based ISO - see bochsrc.txt for info.
# Requires grub2-mkrescue and xorriso be installed!
mink.iso: image-staging
	grub2-mkrescue -o mink.iso build/img# Generates a hard-disk image. See
mink.img: image-staging
	sudo sh

(Thanks to for the syntax highlighting).

This should be pretty self-explanatory, so I won’t bore you with further details.

So there you have it – an easy way to make a Grub2-bootable hard-disk image as part of your build process. Of course you can do it manually by booting your virtual machine from a Linux live CD and installing grub to the hard drive, but if you want to automate it, feel free to use this (it’s under the MIT license, so please give credit where it’s due – see here).

Finally, in the event that Grub changes as it continues to evolve, please let me know in the comments and I’ll try to keep this post up-to-date.