Game Development Reference
In-Depth Information
2.2I
MMEDIATE
M
ODE
Animmediate mode user interface does not keep any state, the code must be executed every
frame and the information displayed will be in real-time. This means than rather than cre-
ating objects for labels, buttons and such, we do function calls and we pass into them the
information on how they need to be drawn precisely at that moment.
std::string itemNames[] = { “a”, “b”, “c”, “d” };
int selectedItem = -1;
for ( int i = 0; i < 4; ++i )
{
if ( radio(selectedItem == i, layout, itemNames[i]) )
{
// if true, we update the selected item's index
selectedItem = i;
}
layout.y += layout.height;
}
For example, if we need to draw a group of radio buttons.
rectangle layout { width=40, height=10, x=0, y=0 }
Where the radio function may take the form,
bool radio( bool selected, const rectangle& rect, const std::string& text)
{
drawRectangle(layout, selected ? SELECTED_COLOR : INACTIVE_COLOR);
drawText(layout, text);
return isSelected(layout);
}
The benefit of this approach is that the user does not have to worry about object creation
or lifetime, information passing or synchronization, essentially, the data is owned by the ap-
plication and not the user interface.
On the other hand, there is a performance cost incurred per-frame for every function call,
complex UIs may require more function calls per frame possibly tying the performance cost
to the complexity.
This approach holds well for modest UI needs, in particular if memory is tight, however,
as the complexity of the UI rises, this UI code becomes more difficult to maintain. We can
imagine having a set of flags that control the visibility of UI components, if not done with
careandforethoughtthecodemayendupwithmanycomplicatedif-elseconditionsthattest
multiple flags, creating edge cases and complex relationships.
