next »

[Orz]

They seem like a good idea, but I haven't seen many complex or non-trivial examples.  Anyone here had experience using this design pattern and would care to elaborate?

[ProgramGamer]

I've made a barebones implementation of my own, and the main draw is that it's quick to setup and doesn't require you to build a tree of canvases and elements to display your interface. The drawback is that you have to redraw your entire UI every frame and that you have to worry about storing the state of your UI elements yourself somewhere. Plus, you can't use an interface editor like in visual studio if that's something you care about.

They're mainly used for debug interfaces as far as I know, but some people have claimed to have made complete applications in the paradigm.

[Daid]

They seem like a good idea, but I haven't seen many complex or non-trivial examples.  Anyone here had experience using this design pattern and would care to elaborate?

I did this for my (free) game http://daid.github.io/EmptyEpsilon/ back in 2015. The project has quite a bit of UI, and the "Immediate mode" quickly became a pain, and thus I replaced it with a OO widget based implementation.

To do Immediate mode properly, you have to keep track of a lot of state somewhere (which I didn't) or else you run into issues like:
* No way to manage layout of widgets: My solution was a lot of hard coded positions, which was no fun when you wanted to change things. Quickly became a pain in the ass.
* No way to have focus on anything (like text fields): My solution, text fields always had focus, and only 1 allowed at at time.
* No way to have overlapping widgets, as you don't know during the intermediate call if there is a button to be drawn on top of you: Fixed it by dropping Immediate mode.


Feel free to check out the code, this was the state of the Immediate mode code, see the master branch for the widget based code, which has a lot more features, and thus is a lot more code.
https://github.com/daid/EmptyEpsilon/tree/af6e3eb6a2b1247ed655515935307624b77e04fc/src/gui

[qMopey]

You can make very complicated and elaborate things with IMGUIs. It is however a very "programmer friendly" approach, and not suitable for designers or artists alone. The assumption is the user is quite good at engineering and very comfortable writing code to do whatever they need.

I've used Dear IMGUI professionally, and in my own personal code at home, and have only good things to say.

[Orz]

No way to have overlapping widgets, as you don't know during the intermediate call if there is a button to be drawn on top of you

Thanks! This is exactly the kind of thing I wanted to know.

I've used Dear IMGUI professionally, and in my own personal code at home, and have only good things to say.

Such as?

[qMopey]

Such as the kind of stuff on the Dear Imgui readme.

[Schrompf]

Have used an immediate GUI in the past, but it was limited to very fixed and small setups, like a game main menu with like five options to select from. In my impression it gets ugly quickly, and for my Steam game I wrote a widget-based library instead that performs layouting.

[JWki]

I'm a dear imgui addict, it's the single best UI library for C++ I've ever used and probably ever will use unless I write my own which I don't really see myself having time for.
The things that I find great about it are partly specific to the library and not necessarily to the immediate UI paradigm, however, it also plays a big part - for a code-centric workflow, it's incredibly intuitive and easy to use to write both simple and very complex UIs. I've used it to create everything from very simple ingame debugging tools to user facing desktop app prototypes. What's a bit lacking about dear imgui specifically is layouting support, but I added my own layouting primitives on top that work with the immediate approach and don't need a retained mode API to function. That being said, a lot of this just works because dear imgui itself does a lot of state caching in the implementation, but as a user you don't really need to know about that. People often - wrongly - assume that an immediate UI is not allowed to cache or retain any state and thus dismiss it because that has very limiting implications. However, the true nature of an immediate UI lies in how the user builds and submits the interface - so in the API, not the implementation.
I also have experience using QT which is a pretty solid framework for retained UI, and while its slot-and-signal based binding model is quite sane and intuitive, I still much prefer the interleaved polling model that an immediate UI uses, it's just much more dynamic and straightforward (as polling models tend to be compared to callback / signal edge approaches).
Unreal Engines Slate, while being retained, has an interesting data binding model which I'd like to explore further, personally, based on delegates and polling - it adds an indirection to separate data from representation, but does away with state duplication - rather than the UI retaining a data model for you, it still pulls from your existing model, with you being in control of conversions / transformations of the data in a just-in-time fashion. This is a model that I personally find attractive for retained mode UIs. TBH, I think an optimal solution wouldn't be purely immediate or purely retained, but rather a hybrid of some sorts. However, I feel like building a higher level retained API on top of a low level immediate API is much more feasible than the other way around.

To summarize, I really like and recommend the immediate UI paradigm even and maybe especially for complex UIs. It interleaves UI logic with representation, which I personally count as a good thing, but peoples opinion on this differ.
You can build very very dynamic UIs with it, with an ease I haven't found when doing similar things in QT or other retained mode UIs. However, atm there's only a single openly available implementation that I would recommend, which is dear imgui. If all you need is UI logic and rendering, it's the first thing I'd recommend by a long margin. However, it's probably not the best for ingame UI - since you want more advanced styling and animation support there, however you can do that with an immediate UI in general, just not necessarily with dear imgui - but it's unbeaten for fast-iteration in game tools, and has proven to be solid even for desktop apps like more serious editors. However, for the latter you will also require more than just UI logic, and more mature application frameworks like QT provide such functionality that you would have to roll yourself otherwise, which isn't for everyone (especially if you wanna be crossplatform), while coming with a retained mode UI approach that isn't the most fun or fastest to work with, but is extremely solid and comparatively sane. It still allows for a code-centric approach, which I personally find extremely important since I'm a programmer and loathe having to edit XML files to build an interface (or use a visual editor) ((looking at you, WPF!)).

[Crimsontide]

Soon I'll be looking at creating my own UI (C++/Vulkan), so I've been watching this thread with great interest.

If you could write the API for an immediate mode UI, what would it look like (obviously very simple overview)?  How do you envision it being used?  How do you handle user input?  Manage state?

I've looked at immediate mode UI APIs before, but I felt I lacked the experience to really see the forest for the trees, how things meshed together, and why it would be better.

[qMopey]

I made an immediate mode GUI for my own game. It’s for in game UI and well as debug tools. The thing about implementing IMGUI is that it’s supposed to be really simple for the most part. There isn’t much to it. I cache a lot of state for window positions, scaling, and the order of the windows. My layout is *very* simple. Only rectangular widgets. When a widget appears it only lays out down or optionally to the right. I don’t do anything particularly fancy, like rows or columns, or overlapping widgets.

For text input I use stb_textedit.

The API is just a few functions, like start window, stop window, submit draw calls, and then the widget functions, such as buttons, sliders, input text, scrolling text, portrait, and anything I need.

[JWki]

One thing that a few ui libs do and that I've found really important is to make it completely gfx api agnostic - which is a lot simpler with ui compared to say a 3D renderer. This goes both for retained and immediate mode.

[Daid]

I suddenly remember why I went for a IMGUI initially, the reason was simple, style of the code. I like the button definition and action to be close together, for example:

Code:

void gui()
{
  if (guiButton("Self Destruct"))
  {
    if (ship.canDoSelfDestruct())
      ship.startSelfDestruct();
  }
}

with "classic" C/C++ you generally get code like this with widgets:

Code:

void init()
{
  guiButton* button = new guiButton("Self Destruct");
  button.setHandler(handleSelfDestruct, &ship);
}

... a lot of other code

void handleSelfDestruct(void* userdata)
{
  Ship* ship = (Ship*)userdata;
  if (ship->canDoSelfDestruct())
    ship->startSelfDestruct();
}

which disconnects the action from the button definition, and makes it harder to pass data.


However, with C++11 lambda's and std::function, this no longer is an issue:

Code:

void init()
{
  guiButton* button = new guiButton("Self Destruct");
  button.setHandler([&ship](){
    if (ship.canDoSelfDestruct())
      ship.startSelfDestruct();
  });
}