31–40 of 128 posts
I believe Rebol's GUI support is even easier to use than ImGUI, but of course it can't be embedded and used in the same way as ImGUI either. I wonder if non Red projects could possibly hook into Red's system once Red/System gets closer to C level performance?
Earlier quoted context omitted.
I've written real-time game UIs before so I think I have some relevant experience here. 1. It is very possible to write a retained-mode GUI in a graphics API like DirectX or OpenGL. In fact, a retained GUI would typically wipe immediate GUIs in terms of performance in this context. In immediate mode, the GUI's vertex buffers need to be completely reconstructed from scratch every single frame, which is slow , CPU boun…
I didn't say that it's not possible to solve these problems in a retained GUI, just that existing ones, QT, Win32, WPF have these problems. And since writing a full retained GUI is not exactly trivial, people just wrote mini-GUIs using immediate mode. When I talked about retained mode APIs, I was thinking about scene graphs, where you say "addMesh" or "addSphere" and then just call "renderFrame". I'm aware that most…
You can absolutely use Win32 Forms and WPF (and probably Qt) with a game. They can be overlaid on top of a DirectX or OpenGL window (with a transparent background) -- I've done it before! I don't think it would have any of the downsides you mentioned, either, except that it wouldn't be GPU accelerated or actually rendered inside the graphics context, which is why nobody actually does this in practice.
But that ignores the dozens of GUI middleware specifically designed for games. A cursory Google search reveals that most of these are going to be retained mode. There's a reason for that. Projects like ImGUI appeal to mostly indie devs who don't have the time or resources to write their own GUI library or license some third-party middleware. And it's probably going to be just fine for their use case. But it's definitely not a perfect solution and we definitely shouldn't throw away decades worth of knowledge and experience like the article is implying.
It's important to point out why games use immediate mode GUIs: 1. The GUI needs to be overlaid on the game image (OpenGL/DirectX). This is difficult with traditional GUIs like QT. 2. The GUI needs to be updated in sync with the game, again, it's difficult to integrate traditional GUIs event loops into the game loop, especially with stuff like double/triple buffering. 3. The GUI needs to be as fast as possible, games…
I've written real-time game UIs before so I think I have some relevant experience here. 1. It is very possible to write a retained-mode GUI in a graphics API like DirectX or OpenGL. In fact, a retained GUI would typically wipe immediate GUIs in terms of performance in this context. In immediate mode, the GUI's vertex buffers need to be completely reconstructed from scratch every single frame, which is slow , CPU boun…
(Every UI I worked on actually did redraw everything every frame anyway. It's really not a big deal. Your average GPU can draw a monstrous amount of stuff, something quite ridiculous, and any sensible game UI that's actually usable will struggle to get anywhere near that limit.)
Earlier quoted context omitted.
I didn't say that it's not possible to solve these problems in a retained GUI, just that existing ones, QT, Win32, WPF have these problems. And since writing a full retained GUI is not exactly trivial, people just wrote mini-GUIs using immediate mode. When I talked about retained mode APIs, I was thinking about scene graphs, where you say "addMesh" or "addSphere" and then just call "renderFrame". I'm aware that most…
Sorry if I misinterpreted your post but I don't think that changes my response much. You can absolutely use Win32 Forms and WPF (and probably Qt) with a game. They can be overlaid on top of a DirectX or OpenGL window (with a transparent background) -- I've done it before! I don't think it would have any of the downsides you mentioned, either, except that it wouldn't be GPU accelerated or actually rendered inside the…
Earlier quoted context omitted.
I've written real-time game UIs before so I think I have some relevant experience here. 1. It is very possible to write a retained-mode GUI in a graphics API like DirectX or OpenGL. In fact, a retained GUI would typically wipe immediate GUIs in terms of performance in this context. In immediate mode, the GUI's vertex buffers need to be completely reconstructed from scratch every single frame, which is slow , CPU boun…
I've written real-time game UIs too. I think you underestimate just how ludicrously fast CPUs and GPUs are, and overestimate the complexity of your average GUI. What does your average screen's-worth of GUI consist of, after all? How many widgets are there? I double dare you to tell me that a modern computer or games console can't handle 500 widgets per frame. And I now triple dare you to tell me that your UI designer…
Why settle for "good-enough" performance?
Really probably not. I love them and they're very handy in certain situations (debugging tools, quick UIs) but once you need a lot of customization they become extremely cumbersome. Also really kind of makes it impossible for designers or less technical people to do anything. Also, while I think separating view logic is slightly overrated, it is useful, and it's very hard to do that with IMGUI. Also it doesn't thread…
It's important to point out why games use immediate mode GUIs: 1. The GUI needs to be overlaid on the game image (OpenGL/DirectX). This is difficult with traditional GUIs like QT. 2. The GUI needs to be updated in sync with the game, again, it's difficult to integrate traditional GUIs event loops into the game loop, especially with stuff like double/triple buffering. 3. The GUI needs to be as fast as possible, games…
I think 1, 2 and maybe 3 could all be done with a traditional retained mode GUI, and indeed there are retained mode GUI systems for games. The big traditional UI frameworks just have not been made to work well with games. Which is fair, game engines are alien environments that may as well be considered their own platforms. > It's worth pointing out that the immediate/retained split doesn't apply only to the GUI Indee…