imgui foundation for the deadcell menu. 5-wip) — everything the menu draws, from the window frames down to the sliders and tabs, goes through this code and out the back into dx11.
deadcell-framework (current/deadcell-framework)
Searching Database…
The project's README from github.com/current/deadcell-framework. As one markdown file: README.md.
imgui foundation for the deadcell menu. this is a pinned snapshot of
dear imgui (1.89.5-wip) — everything the
menu draws, from the window frames down to the sliders and tabs, goes through
this code and out the back into dx11.
the tree is vendored on purpose, not pulled as a submodule:
imgui_internal.h, and that header shifts a lot.
pinning it means it can't get pulled out from under us mid-development.imgui.cpp core — context, windows, id stack, input, layout
imgui.h public api
imgui_internal.h internal api, the one custom widgets actually need
imgui_draw.cpp vertex buffers, font atlas, antialiased primitives
imgui_widgets.cpp sliders, combos, trees, tabs, all the stock widgets
imgui_tables.cpp table api
imgui_demo.cpp live sample of every widget, with source. read it.
imconfig.h compile-time toggles
backends/ platform + renderer backends (see below)
misc/ fonts, freetype, std::string helpers, .natvis files
docs/ upstream docs — faq and BACKENDS.md are the good ones
CMakeLists.txt builds imgui as a static lib
imgui is immediate mode. there's no widget tree and no per-widget state
hanging around between frames — you call NewFrame(), issue your widget
calls, call Render(), and out comes a vertex/index buffer a backend shoves
into the gpu. every frame. that's the whole trick, and it's why dynamic uis
(quick-loading configs, iterating over a vector of features) are one-liners
instead of bookkeeping.
widget identity comes from labels plus whatever's on the id stack, so two
InputInt calls in a loop don't collide as long as you push an id per item.
mostly you never think about it. sometimes you do, and that's what
imgui_internal.h is for.
| file | does |
|---|---|
imgui.cpp |
windows, id stack, input routing, layout |
imgui_draw.cpp |
draw lists, font atlas rasterization |
imgui_widgets.cpp |
stock widgets, built on the core |
imgui_tables.cpp |
tables — scroll, sort, freeze, resize |
imgui_internal.h |
internals: custom widgets, theming hooks |
two kinds, mix and match:
ImGui_ImplWin32_WndProcHandler goes in your wndproc and input just works.win32 + dx11 is the pair that actually gets exercised. everything else in
backends/ (dx9/10/12, opengl, vulkan, sdl2/sdl3, glfw, metal...) is vendored
as-is for reference — fine to compile against, just not battle-tested on this
snapshot.
both primaries compile straight into the imgui static target, and the
dx11 side links d3d11/dxgi/dwmapi on its own when building on windows.
cmake >= 3.16, c++17 compiler:
cmake -B build -DCMAKE_BUILD_TYPE=Release
cmake --build build --config Release
once you've got a device and a window:
ImGui::CreateContext();
ImGui_ImplWin32_Init(hwnd);
ImGui_ImplDX11_Init(device, device_context);
// frame loop
ImGui_ImplDX11_NewFrame();
ImGui_ImplWin32_NewFrame();
ImGui::NewFrame();
ImGui::Begin("deadcell");
// menu contents
ImGui::End();
ImGui::Render();
ImGui_ImplDX11_RenderDrawData(ImGui::GetDrawData());
that's it. no scene graph, no callbacks to register.
snapshot tracks 1.89.5-wip (pre-1.89.5 master). when moving up a version:
diff the core sources against the upstream tag and re-verify the win32/dx11
path first — everything else is untested anyway.
mit, © omar cornut — see LICENSE. this is an unmodified snapshot of upstream; the menu itself lives in downstream code.
imgui foundation for the deadcell menu. 5-wip) — everything the menu draws, from the window frames down to the sliders and tabs, goes through this code and out the back into dx11.