4 ms·

ImGUI has backends for every graphics API in regular use, and some that might be considered deprecated (DX9). Including game engine abstraction layers in Unreal

ImGUI has backends for every graphics API in regular use, and some that might be considered deprecated (DX9). Including game engine abstraction layers in Unreal and Unity and console properietrary APIs (not public, of course). Here's a full list of public graphics APIs and windowing systems part of the official release (https://github.com/ocornut/imgui/tree/master/backends https://github.com/ocornut/imgui/tree/master/backends). Maybe with the exception of stb_image, it's only of the most integrated open source libraries in games and graphics

greggman3 6y ago
it's a mistake to think Dear ImGUI has "backends". Dear ImGUI is a few files that generate a vertex list. It then as a bunch of "examples" that show how to render that list with various APIs. Any slightly competent graphics programmer could take that vertex list and render it in any API. Those Examples are not Dear ImGUI. They are just examples. This is the code for each command list upload vertex data upload index data set scissor bind texture draw That's it! Adapt that to any API, whatever your using Because it's an example and because so many unexperienced programmers use it they assume it's some official part of the library. It's not.
- nitrogen 6y ago
  You both seem to be right, based on this commit message: > Moving backends code from examples/ to backends/… 24 days ago
  - greggman3 6y ago
    Moving them from examples to backends doesn't change anything. That's likely just a sign that "examples" is now examples of using the API, not examples of integrating with some GPU API. One of the main reasons/goals/points of Dear ImGUI is being able to ingrate it into existing projects. It's deliberately API agnostic. It generates a very simple command list that you can then trivially render yourself in your own engine. Everything else, all the platform specific code in the repo is entirely there to help people understand how to use it or to get started. It's a mistake to think otherwise because it incorrectly limits Dear ImGUI's perceived usefulness. If you believe you have to take a backend or use one of the APIs provided then you'll mistakingly believe it would be hard to put in your existing game. If you understand what it's really about then it's trivial to put it in almost anything. That is by design.
    - midnightclubbed 6y ago
      I had different feelings about the examples. Seeing example integrations into so many rendering apis reassured me that it would be trivial to add Dear Imgui in to my own projects. Without the examples you have to take it on faith that they designed their api to be easily integrated. Many libraries claim to be cross platform and turn out to be hugely painful to use on anything outside of a few intended targets. I still have nightmares about Scaleform!
    - ocornut 6y ago
      Hi gregg :) I think it's a bit of both. From the point of view of game programmers and custom engine users/creators, it's important to know that Dear ImGui will be easy to integrate in whatever odd-custom tech they may have, and I am on the watch to hold that guarantee around, and to keep communicating it. At the same time, effectively probably 90% of homebrew custom engines not build in a professional context are build over common known technology, Win32 API, SDL/GLFW, DX11 etc. And it makes sense to provide the ready-to-use glue to ensure you can integrate Dear ImGui is most apps with <20 lines of code. It's even more meaningful to have that possibility when you are bootstrapping a new projects or are wholly unfamiliar with programming or graphics technology. The feature scope of Dear ImGui has grown meaningfully over the years, and although the only "required" elements are still mouse pos/buttons, time and rendering those vertices with scissoring, in reality there are many other desirable things which adds up to more work to provide (clipboard, keyboard, gamepads, mouse cursor shape, IME hooks, dpi queries, not mentioning multi-viewports). You can see my reasoning for renaming examples/ to backends/ here: https://github.com/ocornut/imgui/issues/3513 https://github.com/ocornut/imgui/issues/3513 If anything, I found the tendency of my-weekend-engine people to do their first foray into Dear ImGui often improductive and detrimental to the perception of using Dear ImGui. They tend to struggle 4 hours to get a feature-incomplete backends done instead of first plugging fully working existing backends with <20 lines THEN considering if they really need to rewrite that. I believe that did more bad than good to Dear ImGui because they end up using feature incomplete versions. It's also that years fixing those backends to try to have them work everywhere has been helpful in growing the confidence of calling them backends. I believe this is mostly communication issue: we should keep hammering that backends are reasonably easy to rewrite and keep documenting that process. Ref: https://github.com/ocornut/imgui/blob/master/docs/BACKENDS.md https://github.com/ocornut/imgui/blob/master/docs/BACKENDS.m...
- Impossible 6y ago
  This is some high quality HN pendantry. Sure, you're right they're minimal, but also they're literally in a folder called "backends". Also, if you're active here you'll know a lot of people might be interested in using ImGUI, but also not fit in the category of "slightly competent graphics programmer".
  - greggman3 6y ago
    Absolutely not. Like many things you can mis-understand the point. The point of Dear ImGUI is to easily stick it into what you already have. The point is it has no dependencies on any graphics API. You can stick it in Unreal if you want. You just need to be able to draw a list of vertices. That's one of its major features. To gloss over that and think "it only works with stuff in this folder that was renamed from examples to backends" is missing what the library is and isn't. Those are examples of how to make a backend. They aren't Dear ImGUI

greggman3 6y ago

it's a mistake to think Dear ImGUI has "backends". Dear ImGUI is a few files that generate a vertex list. It then as a bunch of "examples" that show how to render that list with various APIs. Any slightly competent graphics programmer could take that vertex list and render it in any API. Those Examples are not Dear ImGUI. They are just examples. This is the code for each command list upload vertex data upload index data set scissor bind texture draw That's it! Adapt that to any API, whatever your using Because it's an example and because so many unexperienced programmers use it they assume it's some official part of the library. It's not.

nitrogen 6y ago
You both seem to be right, based on this commit message: > Moving backends code from examples/ to backends/… 24 days ago
- greggman3 6y ago
  Moving them from examples to backends doesn't change anything. That's likely just a sign that "examples" is now examples of using the API, not examples of integrating with some GPU API. One of the main reasons/goals/points of Dear ImGUI is being able to ingrate it into existing projects. It's deliberately API agnostic. It generates a very simple command list that you can then trivially render yourself in your own engine. Everything else, all the platform specific code in the repo is entirely there to help people understand how to use it or to get started. It's a mistake to think otherwise because it incorrectly limits Dear ImGUI's perceived usefulness. If you believe you have to take a backend or use one of the APIs provided then you'll mistakingly believe it would be hard to put in your existing game. If you understand what it's really about then it's trivial to put it in almost anything. That is by design.
  - midnightclubbed 6y ago
    I had different feelings about the examples. Seeing example integrations into so many rendering apis reassured me that it would be trivial to add Dear Imgui in to my own projects. Without the examples you have to take it on faith that they designed their api to be easily integrated. Many libraries claim to be cross platform and turn out to be hugely painful to use on anything outside of a few intended targets. I still have nightmares about Scaleform!
  - ocornut 6y ago
    Hi gregg :) I think it's a bit of both. From the point of view of game programmers and custom engine users/creators, it's important to know that Dear ImGui will be easy to integrate in whatever odd-custom tech they may have, and I am on the watch to hold that guarantee around, and to keep communicating it. At the same time, effectively probably 90% of homebrew custom engines not build in a professional context are build over common known technology, Win32 API, SDL/GLFW, DX11 etc. And it makes sense to provide the ready-to-use glue to ensure you can integrate Dear ImGui is most apps with <20 lines of code. It's even more meaningful to have that possibility when you are bootstrapping a new projects or are wholly unfamiliar with programming or graphics technology. The feature scope of Dear ImGui has grown meaningfully over the years, and although the only "required" elements are still mouse pos/buttons, time and rendering those vertices with scissoring, in reality there are many other desirable things which adds up to more work to provide (clipboard, keyboard, gamepads, mouse cursor shape, IME hooks, dpi queries, not mentioning multi-viewports). You can see my reasoning for renaming examples/ to backends/ here: https://github.com/ocornut/imgui/issues/3513 https://github.com/ocornut/imgui/issues/3513 If anything, I found the tendency of my-weekend-engine people to do their first foray into Dear ImGui often improductive and detrimental to the perception of using Dear ImGui. They tend to struggle 4 hours to get a feature-incomplete backends done instead of first plugging fully working existing backends with <20 lines THEN considering if they really need to rewrite that. I believe that did more bad than good to Dear ImGui because they end up using feature incomplete versions. It's also that years fixing those backends to try to have them work everywhere has been helpful in growing the confidence of calling them backends. I believe this is mostly communication issue: we should keep hammering that backends are reasonably easy to rewrite and keep documenting that process. Ref: https://github.com/ocornut/imgui/blob/master/docs/BACKENDS.md https://github.com/ocornut/imgui/blob/master/docs/BACKENDS.m...
Impossible 6y ago
This is some high quality HN pendantry. Sure, you're right they're minimal, but also they're literally in a folder called "backends". Also, if you're active here you'll know a lot of people might be interested in using ImGUI, but also not fit in the category of "slightly competent graphics programmer".
- greggman3 6y ago
  Absolutely not. Like many things you can mis-understand the point. The point of Dear ImGUI is to easily stick it into what you already have. The point is it has no dependencies on any graphics API. You can stick it in Unreal if you want. You just need to be able to draw a list of vertices. That's one of its major features. To gloss over that and think "it only works with stuff in this folder that was renamed from examples to backends" is missing what the library is and isn't. Those are examples of how to make a backend. They aren't Dear ImGUI