6 ms·

Using ImGui with modern C++ and STL for creating game dev tools – Part 2

99 points by eliasdaler 10y ago

flohofwoe 10y ago
Dear Imgui is absolutely awesome, first time in my life where I'm actually enjoying writing UI code. AFAIK it was an intentional (and IMHO good) design decision to not tie the API to the C++ std library, this makes imgui more widely usable, for instance in code bases that also don't use the STL, exceptions or RTTI (and that's quite common in the game development world), it also makes it easier to write wrappers for other languages. Check out what people have been doing with Dear Imgui: - https://github.com/ocornut/imgui/issues/123 https://github.com/ocornut/imgui/issues/123 - https://github.com/ocornut/imgui/issues/539 https://github.com/ocornut/imgui/issues/539
- speeder 10y ago
  ImGUI + EAStl must be awesome.
- eliasdaler 10y ago
  Yup, there's no doubt that it's awesome that ImGui doesn't force you to use some particular library. But for people already using STL and integrating ImGui with their codebase, using STL with ImGui may be somewhat difficult and that's why I wrote the article about things that worked for me. :)
golergka 10y ago
Immediate mode GUI still has a huge drawback - running UI code every frame. It's not a big deal with simple widgets, but with complicated UI, especially with some kind of automatic layout involved, it becomes a pain. In Unity3d game engine in particular, IMGUI was originally used, and it was a huge performance drain. Now all the "real" UIs have been moved to a new, object-based system (with a LOT of caching and optimization), but IMGUI is still used for quick prototyping and debug UIs.
- ocornut 10y ago
  You making a blanket statement based on what Unity (one implementation with its own particular design/features/requirement) did. I've rarely heard of people having unsolvable performance issues with dear imgui. The layout features and other features are carefully designed with performances in mind.
  - TillE 10y ago
    It's an inevitable drawback of the entire concept of an immediate-mode GUI that gets recreated from scratch on every frame. There are major types of optimization which are simply impossible. The vast majority of games use simple GUIs where it won't matter. But if you have a complex or large GUI, you will be eating up significantly more CPU cycles.
    - ocornut 10y ago
      Displaying a few hundreds widgets has absolutely negligible cost if the code is written properly. For large lists they can always be clipped and not submitted at all. With an immediate-mode GUI you can actually handle navigation of a list of one million items whereas more RMGUI would struggle because of all the intermediate data involved. Also, the optimization bottleneck nowadays is mostly programmer/brain time, so having a ten-fold productivity improvements means you can actually create more/better tooling and that has very direct consequence on your software performance. The reality with toolkits like QT is that people write very little amount of tooling with it, because it is so tedious. The cost of that are lost opportunity in improving a game engine and its performances.
    - flohofwoe 10y ago
      In my experience the main problem with performance in UI system is not layout, but draw calls and render state changes. There are some braindead UI solutions that build a hierarchical scene graph for rendering, with each node in the graph costing one draw call. Once you have such a system it doesn't matter whether the higher level parts follow the immediate-mode or non-immediate-mode philosophy, or if the scene graph itself is rebuilt each frame or not, just the render state changes and draw-call overhead will kill performance as soon as you have a few hundred UI elements on screen. Dear Imgui builds flat vertex buffers and a very simple command list where each command is basically 'please render this range of vertices with this scissor rect', and as I wrote above, generates about 1 draw call per window. Only a new clip-rect (e.g. a scrolling text frame) requires a new draw call. As an example, in my 8-bit emulator, the entire debugging UI, with all windows open (12 windows with a lot of scrollable text, buttons, lists etc...) costs 16 draw calls.
aDevilInMe 10y ago
<StlIsTheWrongName>If writing "modern C++", why do you want to use a really old library, STL, why not instead use the "Standard Library"? </StlIsTheWrongName>
- eliasdaler 10y ago
  "Standard Library" sounds better and I'll probably use it instead of "STL" in the future, but I'm not sure that "STL" is not used anymore or have been discarded.
- pjmlp 10y ago
  Because for those of us that started using C++ when C++ ARM was the only reference to it, the STL is a synonym of Standard Library.
- pandaman 10y ago
  I agree, I call it STD myself because of the namespace's name and the apt connotation.
  - ocornut 10y ago
    Software Transmitted Disease
- StephanTLavavej 10y ago
  As an STL maintainer, I can say that using "STL" to refer to "the C++ Standard Library" is a perfectly valid use of metonymy.
  - aDevilInMe 10y ago
    Do you not maintain threads, RegEx etc... ? At best STL can be reffered to as a subset of the Standard Library, which contains the algorithms and containers framework. I take Stroustrup's word over a maintainer with the intials STL, who has an interest to keep calling it by this name.
    - 10y ago
CyberDildonics 10y ago
I'm surprised immediate mode guis have taken such a long time to take hold. The separation of data and drawing in very elegant after having come from ui systems where your widgets essentially end up being data structures.
hellofunk 10y ago
How would this UI library work on an iOS OpenGL project? I would expect it to display fine, but maybe lining up the touches with the buttons could require some extra thought.
Keyframe 10y ago
For C, there's C wrapper https://github.com/Extrawurst/cimgui https://github.com/Extrawurst/cimgui and another library Nuklear https://github.com/vurtun/nuklear https://github.com/vurtun/nuklear which is also really nice.

99 points by eliasdaler 10y ago

Dear Imgui is absolutely awesome, first time in my life where I'm actually enjoying writing UI code. AFAIK it was an intentional (and IMHO good) design decision to not tie the API to the C++ std library, this makes imgui more widely usable, for instance in code bases that also don't use the STL, exceptions or RTTI (and that's quite common in the game development world), it also makes it easier to write wrappers for other languages. Check out what people have been doing with Dear Imgui: - https://github.com/ocornut/imgui/issues/123 https://github.com/ocornut/imgui/issues/123 - https://github.com/ocornut/imgui/issues/539 https://github.com/ocornut/imgui/issues/539

speeder 10y ago
ImGUI + EAStl must be awesome.
eliasdaler 10y ago
Yup, there's no doubt that it's awesome that ImGui doesn't force you to use some particular library. But for people already using STL and integrating ImGui with their codebase, using STL with ImGui may be somewhat difficult and that's why I wrote the article about things that worked for me. :)

golergka 10y ago

Immediate mode GUI still has a huge drawback - running UI code every frame. It's not a big deal with simple widgets, but with complicated UI, especially with some kind of automatic layout involved, it becomes a pain. In Unity3d game engine in particular, IMGUI was originally used, and it was a huge performance drain. Now all the "real" UIs have been moved to a new, object-based system (with a LOT of caching and optimization), but IMGUI is still used for quick prototyping and debug UIs.

ocornut 10y ago
You making a blanket statement based on what Unity (one implementation with its own particular design/features/requirement) did. I've rarely heard of people having unsolvable performance issues with dear imgui. The layout features and other features are carefully designed with performances in mind.
- TillE 10y ago
  It's an inevitable drawback of the entire concept of an immediate-mode GUI that gets recreated from scratch on every frame. There are major types of optimization which are simply impossible. The vast majority of games use simple GUIs where it won't matter. But if you have a complex or large GUI, you will be eating up significantly more CPU cycles.
  - ocornut 10y ago
    Displaying a few hundreds widgets has absolutely negligible cost if the code is written properly. For large lists they can always be clipped and not submitted at all. With an immediate-mode GUI you can actually handle navigation of a list of one million items whereas more RMGUI would struggle because of all the intermediate data involved. Also, the optimization bottleneck nowadays is mostly programmer/brain time, so having a ten-fold productivity improvements means you can actually create more/better tooling and that has very direct consequence on your software performance. The reality with toolkits like QT is that people write very little amount of tooling with it, because it is so tedious. The cost of that are lost opportunity in improving a game engine and its performances.
  - flohofwoe 10y ago
    In my experience the main problem with performance in UI system is not layout, but draw calls and render state changes. There are some braindead UI solutions that build a hierarchical scene graph for rendering, with each node in the graph costing one draw call. Once you have such a system it doesn't matter whether the higher level parts follow the immediate-mode or non-immediate-mode philosophy, or if the scene graph itself is rebuilt each frame or not, just the render state changes and draw-call overhead will kill performance as soon as you have a few hundred UI elements on screen. Dear Imgui builds flat vertex buffers and a very simple command list where each command is basically 'please render this range of vertices with this scissor rect', and as I wrote above, generates about 1 draw call per window. Only a new clip-rect (e.g. a scrolling text frame) requires a new draw call. As an example, in my 8-bit emulator, the entire debugging UI, with all windows open (12 windows with a lot of scrollable text, buttons, lists etc...) costs 16 draw calls.

aDevilInMe 10y ago

<StlIsTheWrongName>If writing "modern C++", why do you want to use a really old library, STL, why not instead use the "Standard Library"? </StlIsTheWrongName>

eliasdaler 10y ago
"Standard Library" sounds better and I'll probably use it instead of "STL" in the future, but I'm not sure that "STL" is not used anymore or have been discarded.
pjmlp 10y ago
Because for those of us that started using C++ when C++ ARM was the only reference to it, the STL is a synonym of Standard Library.
pandaman 10y ago
I agree, I call it STD myself because of the namespace's name and the apt connotation.
- ocornut 10y ago
  Software Transmitted Disease
StephanTLavavej 10y ago
As an STL maintainer, I can say that using "STL" to refer to "the C++ Standard Library" is a perfectly valid use of metonymy.
- aDevilInMe 10y ago
  Do you not maintain threads, RegEx etc... ? At best STL can be reffered to as a subset of the Standard Library, which contains the algorithms and containers framework. I take Stroustrup's word over a maintainer with the intials STL, who has an interest to keep calling it by this name.
  - 10y ago

CyberDildonics 10y ago

I'm surprised immediate mode guis have taken such a long time to take hold. The separation of data and drawing in very elegant after having come from ui systems where your widgets essentially end up being data structures.

hellofunk 10y ago

How would this UI library work on an iOS OpenGL project? I would expect it to display fine, but maybe lining up the touches with the buttons could require some extra thought.

Keyframe 10y ago

For C, there's C wrapper https://github.com/Extrawurst/cimgui https://github.com/Extrawurst/cimgui and another library Nuklear https://github.com/vurtun/nuklear https://github.com/vurtun/nuklear which is also really nice.