Mason McCuskey - Developing a GUI in C++ and DirectX

Let me explain that a little better. Say we need a Super Listbox. We’ve got a normal listbox class, but it just doesn’t cut it for some reason; our game demands the Super Listbox. So we derive a new “super listbox” class from our regular listbox class. So far so good.

But how do we place the Super Listbox in our game’s dialog? Since the Super Listbox is specific to our application, it wouldn’t make sense for us to add functionality to our resource editor to support it. But, at the same time, how do we tell our GUI system that for this one particular instance (our game), we’d like all listboxes to really be Super Listboxes? That’s what subclassing is all about - it’s not an exact, technical definition, but it will suffice for now.

The approach I’m about to illustrate is what I call “subclassing at load time.” To understand it, let’s start with the basic loading code I described in the last section. We’ve got a load function, which recursively news, loads, and then adds windows. Specifically, we’ve got something that looks like this, in PDL:

// read total number of children for this window

// for each child…

// read window ID from disk

// new a gui_window derivative based on that ID

//…

// next child

To implement subclassing, I’ve told my window loading routine to “give the application a chance to create a window of this type,” like so:

// read total number of children for this window

// for each child…

// read window ID from disk

// give application a chance to create a window of this type

// if the application didn’t create a window, then new a gui_window derivative based on the ID

// else, use the application’s created window

//…

// next child

Specifically, I give the application this chance by way of a function pointer. If the application needs to subclass a window, it fills in the function pointer with the address of its own function. When the windows are loading, they call this application function, passing in the ID of the window they want to create. If the application wants to subclass a window from this ID, it news up the appropriate object and returns the new pointer back to the window. If the app doesn’t want to do anything special for this ID, it returns NULL, and the window function senses this and news up the appropriate default object. This method allows the app to “pre-filter” the incoming window ID bytes, and to override the default behavior for certain window types. Perfect!

Using a method like this gave me a huge amount of freedom when it came to creating custom controls. I went back and added code to my resource editor that would let me change the IDs that were saved for each window. Then, when I needed a custom control in the app, I just used my resource editor to change the ID byte that was saved for that window. Saved on disk would be the ID, along with the dimensions and all the other base-class properties for the custom control!

Real quickly - there’s another way to do this same thing, and that is to mirror the approach the STL has used when it needs to create things. The STL uses special “allocator” classes, which are sort of like “factories,” in the sense that clients tell them what they want created, and they create it. You could use this same approach for creating windows.

It’d work something like this. Create a class and call it gui_window_allocator or something. Implement one virtual function, say CreateWindowOfType(…), which would take in a given window ID and spit back out a brand new pointer to that window. Now you’ve got a very simple allocator class, which your window loading code will use by default to new up windows as they are needed.

Now, when your application wants to override the “new” behavior for the windows, you simply derive a new, application-specific gui_window_allocator class, and tell your window loading code to use this allocator instead of the default one. This method is similar to providing a function pointer, only with a bit more C++ thrown into the mix.

Here’s another miscellaneous tidbit for you that will help you if you’re trying to speed up your GUI drawing.

The key concept here, just like with optimizing any other drawing routine, is simply “don’t draw what you don’t need to.” By default, the GUI spends a lot of its time drawing stuff that hasn’t changed. You can, however, optimize this a little, by telling the GUI to only draw windows that are “dirty.” The windows set their dirty flag whenever their appearance needs to change, and they clear the dirty flag once they’re drawn.

There’s one catch - since our GUI controls might be transparent, when a control is marked as dirty, its parent window must also be marked as dirty. That way, when it draws itself, the background is still intact, since the parent window has also just redrawn.

I’d like this article to be as useful as possible, so now that you’ve read it, if there’s anything you’d like me to expand on, or anything that I’ve missed, please email me and let me know about it.

Also, check out my web site and my current project, Quaternion, at http://www.spin-studios.com.

And, if you get a chance, drop by http://www.gamedev.net.

But most importantly… have fun developing your game!

Mason McCuskey is the leader of Spin Studios, a game development team working to break into the industry by creating a great game, Quaternion, and getting it published. He looks forward to your suggestions and comments, and can be reached via his web site at http://www.spin-studios.com, or by email at mason@spin-studios.com.