Build Options¶

Doriax uses CMake for desktop editor/runtime builds and platform tooling for mobile, Apple, and web exports.

Common requirements¶

Editor build¶

cmake -S . -B build -DCMAKE_BUILD_TYPE=Release
cmake --build build --config Release --target doriax-editor
cmake --install build --config Release --strip

DORIAX_CXX_STANDARD applies here too, building the editor and engine with it. It is independent of the standard a project selects: the editor compiles script plugins with the project's value regardless of how the editor itself was built.

Leave DORIAX_PHYSICS_2D and DORIAX_PHYSICS_3D on for the editor: it authors every component, and Play links against its engine library, so the editor needs both backends. They are meant for runtime builds.

On Windows the build also provides doriax-editor-cmd, the same editor linked as a console application for automation and terminal output. It is excluded from the default build, so request it by name:

cmake --build build --config Release --target doriax-editor-cmd

See Command-Line Tools.

Runtime build¶

cmake -S engine -B build -DCMAKE_BUILD_TYPE=Debug
cmake --build build --config Debug

Scripting entry options¶

Engine/library options¶

Runtime project options¶

The editor writes these options into exported CMake projects from Project Settings (VSync, the Window settings, the C++ standard, the physics backends, iOS Google AdMob and App Store Purchases, and the web Game Portal). For a manually configured standalone runtime, override them at configure time:

cmake -S engine -B build-runtime \
  -DPROJECT_ROOT=/path/to/project \
  -DDORIAX_VSYNC_ENABLED=OFF \
  -DDORIAX_WINDOW_MODE=2 \
  -DDORIAX_WINDOW_TITLE="My Game" \
  -DDORIAX_CXX_STANDARD=23

Vulkan treats OFF as a request for Immediate presentation, with Mailbox and then FIFO as fallbacks according to surface support.

Graphics backend¶

Set GRAPHIC_BACKEND when configuring a standalone runtime project. The editor's Desktop export selector passes the corresponding value automatically; Web exports use gles3.

On macOS, vulkan builds through MoltenVK but cannot run yet — see Vulkan backend.

The root editor build reads the same variable, but accepts only vulkan or glcore (Linux and Windows, defaulting to glcore); macOS is forced to metal. There it is a cached variable, so the build directory keeps the backend it was configured with until -DGRAPHIC_BACKEND= is passed again.

App backend¶

The target system selects the app backend, which handles the window, input, and main loop. Configure prints it as APP_BACKEND, but the value is informational: setting it has no effect.

Generated artifacts¶

Engine capacity macros¶

Exported CMake projects and their Xcode workspace receive compiler defines for the largest capacities the editor measured in the project's scenes and bundles, each floored at the engine default in engine/core/Engine.h. Growing past the default lets large authored content compile; the floor keeps dynamically spawned content inside the known-safe baseline.

MAX_EXTERNAL_BUFFERS is counted from the glTF files the models and foliage layers use (an FBX through its imported .glb), including the buffers the loader generates, so it is right even in a command line export that never loads them.

MAX_BONES is the CPU array size used at runtime. Skinned shaders bind those matrices through a storage buffer or a bone texture and do not embed this count. The editor can load skins larger than 96; export writes the raised value so the standalone build matches. If you load a larger skin only from code, edit the generated add_definitions("-DMAX_BONES=N") line in the exported CMakeLists, or MAX_BONES in the project-level Preprocessor Macros of the exported Xcode workspace (or pass the same compiler define in a standalone engine build). The engine and the game must be built with the same value.

Platform guides¶

See Building Overview, then use the guide for your target platform.