Developing a GUI in C++ and DirectX

// 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.

Speeding up GUI Rendering

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.

Conclusion

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!