bitbeet.dev
← back to projects
// 01 · graphics

Prisvector Engine

C++20 game engine with ECS, deferred rendering and editor.


STACK
C++20 · OpenGL 4.5 · GLSL · EnTT · GLFW · GLM · ImGui · ImGuizmo · spdlog · CMake
STATUS
live
LINK
github.com/Perkybeet/prisvector-engine ↗

Prisvector is a full C++20 game engine — not a render demo. It owns the window, the ECS, the renderer, the asset pipeline and an in-engine editor with dockable panels. Every layer is written from scratch on top of modern OpenGL 4.5, EnTT for the entity system and a thin wrapper around GLFW and GLAD.

Render pipeline

Prisvector deferred render pipeline: scene entities through G-Buffer, shadow pass, lighting pass, particles and post-processing into the final framebuffer ECS · RENDER PHASE Scene Entities meshes · materials · lights GEOMETRY PASS · MRT Normal Albedo Metal · Rough Depth SHADOW PASS Cascaded Shadow Maps C0 C1 C2 C3 LIGHTING PASS PBR · Cook-Torrance directional · point · spot PARTICLE PASS GPU Compute Dispatch instanced · sorted · alpha post · HDR tonemap · gamma SWAP CHAIN Framebuffer
deferred pipeline — G-Buffer feeds three parallel passes, then post-processing

The renderer is deferred, not forward: geometry writes into a G-Buffer (albedo, normals, material) and a second pass shades from light sources. This keeps lighting cost proportional to screen pixels rather than scene complexity.

  • G-Buffer pass — MRT framebuffer with normal, albedo, metallic-roughness, depth.
  • Lighting pass — PBR (Cook-Torrance) with directional, point and spot lights.
  • Shadow pass — Cascaded Shadow Maps for directional lights; atlas-based shadows for spot lights.
  • Particle pass — GPU compute dispatch to update millions of particles; instanced draw back into the scene.
  • Post-processing — HDR tonemapping (ACES-like), gamma correction, future bloom slot.

ECS with phased scheduling

Systems don’t run in a flat loop. The scheduler runs them in 9 named phases (PreUpdate, Input, Physics, Update, LateUpdate, PreRender, Render, PostRender, Cleanup) so dependencies stay explicit and the execution order is deterministic. EnTT gives dense storage and fast iteration.

// A typical system registration
scheduler.register_system<MovementSystem>(SystemPhase::Update);
scheduler.register_system<CameraSystem>(SystemPhase::LateUpdate);
scheduler.register_system<ShadowSystem>(SystemPhase::PreRender);
scheduler.register_system<DeferredRenderSystem>(SystemPhase::Render);

Editor

The sandbox app ships a full Unity-style editor:

  • Dockable layout via Dear ImGui docking branch.
  • Scene hierarchy, inspector, viewport, console, asset browser as separate panels.
  • Transform gizmos via ImGuizmo with snapping (grid or rotation steps).
  • Play mode serialises the scene before starting, restores on stop.
  • Editor camera with Alt-drag orbit/pan/zoom (Maya/Blender style).

What’s interesting about it

  • No rendering framework underneath — every VAO bind, every uniform buffer update is code I own.
  • Hot-reload for shaders: edit a GLSL file, the engine recompiles and swaps on the fly without losing scene state.
  • External deps are fetched declaratively via CMake FetchContent, so a clean clone + cmake --build produces a runnable editor.

115+
C++ source files
9
ECS system phases
4.5
OpenGL core profile