Anyone reading this blog but ignoring the comments is missing out on all the intelligent posts at the moment. For anyone who has missed out, the enigmatic Steven seems to have joined the burgeoning ranks of Woopsi developers, and is currently engaged in ripping PALib apart and re-assembling the pieces Woopsi needs into what seems to be becoming a new abstraction layer.
This will make Woopsi independent from PALib, opening the door for any libnds developers to make use of it.
In other news, again based on conversations in the comments, I’ve split the Font class into FontBase and Font classes. The FontBase implements almost everything needed for a font; the Font class rounds it off by adding a 16-bit bitmap into the mix. In addition to this, Woopsi also has a MonoFont class. This allows for 1-bit bitmaps to be used as fonts, saving 15 bits per pixel. These bitmaps need to be arrays of unsigned shorts, with each bit representing a visible (1) or invisible (0) pixel.
Whilst playing with the font classes, I thought I’d have a go at implementing const-correctness. This is the mildly controversial technique of enforcing an API - if a parameter passed into a function shouldn’t be changed within that function, it should be passed in as a const. It’s controversial because it can make programming a little more fiddly, and has led to the creation of the “mutable” keyword (that lets const values become non-const, which seems like something of a waste of effort to me). The benefits far outweigh the cons, though, so it seems like something I’ll definitely need to implement throughout the codebase.
Back in the mists of time when I first picked up C++ I seemed to have the const stuff sorted, or so it seems from looking at my old code. I’ve just forgotten it over the intervening years.
The Gadget::GadgetType enum is history. Since I refactored the code it’s no longer used anywhere, and as Jeff pointed out in the first place, when you’re trying to allow subclassing it’s an approach that simply won’t work. I think the SimpleScreen and SimpleWindow classes are going to have to go the same way.
GraphicsPort now has a drawRect() function. It’s pretty much a copy-and-past of drawXORRect().
Lastly, there’s a new Animation class. Not tested yet - I’ll get around to making an AnimatedButton soon - but it allows bitmaps to be linked together to produce animations. The developer can play, stop and pause the animation, move through it to a different frame, set its playback speed, and make individual frames appear on-screen for longer than the playback speed typically allows. Animations can either not loop, loop with a wraparound, or ping-pong.