Crate concinnity_engine 

The runtime crate. Holds the world loop, the ECS, the GraphicsSystem renderer driver, audio, and physics. The GPU-free render-prep lives in concinnity_core::render and the hardware backends (Metal/DirectX/Vulkan/ Win32) in concinnity-device; this crate drives them through a Box<dyn RenderBackend> from concinnity_device::init_backend and never names a concrete backend. Depends on concinnity-core and concinnity-device (no concinnity-cook, no image decoders). The editor crate (concinnity-dev) drives this crate’s App / renderer through the public API widened here; the modules the editor reaches into are pub so it can name their paths, but individual internals stay pub(crate) unless the editor specifically needs them.

Re-exports

pub use app::run::BlobSource;

pub use app::run::run_from;

pub use app::run::PipelineMode;

pub use app::run::RunOptions;

pub use app::run::init_logging;

pub use app::startup_error::StartupError;

pub use app::state::App;

pub use components::*;

Modules

app

Client application runtime: the world loop and the runtime systems that drive a compiled world. The build / edit / debug / preview paths live in the editor crate. pub so the editor crate (which drives a live App via the runtime API) can reach these runtime app items through concinnity_engine::app::*.

blob

Blob file reading and lazy payload residency live in concinnity_host::store; re-export them under the historical crate::blob::* paths. pub so the editor crate’s in-memory build path can construct BlobData.

components

Client-side component surface: a thin re-export of concinnity-core’s component types under the historical crate::components::* paths. All components are pure data now: every system became an internal client system living in its own domain module (gfx::graphics_system, gfx::camera_controller, gfx::animation, ui, hud, physics) or audio module (crate::audio), constructed by World::start from the components a world declares.

crash

Crash reporting: panic hook, native fault capture, local report files. pub so the binaries install the hooks and the editor composes the recent-log ring layer into its tracing subscriber.

ecs

Client-side ecs runtime. The renderer-free metadata, asset registry, registration macros, asset-construction API, PipelineContext, the System behavior trait, and the World that runs systems over its data all live in concinnity-core; this module re-exports them under the historical crate::ecs::* paths and adds what only a renderer-bearing runtime has: the system table itself, its gates, the load-time decomposition pass, and the resources the render band parks in a world.

gfx

The client’s render layer. Everything below the client sits in concinnity-core and is re-exported here under the historical crate::gfx::<module> paths: the GPU data layouts and render math (camera, frustum, post-process settings) plus the CPU kernels over them from concinnity_core::gfx, and the backend-agnostic render-prep (record builders, render graph, trait seam, and the GPU-free cursor / sprite / text / lights / streaming layout helpers) from concinnity_core::render.

jobs

Backend-agnostic job pool for parallelising expensive per-frame CPU work.

paths

Project state root: where the engine’s state tree is anchored, and the names of the directories hanging off it.

platform

The shader platform this build’s rendering backend consumes. The backend is this crate’s own compile-time choice, so the crate that knows it is the one that states it: the editor and the cook are handed the value rather than resolving a backend of their own. Which shader source language this build’s rendering backend consumes.

resource

Runtime resource tables (per-kind, handle-indexed views of the blob’s resource stream). pub so the editor’s in-memory build path can construct the tables it inserts into the world, mirroring the shipped-runtime loader.

shutdown

Cooperative shutdown signal shared across threads. Clones observe the same flag: any clone’s cancel() is visible to every other clone’s is_cancelled(). Cancellation is one-way and sticky.

Macros

define_systems

The system table. Generates the SYSTEMS table a world starts from; table order is run order.

Structs

ShaderPrecompileReport

Outcome of a built-in shader precompile: how many artifacts were already in place or copied from the local cache, how many compiled fresh, and the programs that failed (with their compile diagnostics). Failures do not abort the run – the affected shader falls back to compiling at the bundle’s first launch.

Constants

HAS_RENDER_BACKEND

Whether this build links a rendering backend. A build with no backend feature has none, so the only loop that can run a world is a headless one. Whether a rendering backend compiles into this build. False leaves the headless loop as the only one that can run a world.

Functions

precompile_builtin_shaders

Compile every enumerable built-in shader variant into the runtime cache segment under state_dir, which is a bundle’s state root.

set_writable_state_dir

Anchor the runtime-writable state (saves/ + settings) at dir, leaving the read-only content (data/) at the installed state dir. A shipped application installs this when its content dir is not writable (a read-only install such as Program Files), redirecting only what it writes at runtime to a per-user directory. When unset, writable state stays beside data/.