Flex Engine: a Vulkan renderer written as a study of real-time graphics

A research engine whose author says it is not for production

The most important sentence in the Flex Engine README is the one that disqualifies it for most teams: Flex Engine is a personal game engine the author began work on in early 2017, used as a playground for learning about real-time rendering and simulation techniques, and it is neither a commercial game engine nor intended for public use.

That framing is consistent with everything else in the repository. The topics listed for the project include personal-game-engine and rendering-engine alongside cpp, glsl, vulkan and game-engine. The homepage is a personal domain rather than a product site, and the way to follow the work is the author's blog at ajweeks.com/blog.

None of that means the code is careless. The feature list is dense with techniques that are usually written about in papers and rarely in hobby projects: stable cascaded shadow mapping, temporal anti-aliasing, screen-space ambient occlusion, image-based lighting, a physically-based shading model, GPU-based particle simulation, and signed distance field font generation. But the audience is a reader, not a user. The right question to ask about Flex Engine is whether the code teaches you something, not whether it will carry a production title.

The Vulkan backend renders into an eight-target GBuffer

Flex Engine's rendering core is a Vulkan backend, and the README points at the file that implements it, FlexEngine/src/Graphics/Vulkan/VulkanRenderer.cpp. Vulkan access goes through volk, listed as a Vulkan meta-loader, which loads the graphics API functions at runtime rather than linking them at build time.

The screenshots document the deferred pipeline directly. One capture shows a GBuffer whose targets, listed in the README caption, are position, albedo, normal, the final image, depth, metallic, AO and roughness, arranged in a grid from top-left to bottom-right. That layout is a deferred renderer: geometry information is written to multiple targets in one pass, and lighting is resolved later from those textures.

The lighting features in the list match that architecture. Rectangular area lights are described as direct-only for both diffuse and specular, which is a deliberate limitation rather than a full area light approximation. Image-based lighting, screen-space ambient occlusion and stable cascaded shadow mapping are all techniques that consume the GBuffer. The ocean is a Gerstner wave renderer, and the terrain is generated with marching cubes. For a reader trying to understand how these techniques fit together in one codebase, the presence of the GBuffer capture is more informative than any amount of prose.

A scripting VM in the engine and a shader compiler that only rebuilds what changed

Two pieces of the toolchain are worth separating from the renderer. First, there is an in-game scripting language with a compiler, an editor and a virtual machine, implemented in FlexEngine/src/VirtualMachine/Backend/VirtualMachine.cpp. The engine therefore carries its own execution environment rather than delegating scripting to an embedded host, and the editor tooling list includes a transform gizmo, a property editor and a keybinding editor, with a scene editor that supports serialization, built around FlexEngine/src/Scene/BaseScene.cpp.

Second, the shader pipeline is checksum based and conditional, in FlexEngine/src/Graphics/ShaderCompiler.cpp. A shader is recompiled when its content changes, not every time the editor starts. Paired with it, FlexEngine/src/ResourceManager.cpp monitors file modifications for textures, meshes, prefabs, shaders and config files, so a developer editing an asset sees the change in the running editor.

This pair is what turns the project from a renderer into something you can iterate in. The cost is the amount of code you are implicitly signing up for, since a custom VM and a custom editor are each large subsystems with their own debugging surface. The README does not document the scripting language's syntax or its performance characteristics, so anyone planning to ship a game on this would be learning the language from source.

Building Flex Engine means starting from build.md

There is no installation command to copy, and there should not be one expected. The README's build section consists of a single sentence and a link: See build.md. The repository does contain a build.md at the top level, alongside a .clang-tidy configuration, a .gitmodules file and a scripts directory, and the presence of .gitmodules indicates that some dependencies are pulled in as submodules rather than fetched by a package manager.

CI configuration exists in the .github directory, and the README carries a Linux build badge pointing at build_linux.yml, so a Linux build path is exercised by the project itself. The README also states support for Windows and linux, and the CI badge is a useful signal for which of those two is actually kept building.

For a first real use, then, the honest sequence is: open build.md, follow the toolchain requirements it lists, clone with submodules so the .gitmodules entries are populated, and build the engine from there. The README does not restate the compiler versions, the graphics SDK version, or the exact commands, and it does not document a nightly build or a packaged binary distribution, so those details have to come from build.md and the source tree itself. Anyone who needs a one command install will not find one here.

Nine third-party libraries do the work the engine does not

Flex Engine states its dependencies explicitly, and the list is short enough to read in one pass. Bullet handles collision detection and rigid body simulation, FreeType handles font loading, glfw handles window creation and input handling, glm provides math operations, ImGui draws the user interface, OpenAL covers audio loading and playback, stb loads images, cgltf loads meshes, and volk acts as the Vulkan meta-loader.

That list is a reasonable way to read the engine's scope. Everything in the rendering, simulation and tooling layer is written in the project; everything in the foundation layer is borrowed. The choice of cgltf for meshes, stb for images and FreeType for fonts also tells you the asset pipeline is deliberately conventional rather than built around a proprietary format, which is what you would expect from an engine that is not trying to sell an editor.

There is a second-order point about the ImGui dependency. ImGui is an immediate mode interface, which is why the editor screenshots look like floating debug windows rather than a docked, themable application shell. That choice keeps the editor code small, and it is one reason the editor is described as a set of tools rather than a full IDE.

The alternative to the built-in profiler is an external GPU capture tool

Flex Engine includes basic profiling capture and inspection tools, and one screenshot shows a profiler overlay with a breakdown of the CPU time of a single frame. That is an in-engine view: it lives inside the running application, it reports the engine's own frame breakdown, and it is available without any extra software.

The project acknowledges the alternative explicitly. The README thanks Baldur Karlsson of renderdoc among the individuals whose resources were useful during development. A general purpose GPU capture tool approaches the same problem from the other side: it attaches outside the application, records the API calls and graphics state across a frame, and then lets you inspect that capture offline. The engine's own overlay answers a different question. It answers where the frame time went inside the engine, in a live window, while the external capture answers what the GPU actually received, in a tool built for that specific job.

The same shape of comparison applies to the educational resources the README credits, including vulkan-tutorial.com, the Vulkan samples by Sascha Willems, and learnopengl.com. Those are the references a reader is expected to pair with the source when the engine's own code is too terse to explain a pipeline stage.

A 2017 pre-alpha release and a recent push tell two different stories

The release history is thin in a way that matters. The repository has one published release, v0.0.3, labelled Flex Engine Pre-Alpha and dated 2017-11-08. A version labelled pre-alpha tells you what the author's own assessment of the code was at the time.

The other signal points the other way. The last push to the repository was on 2026-09-27, and the default branch is master while the screenshot links point at a development branch, which suggests work continues away from the published tag. The MIT licence is permissive, with a LICENSE.md file, so reuse is allowed as long as the copyright notice and licence text are kept.

The practical reading is that Flex Engine is a moving private project with a public mirror, not a released product with a support commitment. A tag from 2017 tells you little about the state of the Vulkan renderer today, and there is no changelog release history to diff against, though the repository does contain a changelog.md at the top level. If you plan to build on this, treat the current master as the only meaningful reference point and expect to read the source rather than a release note to understand it.

Editorial conclusion

Flex Engine fits a developer who wants to read and modify a real-time renderer rather than ship a game with one, and it does not fit a studio that needs a supported engine, a stable API, or an issue tracker with a response time. Before spending a weekend on it, open build.md and confirm it still builds on your platform with the dependency versions it expects, then check that the last push on 2026-09-27 corresponds to a state of the Vulkan renderer you can actually compile, since the only published release remains v0.0.3 from 2017.

Frequently asked questions

Official sources

1. ajweeks/FlexEngine on GitHub
2. License: MIT
3. Project website
4. README
5. Releases