Diagram explorer
Diagram explorer
Choose a subsystem, then compare its engine dependencies, application use and focused views. Arrows point from the consumer toward what it uses. Select a type or arrow for its source evidence and connections; public types also link to the C++ API reference.
Application views list the most relevant methods beneath their owning types. These are selected entry points, not complete method inventories or a call sequence. Implement hooks marks methods your game overrides for the engine to call. Select a box for each method’s purpose, source and available API link; search also finds method names.
Signatures use method(arguments): ResultType, with qualified Engine types and
public aliases for arguments and results. Diagram signatures omit parameter
names when their types are shown, declaration qualifiers such as const,
pointers/references, and ownership or completion markers. [] marks a collection.
The inspector retains those contract details; the API reference has the full
types. A missing result suffix can mean a scalar or standard-library result
and does not imply void.
When a view names a local namespace, its prefix is omitted in the diagram:
within Input, Actions::Context means Input::Actions::Context. Other
namespaces remain explicit, as do local names that would collide with another
namespace, such as Text::Rendering and Input::Events. Mixed diagnostics
and utility views keep their namespaces; the inspector retains full names.
Application arrows include the argument and result types used by selected methods. In the inspector, Accepts and Returns connect a method to those types in the current view. Select an arrow to see the supporting method relationship. Both use the same consumer-to-dependency direction; these arrows do not describe data flow. The API reference supplies the complete signature, including types omitted from the selected view.
Use Docs navigation to keep the documentation sidebar, or Wide explorer for a subsystem sidebar and more room to inspect a diagram. The selected view is preserved when changing layouts or returning from a guide.
Names retain their namespaces without the leading CE::. Primitive and std::
types are omitted. Rounded cream boxes describe illustrative application roles;
they are not Engine types. These are curated relationships rather than complete
declaration inventories. Detailed guides own the execution, lifetime and failure
contracts.
The interactive explorer needs JavaScript and HTTP, as do the manual’s other Mermaid diagrams. The view index below remains available without JavaScript.
Runtime · engine integration — Which engine contracts does one runtime session coordinate?
Display · engine integration — Who consumes the live window and who consumes copied dimensions?
Input · engine integration — How do native polling, action contexts and tick consumers connect?
Assets · engine integration — How do loading, shared caches and drawable resources depend on each other?
Resources · engine integration — Who creates or retains graphics generations, and what implements their lifetime?
Rendering · engine integration — What does playback consume, and what prepares the immutable frame?
Text · engine integration — Where do CPU font/layout work and graphics publication meet?
GUI · engine integration — How do the two toolkit modules connect input, fonts, uploads and retained passes?
Audio · engine integration — What is the audio implementation, and how do explicit notification pumps reach engine owners?
Events · engine integration — Which engine producers use the bus, and where are optional delivery services connected?
Dispatch · engine integration — Which owners drain queues and which engine services retain producer endpoints?
Workers · engine integration — How does shared physical capacity serve Context groups and internal consumers?
Memory · engine integration — Which storage, construction and release contracts support engine caches?
State · engine integration — Which helpers are used by engine services, and which remain standalone alternatives?
Logging · engine integration — How do subsystem writers reach named logging configuration and lifetime?
Diagnostics · owner-specific observations — Which engine owner produces each copied observation?
Utilities · engine consumers — Where do local discovery, fit, numeric and placement helpers enter engine work?
Runtime · application composition — What does an application create, implement and retain for one session?
Display · application access — What is safe from platform hooks, and what should update read instead?
Input · application actions and controllers — What must initialization bind, and what does each update consume?
Assets · application loading and playback — Which values does a game load once, share and advance independently?
Resources · application uploads and retained draws — What must an upload owner supply, and what do later draws retain?
Rendering · application frame preparation — Which real API types does one ordinary sprite draw touch?
Text · application font and label choices — What is the normal path for a static label or a changing label?
GUI · application-owned sessions and publication — What does application code own when it selects a toolkit?
Audio · application-owned playback and outcomes — What remains application-owned around playback, notification pumping and shutdown?
Events · application registration and delivery — What must producers, listeners and cleanup retain or choose?
Dispatch · application owner requests — Which endpoint should a producer save, and which owner executes its work?
Workers · application CPU preparation — What capacity does the host choose, and what does a preparation producer retain?
Memory · application object storage — What are the ordinary pooled path and the explicit-reservation alternative?
State · application state choices — Which value/observation contract matches an application component?
Logging · application configuration and writers — What should happen before producers start and after they finish?
Diagnostics · application observations — What can a live observer inspect, and what requires runtime completion?
Utilities · application-local helpers — Which local values and functions can a tool or game use without a runtime service?
Runtime · simple adapter assembly — What does Context assemble before any game session starts?
Runtime · practical tick and frame boundary — Which values cross simulation and rendering without exposing mutable game state?
Runtime · practical shutdown and observation — How do ordinary requests, host decisions and retained outcomes fit around runtime?
Input · simple gameplay actions — What is the smallest useful binding-and-read map?
Input · practical UI capture and focus — Which separate contracts request records and decide their keyboard recipient?
Assets · simple loading and lookup — What does ordinary application loading need before drawing a sprite?
Assets · practical shared sprite, separate playback — What can be shared while each application object advances its own cursor?
Rendering · simple prepared frame — What is the small immutable structure playback actually sees?
Rendering · practical one-sprite draw — Which names appear in a normal prepare_render_frame() implementation?
Text · simple static label — What are the explicit stages for a label that rarely changes?
Text · practical changing label — Which boundaries does Updater manage instead of application-owned futures?
GUI · TGUI publication — What is the retained UI path for TGUI alone?
GUI · RmlUi publication — What is the retained UI path for RmlUi alone?
Events · simple immediate notification — What must a synchronous producer/listener pair actually retain?
Events · practical delivery choices — What selects platform, simulation or a serial worker listener stream?
Workers · simple Context-owned groups — How does a preparation producer get shared CPU capacity through Context?
Subsystems · interactions — How do the 17 documented responsibilities relate inside Cheryl Engine?
Subsystems · simple execution boundary — What does runtime coordinate, and where does optional queued work enter?
Subsystems · simple content and presentation — Which responsibilities meet when visual content becomes retained draws?