Cheryl Engine

The earlier Cheryl code brings together C++ facilities for assets, input, and the connection between a game’s update and drawing code. Its ToolBox history and later standalone revisions show how those facilities were organized and developed.

This page covers the earlier engine work, including its ToolBox history and the later standalone repository. Asset creation and lifetime, input mapping, and the organization of the engine itself provide three useful examples of how that work developed.

Creating an asset is more than allocating memory

The old AssetFaculties code separates several jobs that are easy to bundle into one function. A factory provides an interface for creating a particular asset type. Loaders deal with bringing asset data into the program. Managed-asset code connects creation, storage and later access.

Pools provide reusable storage beneath those interfaces. This leaves a practical C++ question: which object owns the storage, and which interface is responsible for the object placed in it? A texture, mesh or game-specific asset may share management machinery while still needing its own construction and loading behavior.

The standalone engine continued this work. Its December 2018 revisions reorganized the asset and object pooling implementations. That is a useful point in the history because it shows resource management continuing after the engine had its own repository, rather than ending with the old ToolBox layout.

Keeping controls separate from game behavior

Input follows a similar separation. Contexts, bindings and a mapper sit between device input and the code interested in an action. The retained implementation includes callback polling and Windows keyboard and mouse handling.

A context gives the application a place to describe the controls that matter to it. That makes the mapping itself part of the framework, while the response to a game action stays with the game. The older source also contains Steam-controller experiments, but the later retained controller code is commented out. It belongs to the history of the input design, not to a list of supported integrations.

From ToolBox to a standalone engine

The ToolBox repository also held logging, file-chunk, filesystem and debugging utilities. Keeping those sources together was convenient, but their histories and dependencies were not all the same. The engine eventually became a separate project, with its own resource-management, asset and game-framework code.

A 2023 revision moved that standalone code into include and source directories and revised its CMake and dependency-submodule layout while removing the older Visual Studio project files. These revisions are part of the engine’s development history; they do not establish that every old branch remains buildable today.

The earlier engine is best understood through these implemented boundaries and the source that survives. The current runtime, SDK and consumer work continues on the separate modern-development page.