I'm just wondering how others do their game user interface screens. Do you use windows controls or do you do create them from scratch with your own mouse tracking/clicking routines?

All custom code. Surprisingly easy to do. You begin to wonder why Windows is so big :D

Cas :)

My current game uses OpenGL, and all the GUI is custom made... though it's quite simple. Only textual "buttons" ATM. Oh, and some text input thing too...
I'll have to improve that, probably.

Custom, on top of SDL, thus completely portable. For now I have Labels, Editboxes and Buttons, and a HTML-like layout manager (a layout model like the HTML table model, with rows of cells spanning a variable number of columns)

How do you guys handle button clicks?

Do you ...

[somewhere in main game loop]

check mouse input and position.

check position.

if position is in bounds of a pushbutton
highlight it.

if clicked,
display clicked image and set a state...


??

Well, speaking at a very high level, that's pretty much it.

I created an event model to handle user input. Events are things like Mouse In, Mouse Out, Gain Focus, Lose Focus, Key Down, Mouse Move, Select, Click, Drag Start, Drag Drop, etc., etc.. All of the control objects inherit from an ActiveWindow class that knows how to fire and respond to events. There is an Event Dispatcher singleton that tracks mouse and keyboard focus, samples the mouse and keyboard, and routes events to the appropriate controls.

Each of the various forms in the UI have callback methods that are registered with the appropriate controls and events. So for example, a form containing a list of missions and a text box describing them would have a callback method that gets triggered when the user makes a selection from the list. The form then asks the list what item is selected and displays the matching description in the text box.

Events aren't queued, and all of this happens in a single thread. When the event dispatcher detects user input, the code immediately calls the proper callback function (indirectly through a combination of virtual methods and function pointers). That way the code is theoretically reusable for future projects.

Milo,

You created a window class to handle Game User Interface, right? This is different from the "do it yourself" approach that others have described. Am I correct?

I'm not sure how to do Game User Interface under windows. DX doesn't allow standard Windows control under Exclusive mode, so I am assuming most create their own controls, and handle the mouse interaction themselves.

No, these aren't Windows window classes, they are C++ classes that implement custom windows in the game renderer.

There is class Window, which is the root of all evil. A window object is a rectangular area on the DX screen that can be filled with something. The window object calls out to class View to do application specific rendering. This is the interface base class for a strategy pattern. Each window can have a list of views that get called in order from back to front when the window needs to be repainted. The most common use of this pattern is the 3D renderer class CameraView, but it can also be used to implement full screen fades or the display of bitmaps, or level maps, or whatever.

Then there is the class EventTarget interface for things that need to respond to user input. Event Targets implement a bunch of virtual functions to handle events like virtual int OnMouseMove(int x, int y).

GUI stuff all comes from class ActiveWindow : public Window, public EventTarget. All of the GUI controls and forms are subclasses of ActiveWindow: Button, ComboBox, EditBox, ImageBox, ListBox, and Slider.

All of the GUI classes know how to draw themselves; they don't use View objects to move the drawing strategy out to a separate class. That might have been a useful alternative design if I had wanted to support something like Java's pluggable look and feel, where the whole style of the GUI can be reconfigured at run time by plugging in different view objects. But I didn't need that kind of flexibility so I took the simpler option of just letting the controls draw themselves.

The GUI input event logic is all done separately from the input logic that controls the player's vehicle.

We do both although most of the time in-game we use custom code. Our 2D game engine is game-state based (you can define a number of states in your game like PLAYING_LEVEL, TITLE_SCREEN, HIGHSCORE_SCREEN and so on...) and there are a few UI event callbacks for each state. So for instance theres an OnMouse event and things a little higher level like OnButton similar to windows callbacks.

Custom built UI here also. The benefits of an abstracted rendering engine and a custom UI is that the UI is much more portable. I had been trying to find a good UI library for ages, but none of the existing one seemed to fit my needs. After settling for the current custom solution a few years back I heard somewhere that Microsoft does the same. Eg. Office doesn't use the standard Windows widgets but has its own UI system .. :)

Originally posted by Kai-Peter
[...] I heard somewhere that Microsoft does the same. Eg. Office doesn't use the standard Windows widgets but has its own UI system .. :)
It's actually worse. The Excel team had their own C compiler because Microsoft's was too buggy for them :) (I read this in an old Microsoft book, was it Writing Secure Applications? The name was something like that)

Originally posted by Kai-Peter
Eg. Office doesn't use the standard Windows widgets but has its own UI system .. :)

well just because they wrote the os doesn't mean they have to use it's API :)

I guess they are more qualified than others to (re)write a GUI as they see fit ;)

Many of the changes that you see in new versions of windows got their start in the office development groups. A particular widget will show up in Office (like toolbars), people will use it and like it, and the next version of Windows will have that widget everywhere.