2007-09-19

Woopsi - WindowSystemDS Gets a Name

The problem with DS homebrew is that everything is called xDS, where x is a very specific description of what the game or application is. To wit, we have “DefenderDS”: Defender, but on the DS, obviously. “AmigaGuideDS”: an AmigaGuide viewer, but on the DS. So it goes for all DS homebrew.

I’ve decided to go for something a little bit different, and renamed “WindowSystemDS” to “Woopsi”. As mentioned in the last post, this is a dodgy programmer’s pun on the name “BOOPSI”, a joke which only two bearded old men in the world will understand, and which will cause neither one of them to laugh or even raise a smile.

The problem with this name is that I’m heading into Linux territory, in which all programs have a meaningless name, usually an acronym, that tells you absolutely nothing at all about the program. They may as well all be called “x” for all the good the names do. I’m sure the only reason they’re not all called “x” is because there’s already a program called “x”, and it’d get overwritten if all files had the same name.

Anyway. On to more important things. Here’s a quick list of things I’ve changed/added today:

  • Added woopsi class and moved event handling into it
  • Moved bits and bobs around so that more is available in the base gadget class
  • Added a pointer to the active gadget in windows so that loops are no longer needed to find it
  • Changed filled rect function to draw vertical or horizontal lines instead of pixels
  • Changed window activation so that click events are passed to gadgets immediately, rather than requiring a second click, as the former makes more sense with a touchscreen

Of these, only the last two are at all remarkable. The filled rectangle function previously drew a rectangle pixel-by-pixel; the function now works out the dimension in which the rectangle is larger, then uses the smallest number of lines (horizontal or vertical) to fill the space. This will work up to 4 times the speed of the pixel-by-pixel approach, as PALib will use a 32-bit drawing routine to write 4 8-bit pixels in one command whenever possible.

The window activation thing was a bug - after I moved the activated window to the top of the stack and exited that function, I carried on using the same vector index I had for that window before the move in order to process the click events. This won’t work, as the window is no longer stored at that vector index. Duh.

Tied in with that, I’ve removed the “Stylus.Released” check and written an alternative way of handling release events. If the code doesn’t execute in one frame (at the moment, it doesn’t), “Stylus.Released” is always false (since it is reset at the start of each frame).