Deadcell Framework: A Pinned Imgui 1.89.5 Snapshot for a DX11 Menu
By Indie Kings | October 26, 2026
Updated October 26, 2026: The deadcell framework is a new MIT licensed repository that vendors a pinned snapshot of Dear ImGui 1.89.5 on purpose, wiring the immediate mode UI library into a Win32 plus DirectX 11 foundation for the menu it was built to draw.
Image: Amiga 500 system via Wikimedia Commons.
A vendored snapshot, not a submodule
The current/deadcell-framework repository, 193 stars and 15 forks, describes itself as an imgui foundation for the deadcell menu, and its first, longest section is about version hygiene rather than features. The tree vendors a pinned snapshot of Dear ImGui at 1.89.5 work in progress, everything the menu draws, from window frames down to sliders and tabs, goes through this code and out the back into DirectX 11. The three stated reasons for vendoring instead of pulling as a submodule all come from experience: builds cannot break because something moved upstream, the snapshot the menu compiles against is the one sitting in the repo, always; custom widgets lean on imgui_internal.h, an internal header that shifts a lot, and pinning keeps it from being yanked out from under development mid stream; and upstream fixes get cherry-picked when the team wants them, not when they show up bundled with six months of unrelated churn.
Immediate mode in one paragraph
The README is also a compact tutorial on immediate mode, worth reading regardless of engine. There is no widget tree and no per widget state hanging around between frames: you call NewFrame, issue widget calls, call Render, and out comes a vertex and index buffer that a backend shoves into the GPU, every frame, which is the whole trick and the reason dynamic UIs, think quick loading configs or iterating a vector of features, read as one liners instead of bookkeeping. Widget identity comes from labels plus whatever is on the ID stack, so two InputInt calls in a loop do not collide as long as each iteration pushes an ID. Mostly you never think about it, the README notes, and the times you do are the times imgui_internal.h earns its keep.
Backends and building
The exercised path is specific: Win32 as the platform backend, feeding input and owning the window through a single WndProcHandler call, and DirectX 11 as the renderer that turns draw data into GPU calls, linked against d3d11, dxgi and dwmapi on Windows. Both primaries compile straight into an imgui static library target; the rest of the backend folder, DX9, DX10, DX12, OpenGL, Vulkan, SDL, GLFW, Metal and friends, is vendored as-is for reference, fine to compile against but not battle-tested on this snapshot. The build is deliberately boring: CMake 3.16 or newer and a C++17 compiler, two commands, no dependencies. Upgrading means diffing core sources against the upstream tag and re-verifying the Win32 and DX11 path first, because everything else is untested anyway. The license is MIT, credited to Omar Cornut, and the README states plainly this is an unmodified snapshot of upstream, with the menu itself living in downstream code.
Repo card
| Item | Detail |
|---|---|
| Project | deadcell framework, current/deadcell-framework on GitHub |
| Purpose | Imgui foundation for the deadcell menu, rendering out through DirectX 11 |
| License | MIT, an unmodified snapshot of upstream Dear ImGui by Omar Cornut |
| Repo stats | 193 stars, 15 forks |
| Snapshot | Pinned Dear ImGui 1.89.5 work in progress, vendored |
| Vendoring rationale | Reproducible builds, imgui_internal.h churn, cherry-picking on own schedule |
| Tested backends | Win32 platform plus DirectX 11 renderer |
| Untested backends | DX9, DX10, DX12, OpenGL, Vulkan, SDL, GLFW, Metal vendored for reference |
| Build | CMake 3.16+, C++17, static library target |
| Upgrade policy | Diff core against upstream tag, verify Win32 and DX11 path first |
FAQ
What is the deadcell framework?
A GitHub repository that vendors a pinned snapshot of the Dear ImGui UI library and wires it to Win32 and DirectX 11, serving as the rendering foundation for a project called the deadcell menu.
Why vendor ImGui instead of using a submodule?
So builds cannot break when upstream moves, the snapshot admits bigger internal header benefits stay stable, and upstream fixes are cherry-picked on the project's own schedule.
What does immediate mode mean here?
There is no widget tree; each frame you issue widget calls and the library produces a vertex and index buffer a renderer submits to the GPU, making dynamic interfaces trivial to generate.
Which backend combination is actually tested?
Win32 for input and windowing plus DirectX 11 for rendering; the other backends ship in the folder but are documented as reference only.
What does it take to build?
CMake 3.16 or newer and any C++17 compiler, configuring and building a static imgui library in two commands.
Who gets the license credit?
Omar Cornut, under the MIT license; the repository states it is an unmodified snapshot of upstream with the menu code living elsewhere.
Bottom Line
Vendored dependencies are heresy every engineer is taught to avoid, and this repo argues the opposite for a UI library that edits its own internals every month: if a widget lives or dies by imgui_internal.h, only a snapshot you own can keep a build reproducible. Pinning the future, as one maintainer put it, beats chasing it, and this fork does that for code between versions with a discipline most production apps never reach.
Sources
- GitHub current/deadcell-framework README (snapshot rationale, file layout, backends, licensing), accessed 26 October 2026
- GitHub API repository metadata for current/deadcell-framework, accessed 26 October 2026
Related: EllesmereUI: Modular UI Comes to WoW Forever | AnimeJaNai 3.7.0: Automatic Refresh Rate Matching Comes to Real-Time Anime Upscaling