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: