Creating Fonts and Bitmaps

More work on fonts. Jeff’s solution for creating PackedFont fonts is fantastic - instead of mucking around with u16 arrays, he subclasses the fonts and does all of the work for you. Instead of this:

PackedFont1* myFont = new PackedFont(somearray, somewidth, someheight, blah, blah);

…you have this:

NewTopaz* myFont = new NewTopaz();

So much easier.

I’ve shamelessly stolen this idea and reworked the existing “FontBitPacker” application so that it follows this pattern. I’ve heavily modified it so that the app will convert BMP files to either MonoFont, Font, PackedFont1 or PackedFont16 font classes. As long as they have version 3.5 of the .NET framework, Windows users no longer need to faff about with PAGfx or the bmp2font Python script. The new “bmp2font” .NET console application (which the FontBitPacker has become) will do all of the font conversion work needed for Woopsi.

This pattern seemed like such a good idea I’ve used it for bitmaps, too. Instead of converting BMP files with PAGfx, then using the “all_gfx” files to include the bitmap data before wrapping them up in a BitmapWrapper class, it is now possible to use a new “bmp2bitmap” .NET app to convert straight from a BMP file to a BitmapWrapper subclass.

These new programs have enabled me to delete the PAGfx binary and the files it converted from the Woopsi demo folder. I’ve replaced the converted files with classes converted with bmp2bitmap.


Woopsi 0.39 Released

A new release! Download it at the SourceForge page as soon as SourceForge decide to update the front page. In the meantime, here’s a direct link:

Woopsi Source 0.39

Excitingly, in upgrading to the new layout, SourceForge appear to have lost all of the release notes I painstakingly appended to each Woopsi release.

Anyway, here’s a quick recap of the features in this latest version.

New Features

The TextBox and MultiLineTextBox now listen for the d-pad and respond to left/right presses by moving the cursor in the corresponding direction. This only happens if the gadget in question has focus.

The source distribution includes a new “tests” folder. Now that Woopsi is maturing it’s about time that I tested it properly. Each gadget in the system will eventually have a comprehensive test application in this folder; for the moment, just the CycleButton and RadioButtonGroup have test programs here.

As mentioned in the last post, Woopsi can now load and save 24-bit BMP files. It has two new classes in the “bonus” folder - BinaryFile and BitmapIO - to handle this. There is a new “BitmapLoader” example in the “examples” folder.


As you’d expect, now that there’s a test harness for them, there are a number of bugfixes to both the CycleButton and RadioButtonGroup gadgets. There are few bugfixes to the base Gadget class that were similarly highlighted by the new tests. The Bitmap class also has had some fixes implemented to solve problems that arose when writing the BMP loader. Other bugfixes are listed in the changelog.

There are two important fixes that haven’t been mentioned on the blog before. Firstly, the problem detailed on the 11th in which overlapping gadgets were drawn incorrectly is now fixed.

The second bug arose from a similar situation. If a gadget is disabled and overlaps another gadget, any attempts to click the uppermost, disabled gadget fell through to the lower gadget. This is clearly incorrect behaviour and has been rectified. Disabled gadgets previously neglected to capture clicks; they now capture the clicks but do not react to them.

If you have implemented your own classes, or subclassed existing classes and overridden the “click()” method, you will probably need to change your code. The previous click() template looked like this:

bool MyGadget::click(s16 x, s16 y) {
if (Gadget::click(x, y)) {
    return true;

return false;

It should now look like this:

bool MyGadget::click(s16 x, s16 y) {
    if (Gadget::click(x, y)) {

        if (isEnabled()) {

        return true;

    return false;

Note the extra “isEnabled()’ check.

Known Issues

Just a small one. The RadioButtonGroup does not re-raise any events raised by its child RadioButtons. This means that it is impossible to listen for click/release/drag/etc events from a RadioButtonGroup. This is a minor problem, however, as these events are not particularly useful for this gadget. The useful event is “value changed”, which is raised.

Forthcoming Changes - The Fate of PALib Support

I mentioned back in January that I was no longer checking PALib compatibility. I think it is about time that I removed PALib support from Woopsi. It doesn’t make any sense to leave it in, as I’m not using it for anything, but it does clutter up the code and require an extra makefile. The next release of Woopsi will be PALib-free.


DevKitPro v24 Compatibility

Those of you keeping up with devKitPro releases will probably have noticed that Woopsi is not compatible with version 24 - devKitARM now includes a built-in “DynamicArray” type which was causing all sorts of problems. I’ve fixed that, plus I’ve reworked the hardware setup code to work with the new register names, touchscreen functions, etc.

A couple of notes on upgrading to handle devKitPro v24. If you call irqInit() and irqEnable() to switch on VBL interrupts, you’ll stop the touchscreen from working. That took ages to find and fix.

Lastly, a word on PALib. PALib has massive problems at the moment. Aside from the fact that the original author, Mollusc, now appears to have a real development job and has stopped maintaining it, the library hasn’t worked correctly with any of the recent devKitPro updates. In fact, you could argue (as most of the GBADev guys do) that PALib has never really worked correctly; I fixed plenty of bugs in it myself trying to get it working. Anyway, Woopsi currently works with dkp24 (when built with the libnds makefile) and also with dkp23 (when built with PALib and the appropriate makefile). However, I can’t maintain the two environments on my laptop at the same time (not enough disk space for two 10GB virtual machines until I can afford to get a new hard disk - not so easy now that I’m a student again and spent Christmas in Italy). This means I’m not checking compatibility with PALib any more, but as the hardware-hitting code shouldn’t change, I don’t foresee any problems. Unless the PALib maintainers do something crazy.

Anyhoo, latest change are in SVN. Expect a real release in the next few days. The only change that could affect user code is the name change from “DynamicArray” to “WoopsiArray”.


XCode PALib Template

Following on from the previous post about getting PALib and devKitARM set up in OSX, here’s some instructions for creating a PALib template project:

  • Download the PALib XCode Template
  • Unzip the archive
  • Drag the resultant folder to “/Library/Application Support/Apple/Developer Tools/Project Templates”

All done! To create a project using the template:

  • Fire up XCode
  • Choose “File/New Project” from the top menu
  • Select “PAlib” from the template list
  • Click “Next”
  • Choose a project name and a location for the project
  • Click “Finish”

You’ve now created a basic PALib project that will compile (ROMs are put in the “release” folder) and run in an emulator.


Woopsi Version 2 Ideas #3, PALib Licencing, and Woopsi Docs

More Woopsi ideas that might make it into version 2. First of all, I pre-ordered a GP2X F200 as soon as I received an email announcing it. I’m hoping that the d-pad isn’t as spectacularly unusable as the mini joystick employed on the original GP2X and the three revisions of GP32, and I’m also hoping that it won’t suffer from the quality control problems that plagued the first edition of the F100 (though mine doesn’t seem to have any of the reported issues).

Anyway, rubbish d-pad or not, I’m planning on investigating the possibility of porting Woopsi to the new GP2X. Unless GPH manage to screw up the touchscreen as badly as they screwed up the joysticks, that is - if that happens I’ll just write it off as a bad idea.

Another idea - as I’m going to have to alter all of the hardware-specific sections of Woopsi for the GP2X anyway, I might look at stripping the PALib code out at the same time. I foresee there being two major barriers to widespread adoption of Woopsi - firstly, it uses C++, whereas most DS developers probably use C, and secondly, it uses PALib, which abstracts away the complexities of the hardware and is therefore frowned upon by the more purist homebrewers. C++ has to stay, as only a crazy person (or Linus Torvalds, apparently, who it seems will approach every problem with the same rusty screwdriver he’s been using for the past 20 or so years, because he’s seen a few people make a mess when using other tools such as step ladders or those new-fangled electric screwdrivers) would try to write a GUI with C when there are more suitable alternatives around. PALib isn’t a necessary requirement, however, and it would be annoyingly tedious but possible to strip it out of Woopsi and replace it with libnds calls instead.

On a side note, I’m slightly disturbed to discover that no-one seems to know what licence PALib has been released under. SourceForge lists its licence as “None Listed” (helpful), whilst no-one on the PALib forum has responded to a question I posted about it. The PALib installer doesn’t contain a licence or any mention of one. It doesn’t even have a copyright notice anywhere. To me, this suggests that it’s considered public domain. Either that, or choosing a licence didn’t occur to the developers. If it’s the former, then I could strip out the PALib dependency simply by merging the functions I use into the Woopsi sourcecode. If it’s the latter, then I’m dubious about using PALib when I have no idea what terms I’m implicitly agreeing to follow every time I hit the compile button.

Some other things that I think may be potential barriers to Woopsi adoption are:

  • It looks like an operating system from the early 90s
  • It hasn’t been designed specifically for the DS’ ergonomics (contrast with the beautiful iPod Touch/iPhone interface)
  • Homebrewers generally don’t want to use other peoples’ code - they want to create and discover things for themselves

I disregard all of these minor barriers because they are intentional in the design of Woopsi - I want to create an interface that looks like Workbench 3.0.

Here’s an idea that I want to integrate into version 1 - bitmap buttons. These are just like standard buttons, except they display a bitmap instead of text. When held down, they show a different bitmap. Should be easy to implement.

The addition of bitmap buttons will let me take Woopsi in unusual directions. For example, we can create a window the size of a screen, make it borderless, and add a superbitmap to it. We can then add a set of borderless bitmap buttons, and we’ve created an interface more akin to MenuDS than a windowing system.

Lastly, I’ve added a load of documentation to the Woopsi SourceForge project, which you can find here: