Writing custom UI system for game...

Started by
15 comments, last by Toolmaker 17 years ago
Thanks Ezbez & Deyja; never considered that before.
a glorious rating++ for all! [grin]
Advertisement
Due to easter I haven't been able to follow this thread, but the thread does provide a few good ideas.

I like the example of the scrollbar, and it's good to know you people mentioned it.

However, how do you keep record of the widgets? A huge tree which holds all the parents and siblings, or just keep a reference to the top-level parents(ie, the Windows) and pass the events on from those? Or do you have, say a quad-tree, with a link to all the widgets and traverse that?

Right now, I use this:
Control -> Window
-> Desktop Window(Basically the parent of all Windows)

The WindowManager basically calls CascadeMouseEvent() on DesktopWindow, which will check which Window has the mouse over and then let's the mouse event cascade into that one.

However, if I want to inform the controls about all events(Except button down/up), it would perhaps be more efficient to have the DesktopWindow handle this, because in that case, the DesktopWindow detects which control gets the actual message, instead of each control going the same math.

Toolmaker

I've been using IMGUI. It goes against a lot of my instincts of "solid software" but works well enough for a game context.
Quote:Original post by Toolmaker
However, how do you keep record of the widgets? A huge tree which holds all the parents and siblings, or just keep a reference to the top-level parents(ie, the Windows) and pass the events on from those? Or do you have, say a quad-tree, with a link to all the widgets and traverse that?


I keep a reference to the desktop in the UIManager. For input, I register a callback once: inputManager.setInputListener(desktop)

Although I am a bit inconsistent because to render the UI I call uiManager.update() which in turn calls desktop.paint() (which calls paint() recursively for all widgets)

Quote:Original post by lightbringer
Quote:Original post by Toolmaker
However, how do you keep record of the widgets? A huge tree which holds all the parents and siblings, or just keep a reference to the top-level parents(ie, the Windows) and pass the events on from those? Or do you have, say a quad-tree, with a link to all the widgets and traverse that?


I keep a reference to the desktop in the UIManager. For input, I register a callback once: inputManager.setInputListener(desktop)

Although I am a bit inconsistent because to render the UI I call uiManager.update() which in turn calls desktop.paint() (which calls paint() recursively for all widgets)


Right now, my WindowManager receives all the mouse updates(I'm working in C#, using events for the normal mouse input stuff), and in WindowManager.Update(), I process the latest state(down-side: there's a chance I'll miss a click, so I might change it a bit to buffer any mouse clicks, since mouse movements just send the new X,Y coordinates).

So, I could just send all mouse events down into the DesktopWindow, which will send the events down into Controls and these will recursively send the events further down.

For Up/down/Click events, I can find the window which the mouse is hovering over, and then ask this Control to find out which of it's siblings the mouse is actually over(Again, a recursive function, which will eventually return null when none is found).

Toolmaker

Quote:Original post by Toolmaker
However, how do you keep record of the widgets?


class BaseWidget{    public BaseWidget Parent;    public List<BaseWidget> Children;    public InputBindings InputHandler;    public Rectangle{ get; }    // ...}


There's then one widget which acts as the root of the tree and has no parent. (and in my setup, contains window info) The root is then the only thing kept explicitly by the application.

This provides enough context for the input code to pick which widget is supposed to receive the input, which is then triggered.
Quote:Original post by Telastyn
Quote:Original post by Toolmaker
However, how do you keep record of the widgets?


*** Source Snippet Removed ***

There's then one widget which acts as the root of the tree and has no parent. (and in my setup, contains window info) The root is then the only thing kept explicitly by the application.

This provides enough context for the input code to pick which widget is supposed to receive the input, which is then triggered.


That's exactly what I'm doing right now, except i've called it DesktopWindow, and I then traverse the list of controls.

Toolmaker

This topic is closed to new replies.

Advertisement