Chamoix Engine

Vulkan C++ GLFW GLSL

— DATE

May, 2025


— TOOLS

Vulkan, C++,

GLfw, GLSL


My first vulkan game engine. With it, I learned the fundamentals of physics, input management, imgui, and deferred rendering as well as many valuable lessons on general coding principles and conventional wisdom.


I implemented a Descent clone to test my quaternion understanding, a bowling game for real-time physics, and a unique Surface-Stable Dithering effect – but have since moved on to other projects.

EDITOR FEATURES

  • Create actors and components, move, scale, and rotate them around using ImGuizmo.

Inputs are modifiable via the input manager which supports axis and button controls.


Levels and editor states are saved and loaded as xml files.

RENDERING

To experiment with post processing effects, I went with deferred rendering. Using the

G-Buffer I could create outline shaders, and SSAO effects.


I also wrote my first shadow map and parallax shader in this engine.

Lessons Learned

First attempts are always painful

DEPENDENCIES

Keeping dependencies remote makes the program vulnerable to random updates. Code which worked on Windows and Linux months ago now struggles to boot on either. I now understand the urge to “vendor” everything, or at least gate-keep dependencies behind version requirements.

"CLEAN CODE…

Bad performance."

Inheritance, protected variables, single-responsibility, RAII, all feel neat to implement but haven't necessarily lead me to better code, or more extendable code. The Actor-Component paradigm might make sense in the context of an easy-to-use engine like Unity or Unreal, but it makes little sense elsewhere. The often-recommended many layers of abstraction usually lead you to leak complexity.

(e.g. "I'll make an actor for that" feels like a straightforward solution but is in fact a new class, five layers deep in the inheritance hierarchy, with 30 variables it will never use. But "hey, at least its update function gets called automatically…")


I now take better care to profile my projects, and let that – not SOLID principles – guide my architectural decisions.


Above all, I found that SOLID principles as a bible can lead you to solve problems you haven't faced yet. You feel like you are being diligent, but in fact you are trapping your future self in a solution that might not be adapted to the problems he actually faces. I now prefer solving only the problems I see, at the risk of deleting less code if it finds itself no longer applicable to a larger task.