Dimcrow

Origins

The arc started in April 2023 as Slingshot - a smaller engine project that explored a lot of the same questions. Slingshot was built on a classic ECS, and its limits became the catalyst: enough of the system fought against ECS that it was clearer to start over with a different model than to keep patching the old one. Dimcrow is that reset, and its scheduler - IEGS - is the answer to what should sit in ECS's place.

Not everything from Slingshot was discarded. The most direct inheritance lives inside the engine to this day: crow::input, the input subsystem, is descended from Slingshot's. It was already shaped right, so it came along.

Engine

Written in modern C++ from scratch. Built around a small set of strong conventions rather than a vast API surface.

• Multi-backend GPU. Direct3D 12, Vulkan, Metal, WebGPU - all first-class, all running the same content.
• Cross-platform. Windows, Linux, macOS, Android, iOS, WebAssembly. The same projects build everywhere.
• Slang-based shaders. One shader source, cross-compiled to DXIL / SPIR-V / WGSL / MSL with cached permutations.
• IEGS. An identity-graph scheduler. Game logic is nodes wired through typed value pins; phases keep ordering predictable.
• Custom mesh format. CRM - purpose-built for fast load, skeletal animation, morph targets, multi-geometry identities.
• Lighting. PBR with shadow mapping, IBL from HDRIs, and SH-based ambient blended across multiple sky contributors.
• Terrain. Chunked LOD with deformation, splatmaps, edge skirting; built to scale beyond the small samples it ships with.
• Networking. A separate module that handles DTLS for gameplay traffic and WebTransport for browser clients.
• XR. OpenVR backend for hand tracking and controller models, slotted in as another module.
• Audio. Multiple backends behind a single interface, chosen by the host platform.

Editor

A Qt 6 frontend with a multi-process host architecture - what you author and what you play run in separate executables, talking over IPC.

• Scene host, game host, utility host. Each is its own process. The frontend orchestrates; the hosts render.
• Live DLL hot-reload. Game code recompiles and reloads without leaving the editor. Identity state survives the swap.
• Scenes as zones. A realm holds zones additively; scene transitions stream identities in and out at runtime.
• Inspector tied to runtime. While Play is active, the inspector reads and writes the live game host - see and tweak the actual values, not the file on disk.
• Apex - the mutant gizmo. Multi-mode, multi-select, sprinkler-driven, parent-aware. Drag a parent and the children follow; drag a child and its local transform is recomputed through the parent inverse. Sprinkle copies along an axis to lay down a fence - ask nicely and it'll build your house.
• Build pipeline. One click compiles game DLL, deploys runtime, packages assets, and produces a standalone executable.

Status

The current focus is the first complete game built on top of the system - <game project x ;)>, used as the dogfooding loop that drives every engine and editor change. Each missing feature surfaces as a real problem in the game and gets fixed against that pressure.

Why

Most engines exist to ship a product, please an audience, or hit a deadline. This one exists because the problem is interesting. Every choice - multi- process editor hosts, slang-driven shaders, custom mesh format, four GPU backends - was made because it was the right shape, not because anyone asked for it.

It is not a startup. It is not for sale. There is no roadmap to a 1.0. What there is, is a long-running attempt to answer one question: what does a serious game engine and editor look like when nobody is paying you to take shortcuts?