Minor Changes and No$GBA

Just a few changes today. First up, debugging. The Debug class now has a printf() function (thanks again to Jeff), which renders the output(s32) method obsolete (it’s now been removed). It also receives a pointer to a Woopsi object when one is instantiated, which removes the need to pass gadget pointers around.

I noticed yesterday that dragging a screen down and then moving windows around within it caused those windows to wrap around and be drawn at the top of the display. I have no idea when this bug appeared, but it’s now fixed - the GraphicsPort clipping routine checks for this and clips as necessary.

All warnings are now fixed (except the Alert requester one, which I need to remind me that I need to finish that class), as per Jeff’s request.

Last changes of the day involve the skinning system. I’ve changed around the structs in an attempt to create a more generic description of a skin, and split it up into separate structs where appropriate.

I’ve fixed a few bugs in the interpretation of the data within some of the classes, too. Hopefully it should now be easier for subclassers to add skinning to other gadgets. It should also pave the way for allowing any skinned gadget to have focused, blurred, focus-and-clicked and blurred-and-clicked bitmaps (quite how you’d achieve a blurred-and-clicked gadget I’m not sure…). A few things to note in the skinning system:

  • Screen and window skins include the definitions for their decoration gadgets as sub-structs
  • To save tedious typing, screen and window decorations use a few of their parent’s properties (ie. font info, colour info, etc) instead of needing those values to be specified in their structs
  • Not every gadget implements every property (screens don’t do anything with the struct’s bitmap property, for example).

All of this requires documenting properly. The current documentation is completely out-of-date now, but I won’t bother fixing it until I’ve got at least a beta release ready. There’s no point - it will just change again.

One thing I should mention is that a new version of No$GBA has been released. This version is donation-ware - you have to donate $2.50 to download the latest version. It sounds like the author is struggling to make ends meet at the moment. I heartily endorse this product and/or service and suggest that you pop over to the website now and buy a copy. No$GBA is a fantastic emulator and it’s only £1.24 in real money.

You can find the website here:



Jeff on 2007-12-18 at 22:08 said:

How about changing alert.cpp to contain this then:

 #warning Ant: you need to finish this

and fix the buttonWidth problem. That way, its identifiably a reminder to yourself, not an accidental logic problem.

(Of course, we have code here thats got reminders like this that are three years old, and addressed to a guy who no longer works here - eh, do what I say, not what I do)

Jeff on 2007-12-18 at 23:11 said:

Ok, I just checked out the Debug::setWoopsi() approach and I think the problem with this is that it locks in the Debug panel - any application that wants to use Woopsi must have a debug screen compiled in even if it doesn’t use it.

I think the approach of having the Debug class know how to access a Woopsi singleton makes for better code isolation.

Consider the following “mydebug.h” which someone can put into their project.

#define MYDEBUG

#if defined(MYDEBUG)
#include "debug.h"
#define dprint(...) Debug::printf(__VA_ARGS__)
#define dprint(...) /*nothing*/

Now, you can pepper your application with dprint(“messages”) throughout, and by tweaking the MYDEBUG define you completely remove the Debug class from your executable

ant on 2007-12-18 at 23:13 said:

Yeah, that was my reservation about the approach I took. Plus, having the singleton in the Woopsi class is useful for other things. I’ll switch it around later.