155 karma · joined August 11, 2014
Not sure exactly what you are referring you precisely? Happy to hear about it. Once you get the hang of what the ID Stack is for, normally you would push on the id stack for everyloop.
> I've found cases where the UI would lock, when flowing text
Never seen that sort of stuff happening.. if you do encounter issues of this kind please try to report them with some details!
There's literally about ~10 lines of specific imgui code in there other than the 35 lines of example code in the middle of the main function.
Your problem is perhaps that you don't want to engage in actually reading that code.
The sky is the limit and I am sure someone could sit down and reinvent debuggers which basically haven't been evolving for decades.
Even though RemedyBG is in infancy and there's plenty of work ahead, it has the ability to surprise us tomorrow with features that haven't been in any other debuggers.
Also check out http://www.radgametools.com/debug.htm
Nuklear was developed as multiple files and hastily merged at the last minute by its author before being tagged 1.0. I think it was a mistake especially as he copied the entire stb_xxx files inside. And unlike libraries like stb_image.h, if you want to use Nuklear you need to setup or copy a non-trivial backend anyway, so it's not a matter of include and ready-to-use.
(Dear ImGui which Nuklear is based on is 7 files including 4 headers as you know.)
To me the core value of those libs is that they are highly portable, designed to compile everywhere without any specific build system, and designed to be compiled from source code. Because they are designed as such, problems (such as error/warnings on some setup) are caught easily and fast.
Whereas for bigger libraries you either get the headache of binaries, either get the headache of figuring out their build systems and building from source which frequently fails. And as people don't frequently build themselves, portability problems aren't caught as often.
For a start there are 4 incompatible standard libraries (dll vs static, debug vs optimized) and that's already a big headache. Also to a mix, a bunch of Visual Studio versions with enough difference to make it frequent that one compiled for e.g. 2010 doesn't work with 2015 or vice-versa.
To me the nature of those small libraries (regardless of the number of source files) is that they are highly portable and designed to always be compiled from source code to prevent those issues.
That would very likely be done at a loss, the processing/clipping of ImGui is sufficiently fast.
> I still think there's a lot of implementation details that leak out when you're coding (the stuff with the double hashes for instance)
Yes the id-stack system is an artefact of the entire architecture but it's pretty trivial, transparent and a cost that is immediately amortized once you understand the UI architecture. Double-hash is a feature, would you prefer an UI system where every single widget would requires an explicit ID? Or worse, an explicit storage (like most RMGUI). Every piece of software involve implementation details. The details of QT can get pretty opaque if you ask me.
I am bit annoyed with people just theorizing on performance issues that they haven't experienced themselves. I wish people where spending a tenth of the time looking at the cost of naively using std::string or containers.
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.
I will provide an example app that use glScissor() and the fixed pipeline so no custom shaders will be required. However I am not sure how the performance will behave with widgets that frequently change the clipping rectangle. At the moment the system is optimised to minimize draw calls (I would like a typical "complex" tool to take under 0.5/1.0 milliseconds to build and render). I was actually considering moving the clipping rectangle within the vertex buffer so everything could be rendered in 1 draw call, which would simplify the code and be faster, but requires a custom shader. That is to say, it is an open ended problem and there's not one single solution.
I already pushed some tweaks and comments in the sample applications. Your criticism is perfectly legit and I aiming to simplify integration as much as possible so please don't hesitate to comment further if you had another go at it.
Thanks for your feedback (I am the author).
The example applications probably haven't received enough love. They are standalone apps and there is only so much you can shrink the code. If you are using your own engine it is likely that you've already done initialisation and you have helpers to load shaders easily.
Imgui.cpp/Imgui.h themselves are render agnostic to enable portability on embedded systems and consoles where OpenGL is unavailable so it is important it stays this way. However it is perfectly possible that we could rework the sample applications to become more like "drop-in" for a given architecture (OpenGL+glfw coming to mind as being a common case).
It also appears that I could make the OpenGL sample simplier by using the fixed function pipeline and the glScissor() function so I will try that.
This is a first release and it hasn't been used or touched by more than half a dozen people so it may take a few patches until I can make the sample application simpler.
Best. O.