An ImGui adapter for the bgfx renderer backend.
- Header-only.
- Only in C++. It cannot compile in C.
- Supports multiple viewport.
- Supports dynamic textures. In fact, it doesn't even implement the old way. Come on, they've been using dynamic textures for nearly a year now. Are we just don't care to update?
- Provides a larger set of configs for better control.
- Probably the newest among the ones on GitHub and will follow the latest bgfx / ImGui versions.
Bringing your own shader and texture sampler to the backend is the expected default. But if you don't want to be bothered, initialize the backend with .autoShaderSampler = true. We will use the shader in the shader directory and create a sampler.
This is only for multiple viewport support. If you don't need it, initialize the backend with .enableMultiViewport = false, and skip this section.
A set of callback functions that we specifically ask you to provide that cross the bridge from bgfx to the platform (backend).
The backend would probably don't work or crash on creating a new viewport if you don't provide them.
Currently there are two of them:
-
void* getNativeWindowHandle(const ImGuiViewport& viewport): This callback must return the OS native window handle that bgfx needs for rendering. Refer to your platform backend's documentation to see how they put the information needed toImGuiViewportso you can implement this function correctly.ImGui commonly exposes backend window information through
viewport.PlatformHandleandviewport.PlatformHandleRaw.ImGui documents
PlatformHandleas a higher-level platform window handle andPlatformHandleRawas a lower-level platform-native window handle, and is explicitly expected to be anHWNDon Windows and unused for other platforms.Because of that, the default implementation that simply returns
viewport.PlatformHandleRawis only a placeholder and will only work on Windows. It is required that you provide your own implementation for abstraction layers such as SDL/GLFW/custom engines, or for other native platforms.For other native platforms, you can check
PlatformHandle's documentation to see how to convert it into bgfx's expected native window handle, probably with some OS API calls.For SDL3, reach out to CherryGrove for a working implementation.
-
ImVec2 getFrameBufferScale(const ImGuiViewport& viewport): Return the number of framebuffer pixels per ImGui logical unit for this viewport. This is used to convert logical ImGui coordinates and sizes into actual framebuffer pixel sizes for rendering and clipping.This is different from content/DPI scaling: framebuffer scale answers “how many framebuffer pixels do I render for one ImGui unit?”, while DPI/content scale answers “how large should UI content appear to the user on this display?”
The default one simply returns
viewport.FramebufferScaleand defaults to{1, 1}if not presented.This implementation is usually sufficient, if the platform backend is competent enough and it keeps
viewport.FramebufferScaleupdated correctly, like SDL3.
Include the header:
#include "imgui_impl_bgfx.hpp"And you are good to go. You shouldn't include other headers.
Check out the file itself for available functions. TL;DR: We mostly follow the conventional renderer backend contract, except you don't need to call ImGui_Implbgfx_NewFrame on new frames.
This backend uses CherryGrove's inclusion paths for bgfx and ImGui headers by default. If you have different paths in your project, check out inclusions.hpp and define the macros.
The backend exposes some internal data structures and functionalities for developers that might need more power.
Use with caution. Modifying anything here is probably dangerous.
Include this header for access to them:
#include "imgui_impl_bgfx_extras.hpp"Check out the comments and definitions in the files for documentation.
Licensed under the MIT License.