The core
The engine ships base types and nothing else: Deki::Object and
Deki::Component, the lifecycle manager, the asset system and the provider
interfaces a platform implements. Rendering, sprites, input, audio, networking
and every peripheral live in packages.
One tag, everywhere
Derive from Deki::Component, tag a field DEKI_EXPORT. That tag drives the
inspector widget, serialization, undo and asset resolution. There is no second
place to register anything.
Hot reload
Edit a component, focus the editor, and it rebuilds and swaps the DLLs in place. No restart, no scene reload.
Software renderer
One QuadBlit pipeline, four output formats. Dirty rectangles keep partial
panel updates cheap on battery.
Packages as DLLs
Every package is a standalone shared library, never baked into the core. Ship with no rendering, no input, no audio. Just the lifecycle.
Platforms
A platform is a package. Swap the integration to retarget, and leave display and input out entirely for headless services.
| Platform | Status | What it is |
|---|---|---|
| ESP32 | Shipping | The primary target. Built against ESP-IDF, so any variant the SDK supports is in scope: SD, display and touch included, with the editor’s build pipeline running through to hardware. |
| Windows desktop | Shipping | Window, input and filesystem through SDL3. This is what the editor itself runs on. |
| Linux desktop | Experimental | Engine and editor build and run on GCC 16, verified end to end on a Steam Deck, with native file dialogs. |
Bring a hardware FPU. Transforms, tweens and rendering all lean on native
float; soft-float works, just much slower.
Where it is
0.x, and the number is honest: the API still moves between releases, the editor is not packaged for download yet, and boards are still being added. The engine and the packages are usable today, under Apache 2.0, at github.com/orgs/dekiengine.
The C++ API, the component reference and every package’s own documentation are in the docs.