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

I didn’t want to spend a lot of time implementing controls for my game GUI; I wanted to stick with the smallest set of controls that I could. So, I came up with a list of controls that I consider the minimum set for game GUIs…

· Static Text, Icon, and Group Boxes - vital. These controls label and group the other controls in a dialog box. The static control is crucial; the frame control we could probably live without, but it’s fairly simple, and in some cases can go a long way towards making a dialog box easy to navigate, so I’m including it. Icon controls should be simple, but should be able to animate, providing cool background animations in our dialogs and menus (ala Theif: The Dark Project).

· Buttons and Checkboxes - vital. Weird button types (flat buttons, pushbutton-style radio buttons) we can do without, but most games can’t live without a basic button and checkbox.

· List control - important. I’ve found list controls, especially multi-column list controls, indispensable when creating game GUIs. They’re used everywhere. You’re going to want a very intelligent, heavyweight list control, as good or better than the Windows List Control. For me, the list control was the most difficult control to implement.

· Sliders and scrollbars - Important. Famous for controlling sound and music volume. The bad news is that we’ll probably need horizontal and vertical flavors of these guys; the good news is that they’re so similar you can implement them very easily.

· Textboxes - Vital. You have to be able to enter your mega-3l33t, super-kewl player handle somewhere, right?

· Progress Bars - Essential for displaying hit points, “I’m almost done loading!”, etc.

Noticeably absent from this list are the spin button controls (which aren’t crucial, and irritate me to no end anyway), radio buttons (we can get by with a single selection listbox instead), and the drop-down combo box (again, we can just use a list box), and tree control. By making the listbox control smart enough to indent certain items, we can incorporate the functionality of the tree control

Tab controls aren’t included simply because my game doesn’t have enough of a GUI to warrant them, though your needs may differ.

Even with all the omissions, the “minimum” list might seem daunting at first, but we can simplify it quite a bit…

The list becomes much more manageable when we realize that the more complex controls are just clever combinations of other, more simple controls. For example, a scrollbar is basically just two buttons and a slider control. A checkbox is a static control and two buttons (one “off” button, and one “on” button). A plain old button could be implemented using three static icon controls (just show/hide the appropriate ones to get the button to “press”), so that you can reuse your drawing code. If you were really strapped for time, you could even implement a progress bar as a slider that’s moved by the computer, though I prefer having a separate control for this.

There are, however, disadvantages to this - namely, your GUI controls are going to take up more system resources than they really need. Think about it - each control is a window. Let’s say you’ve gone with the reuse philosophy, and have created a button control that’s really just three different statics. That’s three windows per button. Now, you build a scrollbar control, using two button controls. That’s six windows per scrollbar control. Build a List control using horizontal and vertical scrollbars, and you’re sitting at twelve windows per list. It adds up quickly.

So it’s really just another example of the classic tradeoff between “how fast can I develop it” and “how little resources can I get it to use?” If you need a very high performance, no-waste GUI, implement each control from the ground up. If you would instead a quick implementation, and don’t mind the performance hit, you might choose to implement your controls so that the only control that would actually draw to the screen would be the static, and all other controls would be made up of combinations of statics.

When building my GUI, I tried to create a good balance between these two extremes.

Now, let’s dive into the actual implementation of each control, starting with everyone’s favorite, the static label.

There are three kinds of static controls we’ll be looking at: static text controls, static icon controls, and frame controls. All three of these controls are very easy, because they take no messages - all they do is draw themselves at certain positions.

Static text controls are by far the easiest control you’ll ever implement - just draw your window’s caption at the upper-left of your window, and you’re done. If you’re especially through, you might want to add code to justify your text a certain way - for example, to center your text in your client rect, you might employ the classic centering algorithm - take the width of your window, subtract the width of the text you’re going to draw, and divide by two, telling you how many pixels “in” (that is, how many pixels right from the left window edge) to start drawing.

Static icon controls are a little tougher. Actually, the term “static icon control” is a bit of a misnomer, given that we want our icon controls to be able to animate. Even so, implementation of these icon controls isn’t tough, provided you’ve got a solid sprite library to handle all the details of implementing animation: checking the millisecond delta between this frame and the one that’s on the screen now, using this delta to determine how many frames your sprites should advance by, etc.

Icon controls only become painful to implement if you’re notredrawing your entire GUI system every frame. In this case, you’ve somehow got to deal with clipping the icon control, so that even though it’s being drawn every frame, it doesn’t accidentally overwrite pixels belonging to a window that’s sitting on top of it (but wasn’t changed, so therefore wasn’t drawn). I didn’t implement this - my GUI gets redrawn every frame - but if you’re faced with this problem, you might want to try setting up a clip list for each icon, using it to draw the icon, and re-evaluating it when any window is moved, closed, or opened. This may or may not be a viable solution - I just dreamt it up while writing this - but it seems to be at least a good jumping off point.

Frame controls are also pretty straightforward. I implemented my frame control by drawing a border around m_position, then drawing the window caption at about position (5,5), in client coordinates (that is, about five pixels right and five pixels down from the upper-left of the frame control), but you may decide you want something a little fancier.

The one complex thing you might want to do for your static controls is to change the behavior of the findwindow function slightly so that it “skips” all windows that are static controls. That way, if a static text control is sitting on top of a pushbutton, the user will be able to push the button “through” the static control.

Speaking of, let’s now take a look at how to implement that button.

Pushbuttons are only slightly more difficult than static controls. Your pushbutton control needs to keep track of whether it’s “pressed” (pushed down) or “unpressed.” It does this by implementing two virtual functions, wm_mousedown() and wm_mouseup(), which your main calcall() function needs to call when appropriate.

Basically, in wm_mousedown(), you set a boolean variable, which I call the “depressed flag,” to true, and in wm_mouseup(), you set it back to false. Then, in your drawing code, if the depressed flag is set, you draw the button “pressed,” otherwise, you draw it “unpressed.”