Readit NewsEveryone seems to want 9234567345863489634589 fps, when that's IMO completely absurd for a normal desktop app, e.g. editor! What you actually want is low latency, not constant massive bandwidth and power usage. If all your normal desktop apps constantly ran at uncapped FPS, your computer would scream and laptops wouldn't last 5 minutes on battery.
Engines are the easy part.
The real meat & potatoes is all the tooling and content and asset pipelines around the engine. If you think about it, you need to implement:
- importing data from various sources and formats, textures, audio, model files such as gltf, fbx, animations etc etc.
- editor app with all the expected standard editing features, cut, copy, paste, undo, redo, save, delete etc.
- all the visualizations and operations that let the game developer use the editor to actually create and manipulate data, entities, animations, scenes, audio graphs, scripting support etc. etc.
- all the data packaging and baking such as baking static geometries, compiling shaders, resampling and packing textures, audio, creating game content asset packs etc
- etc etc.
When all this is done you learn that the actual game engine (i.e. the runtime part that implements the game's main loop and the subsystems that go brrr) is actually a rather small part of the whole system.
This is why game studios typically have rather small teams (relatively speaking) working on the engine and hordes of "tools" programmers that can handle all the adjacent work that is super critical for the success of the whole thing.
The sum of all those parts IS the actual meat of the engine imho.
People mistakenly assume that rendering something and having a Dear ImGui frontend constitute an engine but it's only the tip of iceberg. Actual real world issues, productivity concerns, getting shit done is the meaningful work.
These are some pretty bold statements.
* "They wouldn't exist in the first place" implies that ImGui was the primary reason and foundation for creating these programs. As if using the traditional retained mode GUI is so unbearable that without ImGui the authors would have abandoned the idea of creating these tools in the first place.
* "Or wouldn't be as full-featured" implies that ImGui is either more full-featured or (if you meant time) is faster to develop with compared to a traditional retained mode GUI.
> I'm surprised this is so hard to comprehend?
Well, I'm surprised that some people keep presenting the immediate mode GUI as the silver-bullet alternative to the traditional GUI. Don't get me wrong: I understand that IMGUI is a great tool if you need to quickly add a throway GUI to a game, but otherwise there is a price to pay, both by the developer and the end user.
I'm saying it is making some development - those that are well aligned with the frameworks qualities - particularly efficient. Efficiency and productivity are everything. Productivity is often a major contributor in bridging the gap between cancelled and released, between painful and pleasant, between under-featured and full-featured, between abandoned and maintained, between unprofitable and profitable.
So while not saying things are simple to describe and compare, they are not, Dear ImGui focus on high-productivity is the reason why it has been adopted by some people.
> without ImGui the authors would have abandoned the idea of creating these tools in the first place.
It is probable those particular authors would have, yes.
I meant, it's not a secret that many engineers are totally afraid or uninterested in UI programmers. A common feedback is of certain people saying "hey, dear imgui made UI programming fun for me". So I'm confidently saying that SOME software wouldn't have existed without dear imgui. It being so brutally different in term of philosophy, coding style, culture, by definition makes it reach a different crowd.
> implies that ImGui is either more full-featured or (if you meant time) is faster to develop with compared to a traditional retained mode GUI.
Dear ImGui is clearly LESS full-featured than e.g Qt, but for some uses is is faster to develop with than most other frameworks.
It's used for quickly hacked debug tools to interleave UI and regular logic and not do a logic/view separation (as it would result in code bloat and a necessity for a refactor). You want UI code do some logic (like modifying properties of some game entity or renderer) and prefer to inline it. Lots of game code is effectively YOLO without even a single test. It's also typically guarded by IfDefs and compiled out of release versions.
But as soon as it stops being just hacky debuggers and people try to write proper tools in it, it becomes much more of a pain - people try to (poorly) emulate a retained mode in it, hold state, cache - and it becomes unreadable mess.
Effectively people are hasty and don't spend the time to try doing things nicely, in particular because the first steps and debug use allow you to do quick things.
But I don't think it's a fundamental property of IMGUI or Dear ImGui that "proper tools" become particularly more of a pain. Of course it is more work to make a proper tools than hasty-debug-tools, and I can easily see how underengineering can back-fire (over-engineering it likewise).
I'm talking about having two labels in the center of the screen, making them full width, making the text word wrap, and having each label flow properly when resizing the window. That requires calculating word wrap for each label plus knowing where labels visually higher on the y-axis have decided to place themselves after considering word wrapping. Labels beneath other labels should get pushed downward when word wrapping occurs.
That seems really hard to achieve in immediate mode libraries without effectively recreating retained mode functionality yourself.
The purpose of an IMGUI is to handle whatever data retention will simplify user's life. If you want to extend the IMGUI in some case it's perfectly adequate to do some that work yourself. Ideally the IMGUI infrastructure would make it as painless as possible.
So yes, the experience was not good, and I don't see what these tools would lose by using a proper GUI. I don't want every utility to drain my laptop battery like a decent video game.
ImGui is great if you already have a loop where everything is unconditionally redrawn every frame, but otherwise it's a really odd choice for an end-user application.
It seems like an issue of how it is implemented. I think Tracy does it well. It's party my fault since Dear ImGui lib and backends currently doesn't have an "official" way to tackle this, so everyone does their own sauce and it's easy to make a mistake. But I have zero doubt it is doable.
> I don't see what these tools would lose by using a proper GUI.
What they would lose is that they wouldn't exist in the first place or wouldn't be as full-featured. I'm surprised this is so hard to comprehend? In spite of its shortcomings, software like Dear ImGui is an enabler to make things exists and happen.