Relocation and SDL2

Things have been a little quiet here recently. I am pushing ever westward; this time I moved from sunny Littleton, Colorado, to the equally-sunny Mountain View, California. I’m close enough to Google’s headquarters to be able to see their city-wide free wifi on my laptop, but far enough away that I can’t use it.

Relocation is something of a theme. The little coding time I’ve had has mainly been spent moving repositories from Mercurial/BitBucket to Git/GitHub so that I can hang out with the cool kids. Actually, I’ve been using Git exclusively for about five months and find that, when I do need to use Mercurial, I can’t remember how it works. Within the repositories, I’ve done some relocating too: consolidating DS and SDL code.

SDL2 was released not too long ago and I thought I’d have a play and see if it offered anything new. It seems the most important change for my SDL projects was the inclusion of automatic texture format conversion within the library itself, meaning it has built-in support for converting and displaying bitmaps in ARGB1555 format. This means that all of my DS projects no longer need to keep track of two bitmaps - one in ARGB8888 and one in ARGB1555 format - when in SDL mode.

Upgrading to SDL2 has allowed me to merge the SDL and DS codebases together, meaning I now have a single repository that will build for the DS and OSX out of the box. Getting them to build in Windows and Linux should be trivial. Additionally, the makefiles for the DS versions all work with the latest devkitARM. Something must have changed in the build system as all of the makefiles were broken.

In other news, I’ve been tinkering with Woopsi again. The complex, C#-inspired EventArgs system is out and I replaced it with the set of arguments that are relevant to each event. Gadgets no longer support multiple event handlers; each can now have just a single handler. Much tidier.



As promised, here’s the BitBucket repository that contains the full NSManagedObject diff/patch functionality discussed in the last post:

The repository doesn’t include a demo yet, but the comments are extensive and the APIs are simple. I’ll revisit this soon with a post that discusses the patching functionality.


Blogging with Mercurial from the Rocky Mountains

It’s been a while since the last update, but I do have a good excuse. I’ve upped sticks and moved from dingy Birmingham, in the UK, to sunny Littleton, Colorado, in the USA.

So, who’s hiring?

I’ve decided to start blogging about those experiences, but rather than flood this blog with personal posts I’m making a separate blog. But what blogging platform to use? It’s not going to have much traffic, I don’t want to put any admin time into it, I don’t want comments or tags or categories. All I want is to be able to post text as quickly as possible using Markdown.

It would be great if there was a blogging platform for Mercurial like the one available to Github users, but I’ve looked around and haven’t been able to find one. So why not write one?

Here’s my list of requirements:

  • Displays blog posts in reverse chronological order (newest first).
  • Posts are written in Markdown and reformatted into HTML automatically.
  • Posts are stored in a repository on BitBucket.
  • Pushing to the posts repository automatically updates the blog.
  • Allows paging through blog posts.
  • Includes an “Archive” page that lists all blog posts.
  • Has an RSS feed.
  • Maintains a cache of blog posts to minimise queries to BitBucket’s API.
  • Looks a bit like WordPress’ “TwentyEleven” theme, as that’s my favourite theme at the moment.

After a couple of evenings of hacking, here’s the result:

And here’s a demo:

A blog powered by BitBucket and Mercurial. Neat!

I’ve included instructions for getting a BitBlogger instance up and running on AppHarbor, a .NET hosting site that offers a basic freemium option. As BitBlogger doesn’t use any local storage or background events (BitBucket notifies it of changes, rather than BitBlogger needing to poll for updates), it doesn’t need anything above the free package.

I’ve copied bits and pieces of the TwentyEleven theme’s CSS file in order to replicate some of the appearance, so the licence for this application is the GPL rather than my preferred MIT licence. If anyone feels like putting together a simple and very legible theme to replace the current look and feel, I’ll be able to switch it over.


Really Bad Eggs OSX Demo

Here’s a preview release of the Mac version of Really Bad Eggs:

For those of you without a Mac, here’s a screenshot:

I’ve been debating what to do with the game when it’s finished. I can either:

  • Open-source it on BitBucket;
  • Release it via the Mac App Store;
  • Release it as freeware on this blog.

If I want to release it on the Mac App Store (which would be neat) I’ll need to sign up for the Mac Developer Program. That’ll cost me $99 that there’s little chance of recuperating. There are a couple of Puyo Puyo games on the store already for bargain prices. I haven’t tried them so I’ve no idea if they’re any good, but Really Bad Eggs would probably need to be free to get any downloads at all. I won’t put advertising in the game, so there’s no chance of making any money from it.

I’ll also need to replace the graphics and sounds. I haven’t been able to track down the original developers so can’t get their permission to use their assets. I’m sure they’re great people and would have no objection to me using them, but I’d rather not get the game pulled due to a copyright dispute. Fortunately I know a couple of great artists who have expressed an interest in helping to replace the graphics, so that’s not too much of a hassle.

Releasing it as freeware is much cheaper (it’s free). If I can get the game listed on something like MacUpdate it should get plenty of exposure.

The last option is to open-source it. As a huge fan of open source software I’d love to do this, but I’m loathe to supply a finished game that someone else can release via the App Store themselves.

Anyway, the game in its present state is playable but has no presentation screens. The CPU is set to its hardest level, and restarting a game requires the player to restart the application. It has a few improvements over the DS version:

  • The larger screen let me include the blocks at the bottom of the two grids;
  • The garbage egg landing animation is more effective;
  • Eggs drop off the bottom of the losing grid when a game ends;
  • It includes the original background graphic from the Amiga game rather than the truncated DS version;
  • The incoming garbage indicator is in the original Amiga position at the edge of the screen, rather than on a separate screen where it can’t easily be seen.

Have a play and let me know what you think. Controls are included in the readme.


Woopsi 1.2 Released

Another version of Woopsi is out. Get it from the Woopsi website:

In my last Woopsi post I discussed the removal of the AmigaWindow and AmigaScreen-specific flags. I’ve decided to get rid of all gadget flags supplied as constructor arguments. This was the old way of creating draggable, borderless windows (ignore for a moment the impossibility of such a window):

AmigaWindow* window = new AmigaWindow(0, 0, 100, 100, "My Window", Gadget::GADGET_BORDERLESS | Gadget::GADGET_DRAGGABLE, true, true);

This is the new way:

AmigaWindow* window = new AmigaWindow(0, 0, 100, 100, "My Window", true, true);

There were multiple problems with the gadget flags idea:

  • Most gadgets weren’t set up to receive the flags in their constructors;
  • Impossible for the compiler to check for any errors;
  • Discovering which options were available for a given gadget was very difficult;
  • Annoying to have to constantly set the same options every time a gadget was created (windows are more often draggable than not, for example).

Instead, I’ve chosen sensible defaults that are set automatically in gadget constructors. If these need to be changed, they can be via the usual getters and setters available in all gadgets. The change leads to:

  • Less code;
  • Easier to create gadgets;
  • Fewer bugs that the compiler can’t catch;
  • A more consistent API.

This is another breaking change.

Let’s see what other bugs are in this changelog… (Rummages around the hard disk.) As mentioned previously, the Woopsi gadget creates a couple of background screens at startup to ensure that the background is always grey. These are now passed the Woopsi gadget’s style object, so if the colours have been changed by a developer the background will change to match. The ProgressBar gadget also accepts a style object in its constructor.

Disabling or enabling the border around a Label gadget now repositions its text to match. Getting rid of the flags system let me spot this one. Related to that, the Gadget class’ setBorderless() method is now virtual so that subclasses can react to changes in their border state.

One of the improvements I hoped to get in after implementing the damaged rect redraw system was to reduce the amount of redrawing done by textboxes. This is now in place. It’s not as efficient as I’d hoped because I’d previously opted for a design that eliminated code repetition. Whenever the text in a textbox is changed, an “onTextChanged()” method is called. Unfortunately, the method doesn’t know what the text was before it was called, so it can’t make informed decisions about how much of the gadget to redraw. For example, if the width of the text has shrunk, it needs to redraw the region covered by the original text. If the text has grown wider, it needs to redraw the region covered by the new text. I considered the benefits of redesigning this to be more efficient against the downside of increasing the complexity of the class, and decided to just stick with the current design.

What I did do was change the redrawing system so that it just redraws the total area within the gadget that could conceivably be covered by any text for the current font, which should save exponentially larger amounts of redrawing as the size of a textbox increases relative to its font size. The same thing happens when the cursor moves.

The Gadget class included a lot of methods for working with subgadgets, such as “addGadget()”, “raiseGadgetToTop()” and “lowerGadgetToBottom()”. It also included other methods for working with subgadgets such as “closeChild()”, removeChild()” and “shelveChild()”. The obvious inconsistency in the naming convention is now fixed, and all methods that previously referred to “child” now refer to “gadget”.

Lastly, the Bitmap class has a couple of new features. It has a real copy constructor, so it is now possible to create a duplicate of any bitmap that inherits from BitmapBase with no effort. It also has a “setDimensions()” method that will resize the bitmap in the same way that PhotoShop resizes a canvas. It doesn’t feature any clever scaling algorithms; it just increases or decreases the space available to draw on. Any existing data is preserved unless the bitmap is reduced in size, in which case data on the right and at the bottom is cropped out.

Instead of hosting the downloadable files on this website, I’m storing them on BitBucket. This is mainly just so I can easily see how often Woopsi is downloaded (uncannily-accurate prediction: not many).

The Woopsi todo list is growing increasingly short. In fact, there are less than half a dozen items left:

  • Create a tree gadget;
  • Create tab/tab group gadgets
  • Add a “Parent” button to the FileRequester and get rid of the “..” entry;
  • Add a file type filter to the FileRequester;
  • Rethink the appearance of the GUI - can I come up with something that looks better than the current Amiga-inspired design?

This last item is tricky. The more complex the GUI design gets, the more visually interesting it becomes; it also becomes more demanding on the DS. Is it worth trying to make the appearance more modern if it potentially causes slower performance?

As for the other items in the list, the FileRequester changes are fairly trivial (especially as the WoopsiString is now set up to make the file filtering task easier), and I’m not in any hurry to get the tabs or tree gadgets written. Other than that, there are a few things that I won’t implement that I’ll have to describe in a future blog post.


BitSyncPy Updated

BitSyncPy, my Python 3 utility for pushing/pulling/cloning/etc a whole directory of Mercurial repositories with BitBucket, has had a few updates. It now works under OSX (and should therefore work with Linux). It can also force local repository names to be lower case when cloning.


BitBug and BitBugPy

Another pair of C#/Python programs. This time it’s an idea branched from BugBare, my distributed bug tracker. The real problem with distributed bug trackers is their complete lack of utility and visibility for people who aren’t programmers on the project in question. BitBug dumps the distributed part and is really just a command line interface to BitBucket. All bugs are stored in BitBucket’s issues database. They obviously don’t work offline, but they’re as quick to use as BugBare and come with a ready-made web interface.

The two programs are here:

Of the two, BitBugPy is the tidier program. It uses the BitBucketAPI library for all BitBucket interaction, so the script itself is tiny. Again, it uses Python 3.2 (release candidate) so I’m sure 99% of the world won’t be able to use it. I’d look into making it a Mercurial extension, but - shock! - Mercurial is written in Python 2, not 3, and I’m not interesting in backporting it.

The C# version - BitBug - uses my MurkyCommando library as its command line UI. Since playing with the various command line argument parsers in Python I’m a lot less happy with it now.

They are both rather limited at the moment, mainly because the API offered by BitBucket is still a work in (very slow) progress.



Combining Python, the best parts of BitSync and BitBucketAPI has produced BitSyncPy. This is a very short Python 3 script that will:

  • Connect to BitBucket’s API using a user-supplied username and password;
  • Get a list of the remote repositories belonging to a specified user;
  • Get a list of local repositories in a specific path;
  • Print the total number of remote and local repositories;
  • List any repositories that are local but not remote;
  • Clone all repositories that are remote but not local;
  • Pull/update all repositories that are both local and remote.

It’s essentially the same utility as the C# version of BitSync, but it’s a fraction of the size and should be cross-platform. Note, however, that it uses the new argparse module included in Python 3.2 (yep, I’m running the release candidate) and so won’t work without modifications in the stable version of Python 3.1. It won’t work in Python 2 either.