SufferEngine

Why this project matters

SufferEngine is the strongest C++ systems project in my portfolio. It is not positioned as a commercial engine or a pure graphics demo. Its value is architectural: it shows that I can reason about engine-level organization, runtime loops, resource ownership, rendering commands, editor tooling, scripting, audio, platform issues and packaging.

The source code remains private, so this page documents the system without exposing implementation details. The goal is to communicate what exists, how it is organized and which engineering problems it demonstrates.

High-level architecture

The engine is organized around a central Manager that owns the main loop and coordinates the main subsystems:

• Window/Input and OpenGL context.
• Scene management.
• Resource management.
• Rendering.
• Audio.
• Lighting.
• Dear ImGui editor interface.
• Systems for transform, hierarchy, script, light, audio and render.

A simplified view:

Application demo
  -> EngineManager
    -> Window / Input / Interface
    -> Scene
       -> GameObject
          -> Transform / Geometry / Material / Script / Light / Audio / Child components
    -> Systems
       -> Transform / Hierarchy / Script / Light / Audio / Render
    -> DisplayList / Commands
       -> RenderManager / AudioManager
    -> ResourceManager
       -> buffers / textures / cubemaps / framebuffers / shaders

Runtime model

The project uses an ECS-style model rather than a data-oriented ECS. Scene objects are composed from components, and systems iterate over those objects to perform work. This demonstrates separation of concerns — object data, behaviour systems, rendering commands and resources — while still being honest about the trade-off: it is flexible and readable, but not designed as a cache-friendly archetype ECS.

Render and resource flow

The renderer is built around a command/list style flow. Systems generate display lists containing commands such as geometry drawing, depth passes, shadow maps, point-light depth passes, skybox rendering and post-processing. The RenderManager executes those commands, while ResourceManager owns or synchronizes the data needed by OpenGL: vertex buffers, index buffers, textures, cubemaps, framebuffers and shader programs.

This is the core professional signal: the project does not simply call drawing code directly from gameplay. It separates data, submission and execution into different responsibilities.

Editor tooling

The editor layer uses Dear ImGui and includes practical runtime tools such as scene hierarchy, inspector-style panels, project browsing, game viewport, lighting/material controls and audio interaction. This turns the engine from a rendering sample into a small editor/runtime environment where scene state can be inspected and changed interactively.

Scripting and audio

Lua scripting is integrated through a script component that exposes engine actions such as transforms, component changes, geometry/draw-mode changes and audio triggers. SoLoud is used for audio playback, including 3D audio concepts. These features show that the runtime is not only a renderer: objects can own behaviour, state and sound.

Linux hardening and packaging

The enhanced version includes Linux/CMake build support, run scripts, sanitizer builds, GDB execution helpers, OpenGL diagnostics and AppImage packaging. A dedicated public packaging flow creates a runtime-only demo while excluding source code, headers, tests, dependencies, scripts and private build artifacts.

This is important professionally because it shows platform and distribution thinking, not just feature implementation.

Technical trade-offs

• Global engine access vs explicit dependencies: a central singleton-style engine object simplifies demos but increases coupling and reduces testability.
• Flexible component map vs data-oriented ECS: easy to extend and inspect, but not ideal for cache-local performance.
• Command-based render flow vs direct calls: cleaner separation, but more ownership and lifetime complexity.
• Runtime editor convenience vs strict runtime correctness: editor tooling is useful, but it increases synchronization and state-management complexity.
• Relative asset paths vs robust runtime asset root: quick to use during development, but fragile for packaging and distribution.

What I would improve next

• Centralize runtime asset path resolution.
• Separate demos/samples from real automated tests.
• Add tests for resource handles, display-list ownership and component retrieval.
• Reduce global engine access through explicit context passing.
• Harden Lua scripting boundaries.
• Add architecture diagrams and a public technical write-up.
• Keep public packaging source-safe and repeatable.

Professional takeaway

SufferEngine is the portfolio proof that I can go below engine-level APIs and reason about the structure of a runtime system: update order, object/component organization, resources, render commands, editor tools, scripting, audio, platform debugging and packaging. It is the best project for roles that care about C++, tools, engine-adjacent systems and maintainable low-level software.