The Forge Framework: a C++ cross-platform renderer for PC, mobile and consoles

What The Forge Framework solves, and who it is actually for

Writing a renderer once and running it on Windows, macOS, iOS, Android, Steam Deck and Quest is the recurring problem this project targets. The README frames The Forge as a set of building blocks rather than a finished engine: it lists a Graphics / OS / Utilities layer, an App layer, and a partially provided Game Layer, then states plainly what is missing. Physics, networking and sound are not there. Scene, resource streaming and resource loading are marked as not provided.

That tells you who it is for. The README names three uses: extending existing game engines so they reach more platforms, bringing old games back to modern platforms, and writing custom engines from scratch. It also lists SDK work (Adreno SDK, Oculus and Qualcomm VR SDKs, Dolby AR and Dolby Vision) as a supported use. The named shipping titles are Starfield, Hades and the Hypixel Game Engine.

If you are a solo developer looking for a game engine with an editor, this is the wrong shape of project. You get the graphics and platform layer, and you write the rest.

The renderer, the shader language and the lego blocks

The Forge Shading Language (FSL) is the piece that makes the cross-platform claim concrete. It is a superset of HLSL, and the README points to a wiki page called the FSL Programming Guide. Shaders written in FSL are translated to the target platform's shading language, which is why one shader source can serve DirectX 12, Vulkan and Metal targets.

On top of that sit the high-level features the README calls the lego blocks, available on all platforms. There is an asynchronous resource loader for textures, buffers and geometry. Animation comes from the Ozz Animation System. Math is an extended Vectormath with NEON intrinsics for mobile and double precision support. Memory management follows Vulkan Memory Allocator and D3D12 Memory Allocator on the GPU side, and the Fluid Studios memory manager on the CPU side. There is a C API filesystem that handles disk files, memory streams and files inside zip archives, a C input library with touch gestures, a flecs-based entity component system, and a Dear ImGui UI layer extended for touch. A Lua scripting system is used for automated testing and in the 06_Playground example.

The graphics feature set is where the project spends its release notes. Release 1.63 describes a triangle visibility buffer with programmable MSAA, an RTX-based global illumination middleware with probe volume cascades and spatiotemporal reservoir sampling, and a Quest runtime that moved to OpenXR. That GI middleware is explicitly not publicly available: the release notes say to contact the company for information. So the most advanced rendering work described in the repository is not something you can read or build from the GitHub tree.

Building it on Windows, macOS or Linux

The repository root contains three entries that matter for a first build: PRE_BUILD.bat, PRE_BUILD.command and a Tools directory. The README does not spell out the build steps in the text we have, so the safest path is to run the pre-build script for your platform and then open the generated project files for the unit tests under Examples_3.

On Windows, run the batch file from the repository root:

PRE_BUILD.bat

The script is named for the platform it targets, so this line is Windows only. On macOS, the equivalent is the command file:

./PRE_BUILD.command

After the script finishes, look inside Examples_3. The unit tests are numbered, and the README refers to 06_Playground as the example that loads models and textures through the Lua scripting system and animates the camera. That test is the most useful first target because it exercises the resource loader, the scripting layer and the renderer together.

One constraint to plan for: the README says the console platforms (XBOX One, XBOX Series S/X, PS4, PS5, Switch) are only available to accredited developers on request, and that you need a license from the company to use them. The GitHub repository under Apache-2.0 covers PC, macOS, iOS, Android, Steam Deck and Quest, not the consoles.

Where The Forge stops and you start

The most important limitation is written into the README's own layer diagram. Scene management, resource streaming and resource loading are marked as not provided. If your project needs a scene graph, a streaming system that pages content in and out as the player moves, or a content pipeline that turns artist assets into runtime data, none of that ships here. You build it, or you bring it from the engine you are extending.

Physics, networking and sound are also absent. That is a deliberate boundary, and it is consistent with the stated use cases: extending an engine that already has those systems, or writing an SDK that does not need them.

The second limitation is licensing, and it is easy to misread. The GitHub repository is Apache-2.0, but the README states that console platforms require a license from ConfettiFX. Apache-2.0 on the public tree does not grant you the right to ship on PlayStation, Xbox or Switch.

The third is distribution. Release 1.64 in the README says development continued on Codeberg at codeberg.org/The-Forge. The GitHub repository's last push was on 2026-08-27, so the GitHub tree is recent, but the release notes themselves point readers elsewhere for the newest work. If you are choosing where to track the project, that sentence is the one to read carefully.

How it compares to writing against one native API

The obvious alternative is to skip the abstraction and write directly against DirectX 12, Vulkan or Metal. That is a real option if you ship on one platform. You get the vendor's documentation, the vendor's debug tools, and no translation layer between your shader source and the driver. You also give up the ability to move that renderer to a second platform without a rewrite.

A second alternative is a full engine such as Unreal or Unity. The difference in approach is not subtle. Those give you an editor, an asset pipeline, physics, audio and networking as part of the package, and you work inside their architecture. The Forge gives you the platform and graphics layer and expects you to bring or build the rest, which is why the README lists Hades and the Hypixel Game Engine as custom engines built on it rather than as projects configured inside it.

The choice comes down to where your team's effort already sits. If you have engine programmers and a renderer you want to port, The Forge is a thinner layer than adopting a full engine. If you do not, the missing scene and streaming systems are work you will fund yourself.

Maintenance, upgrades and the license boundary

The GitHub repository is not archived, and its last push was on 2026-08-27. Releases arrive at a steady cadence: v1.61 in February 2025, v1.62 later that month, v1.63 on 2025-03-21. Each release note describes substantive renderer work, so upgrades are not cosmetic. A release that rewrites the Vulkan and DirectX paths, as v1.62 describes with its C99 rewrite, is not a drop-in update for a project that has modified those paths.

Budget for that. If you fork The Forge to extend an engine, you are maintaining a fork against a moving renderer, and the cost of each upgrade is proportional to how far your fork has drifted.

On licensing, the split is explicit in the README: Apache License Version 2.0 for the platforms offered on GitHub, and a commercial license for game consoles. Apache-2.0 is a permissive license, but the console platforms are not in the public tree at all, so the license question and the access question are the same question. If consoles are on your roadmap, contact ConfettiFX before you build a plan around this repository. This is not legal advice; read the LICENSE file and the console terms yourself.

Editorial conclusion

Adopt The Forge if you are extending an existing engine to more platforms or building a renderer or SDK in C++, and you accept that scene management, streaming and loading are yours to write. Do not adopt it if you need a complete game engine with physics, networking and sound, or if you only target one platform where a single native API would be simpler. Before committing, clone the repository, run the PRE_BUILD script for your OS, and check two things: whether the unit tests you care about build and run on your target, and whether the console license terms from ConfettiFX fit your project, since those platforms are not covered by the GitHub license.

Frequently asked questions

Official sources

1. ConfettiFX/The-Forge on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases