How dsbch/engine works
1. Repository shape
- This is a C++ engine repo split into three runnable layers: engine (shared runtime), sandbox (testbed/demo app), and editor (tooling app).
- Build orchestration is done with Premake (premake5.lua plus per-project Lua scripts), and the solution file is dsengine.slnx.
2. Top-level runtime model
- The engine is organized around an application loop that owns global state, a window, and a renderer.
- Higher-level app code lives in sandbox and editor, while reusable engine code lives under engine/src.
3. Core engine foundation
- engine/src/base contains cross-cutting utilities: logging, errors, config, timers, hashing, context, cache, and a ring buffer for concurrency.
- These pieces support initialization, diagnostics, and shared runtime services without being tied to rendering or gameplay.
4. Scene and ECS-like structure
- engine/src/core/scene defines entities, components, scenes, and systems.
- Systems are split by responsibility: animation, camera, and render, which suggests a data-oriented scene update pipeline.
5. Event and camera flow
- engine/src/core/events provides event types and dispatching.
- Camera control is separated into its own component/system pair, so input-driven view updates are isolated from rendering and scene ownership.
6. Asset and content processing
- engine/src/core/amanager contains asset/material/meshlet/primitive processors, indicating an offline or runtime asset preparation layer.
- The presence of meshletProcessor and primitiveProcessor suggests geometry is transformed into renderer-friendly structures before drawing.
7. Rendering abstraction boundary
- engine/src/platform/renderer is the renderer interface layer, with shared types like shader, texture, and vertex.
- This layer isolates the engine from a specific graphics API while exposing the API-neutral rendering contract.
8. Vulkan backend
- engine/src/platform/renderer/vulkan is the concrete backend and contains the full GPU implementation: buffers, images, descriptors, pipelines, swapchain, submission, shader loading, registry, and deletion queue.
- Specialized renderers exist for meshlets, lines, compute, and UI, showing that the backend is split by rendering mode rather than being a single monolith.
9. Modern rendering features
- The shader set in assets/shaders includes mesh, compute culling, hierarchical Z-buffer, line, composite, and accumulation shaders.
- This points to a GPU-driven pipeline with compute-assisted visibility/acceleration stages and meshlet-based rendering.
10. Asset and shader pipeline
- Shader sources are in HLSL and precompiled SPIR-V binaries are stored under assets/shaders/vkCompiled.
- The repo treats compiled shaders as part of the runtime asset set, which means shader compilation is an explicit step in the content pipeline.
11. Application layers
- sandbox is the interactive demo/runtime app; its README hints at keyboard-driven model loading and instance manipulation.
- editor is a separate tooling app, likely intended for scene/content authoring on top of the same engine runtime.
12. Platform and windowing
- engine/src/platform/window handles window creation and OS-facing lifecycle.
- The renderer and window boundaries are separate, so rendering can be swapped or reworked without changing the rest of the engine.
13. External dependencies and tooling
- Vulkan is the primary graphics API, and the README explicitly requires the LunarG Vulkan SDK.
- vendor and the submodule file indicate third-party dependencies are integrated locally rather than fetched dynamically at runtime.
14. Likely end-to-end data flow
- Application starts → engine initializes config/logger/context/window → scene is loaded → systems update camera/animation → render system hands visible data to the Vulkan backend → backend records/submits GPU work → swapchain presents the frame.
- Asset processing and shader compilation sit on the path before rendering, while the sandbox/editor are the main entry points for exercising that pipeline.
Main entry points: application.cpp App loop · scene.cpp Scene model · premake5.lua Premake · renderSystem.cpp Render system
Components 19
Build
Solution and project orchestration
- Solution · Top-level Visual Studio solution
dsengine.slnx - Premake · Root build orchestration
premake5.lua - Engine Lua · Engine project definition
engine/engine.lua - Editor Lua · Editor project definition
editor/editor.lua
Apps
Runnable entry points
Engine
Reusable runtime and systems
- App loop · Owns lifecycle and global execution state
engine/src/application/application.cpp - Base runtime · Logging, config, context, timing, errors, hashing, cache, concurrency
engine/src/base/logger/logger.cpp - Scene model · Entities, components, scenes, and system contracts
engine/src/core/scene/scene.cpp - Events · Event types and dispatcher for runtime coordination
engine/src/core/events/dispatcher.cpp - Camera · Camera state and control logic
engine/src/core/camera/camera.cpp - Assets · Asset, material, meshlet, and primitive processing
engine/src/core/amanager/aManager.cpp - Animation · Scene animation update system
engine/src/core/scene/systems/animation/animation.cpp - Camera system · Scene system that updates camera behavior
engine/src/core/scene/systems/camera/cameraSystem.cpp - Render system · Scene-to-renderer bridge
engine/src/core/scene/systems/render/renderSystem.cpp - Window · OS window creation and lifecycle
engine/src/platform/window/window.cpp
Rendering
API-neutral interface and Vulkan backend
- Renderer API · API-neutral renderer contract and shared types
engine/src/platform/renderer/renderer.cpp - Vulkan backend · Concrete Vulkan renderer implementation
engine/src/platform/renderer/vulkan/renderer.cpp
Content
Assets and shader pipeline
- Shaders · HLSL sources and compiled SPIR-V shader set
assets/shaders/vkMesh.hlsl
Connections 19
- Solution → Premake: builds via · Solution is generated and coordinated through Premake
- Premake → Engine Lua: includes · Root build pulls in engine project definition
- Premake → Editor Lua: includes · Root build pulls in editor project definition
- App loop → Base runtime: uses · Application loop depends on shared runtime services
- App loop → Window: owns · Application lifecycle manages the OS window
- App loop → Renderer API: drives · Application initializes and coordinates rendering
- Scene model → Events: publishes · Scene logic is coordinated through events
- Scene model → Animation: runs · Animation is a scene system
- Scene model → Camera system: runs · Camera updates are part of scene processing
- Scene model → Render system: runs · Rendering is orchestrated from the scene layer
- Camera system → Camera: updates · Camera system manipulates camera state
- Render system → Assets: consumes · Render path uses prepared assets and geometry data
- Render system → Renderer API: targets · Scene rendering emits API-neutral draw work
- Renderer API → Vulkan backend: implemented by · Vulkan backend satisfies the rendering contract
- Vulkan backend → Window: presents via · Swapchain and frame presentation are tied to the window
- Vulkan backend → Shaders: loads · Backend consumes compiled shader assets
- Sandbox → App loop: uses · Sandbox is an entry point into the engine runtime
- Editor → App loop: uses · Editor is another entry point into the engine runtime
- Assets → Shaders: aligns with · Asset pipeline feeds rendering-oriented content