The-Forge

The Forge Framework (TM) is a cross-platform programming framework supporting the following platforms:

• Windows 10/11 with DirectX 12 / DXR
• Steam Deck with Vulkan 1.1 with VK_KHR_ray_query Ray Tracing API
• Android Pie or higher with Vulkan 1.1
• Apple
  • iOS 14.1 / 17.0
  • iPad OS 14.1 / 17.0
  • macOS 11.0 / 14.0, with Intel and Apple silicon support
• Quest 2 using Vulkan 1.1
• XBOX One / XBOX One X / XBOX Series S/X *
• PS4 / PS4 Pro *
• PS5 *
• Switch using Vulkan 1.1 *

*(the console platforms are only available for accredited developers on request. Please note that you need a license from us to use the console platforms.)

The Forge Framework (TM) (TF) provides building blocks to

• extend
  • Existing game engines so that they support more platforms (Starfield ...)
  • Old games (e.g. 20+ years) can be brought back to modern gaming platforms
  • … and/or write custom game engines from scratch (most notable Supergiant Hades, Hypixel Game Engine)
• write SDKs (Adreno SDK, Oculus / Qualcomm VR SDKs, Dolby AR SDK, Dolby Vision etc.), enable new technology (Google Stadia, Dolby Vision, Meta App framework etc.)
• Supports most of the gaming platforms As such it is a core part of our service business.

We offer many platforms (PC, macOS / iOS, Android, Steamdeck, Quest) under the Apacke License Version 2.0 here on Github. We offer a commercial license for game consoles (Playstation, XBOX, and Switch).

Here is an overview:

• Game Layer (partially provided)
• App
• Renderer / Scene (not provided) / Resource Streaming (not provided) / Resource Loading / Animation
• Graphics / OS / Utilities What is not there: Physics / Networking / Sound

The "lego" High-Level Features supported on all platforms are at the moment:

• Resource Loader capable to load textures, buffers and geometry data asynchronously
• Lua Scripting System - currently used for automatic testing and in 06_Playground to load models and textures and animate the camera and in several other unit tests to cycle through the options they offer during automatic testing.
• Animation System based on Ozz Animation System
• Consistent Math Library based on an extended version of Vectormath with NEON intrinsics for mobile platforms. It also supports now Double precision.
• Consistent Memory Managament:
  • on GPU following Vulkan Memory Allocator and the D3D12 Memory Allocator
  • on CPU Fluid Studios Memory Manager
• Custom Input system library with Gestures for Touch devices written in C
• Fast Entity Component System based on flecs
• Cross-platform FileSystem C API, supporting disk-based files, memory streams, and files in zip archives
• UI system based on Dear imGui extended for touch input devices
• Shader Translator using a superset of HLSL as the shader language, called The Forge Shading Language. There is a Wiki page on The Forge Shading Language
• Various implementations of high-end Graphics Effects and game engine sub-systems as shown in the unit tests below

Please find a link and credits for all open-source packages used at the end of this readme.

Join the Discord channel at https://discord.gg/zxPRFzKGqD

The Forge Interactive Inc. is a Khronos member

News

Release 1.64

Continued on https://codeberg.org/The-Forge

Release 1.63 - March 20th, 2025 - Advanced RTX Global Illumination Middleware | Quest Run-time switches to OpenXR | Triangle Visibility Buffer with Programmable MSAA | Ephemeris running on low end mobile devices | Particle System UT now runs on Adreno Devices with lower storage buffer limits

Advanced RTX Global Illumination Middleware

Over the last three years we developed a solution for Global Illumination based on the RTX / DXR interfaces. This development was fuelled by the games that will use this solution. We are adding it to our arsenal of graphics middleware, which is not publicly available. In case you want more information, please drop us a note. Here is a feature list and screenshots:

• New sky shading model for more accurate GI
• Normal texture generation from depth
• Single pass depth hierarchy from FSSR
• Screen space ray marching for evaluation of screen space GI
• Single bounce hybrid ray tracing for GI
• Multi bounce GI with probe volume cascades
• World and frustum GPU hash implementation for samples accumulation
• Denoising with reprojection and a weighted blur
• Batching rays for indirect dispatches as an optimization
• Spatiotemporal reservoir sampling

Following the trajectory of RTX based Global Illumination approaches, this should be the most advanced and already proven system out there ...

Android Samsung S24 Xclipse 940

PS5

Steam Deck

Xbox Series X

iPhone 15 Pro

Quest Run-time switches to OpenXR

We made the internal switch to finally use OpenXR. A funfact is that we used and helped to develop OpenXR in projects since about 2016 but never implemented it into our own code base ... only customer code bases.

Triangle Visibility Buffer with Programmable MSAA

This is an oldie but goodie :-) ... I (Wolfgang) wrote several blog posts about it and talked on conferences about it and now we have it in our code base. I remember having been involved at Rockstar Games with developing a programmable MSAA approach on XBOX and PS in 2006 (?), we had examples running with it in our code base over the years. We finally found time to bring it also into our open-source code base inside the Triangle Visibility Buffer.

Android Samsung S21 Mali-G78

PS4 Pro

PS5

Xbox Series X

Quest

Debug screenshots Godray samples 4xMSAA

VB Shading samples 4xMSAA

Stencil mask 4xMSAA

Ephemeris running on low end mobile devices

This was also one of the overdue things. Ephemeris is our skydome system that shipped in game engines before. Most of the time we had it running on PS4 class hardware but now it also supports low-end mobile phones. It is in our non-public middleware folder. Drop me a note if you want to know more.

Particle System UT now runs on Adreno Devices that do not support bindless Textures

Now there is a fallback for devices with lower storage buffer limits. Also we further optimized the size of the particle data to accommodate more particles in the particle buffer.

Release 1.62 - February 27th, 2025 - C99 Vulkan/DirectX rewrite | Scene resolution using GPUCfg | SRT updates | In-Flight Motion Vector

C99 Vulkan/DirectX API rewrite

Our quest to move as much code to C99 as possible is motivated by the idea that small teams deal better with a C99 code base. We are targeting this framework at small teams that need to be agile and quick. We finished a first pass on the Vulkan and DirectX run-time. There is more to come.

Scene Resolution using GPUCfg

On mobile phones and mobile devices, the scene resolution is quite often very different even for one category of devices like Android Phones. So we have a better system now in place to really define scene and screen resolution with the GPU config system.

FSL 2 improvements

After having shipped a Shader Resource Table based FSL language two weeks ago, we have done a bit more clean-up work and unified and simplified naming conventions.

Quest Support

We make on-going improvements for the Quest support.

Triangle Visibility Buffer 2.0

We found several issues with TVB 2.0 and fixed those. Next step is to make another pass on the architecture and see how much better we can make the memory access patterns to improve performance.

In-Flight Motion Vectors

Many people still store motion vectors in render targets. For the last 15+ years that didn't make much sense anymore because the memory access pattern to write and read those motion vectors was so costly that calculating them on the fly made more sense. This approach is based on Ben Padget's article in one of the ShaderX books ... he will smile about the fact that after all this time we are still quoting his article ...

Release 1.61 - February 13th, 2025 - FSL 2 | Browserstack | Android / Vulkan | DirectX 11 | Quest | flecs

FSL 2

We are enforcing now a better memory access pattern for root signatures. We unified root signature usage, so that in best case only one or two need to be used for a game. To do this we added a unified shader resource table that is shared between FSL and C++. We wrote a more thorough documentation here:

https://github.com/ConfettiFX/The-Forge/wiki/FSL-Programming-Guide

This is a good example how shader languages should evolve. Instead of mimicking the misguided efforts in writing a C++ shader language, a shader language should mimic the memory access patterns of a GPU and guide the user towards the "best and most performant" results. From a practical standpoint, unreliable and non-functioning shader compilers are a bigger problem than any language syntax to please some twisted abstraction that has no performance benefit and happens for no good reason.

Browserstack

For testing mobile phones we integrate Browserstack more and more into our workflows.

Android / Vulkan

After having finished our more than four year stint on the Warzone Mobile project, making and keeping the game run on Android phones, this same team is now making sure our internal Android / Vulkan run-time lives up to the same or higher expectations. Browserstack is used to test a larger number of phones now. Higher-end phones will now support our Triangle Visibility Buffer unit tests. It appears that a lot of our priorities in the game industry are shifting towards mobile and also to a lesser extend consoles, as the most important gaming platforms now. We are trying to find ways to make sure mobile is the first class citizen.

DirectX 11

We removed DirectX 11 support with the retirement of Windows 10.

Quest Support

We help developing the Quest since 2016 now. We somehow missed to take care of our own Quest run-time :-) ... we are currently catching up on all the missed opportunities here and updating and upgrading it. Making it a better part of our test suite and adding more unit test support.

flecs

We improved our flecs integration and upgraded to latest.

Release 1.60 - October 11th, 2024 - GPU Work Graphs | Filesystem Refactor | Window System Refactor Phase 1

GPU Work Graphs

We are testing GPU Work Graphs now for a while. We see opportunities to implement more complex compute driven interactions, which helps us to move towards GPU-driven rendering more and more. The current example runs the clear buffers and triangle culling in a GPU Work Graph if GPU Work Graphs are supported. Otherwise it takes the old path. So visually there is no change.

Filesystem Refactor

We data drive the everything in a game engine. For the file system, we finally managed to implement that too in the public repository. We also removed unnecessary copies and symlinks. Please note our file system consists of "two" file systems. One for the run-time and one for tools. You can't ship a tools file system in a game :-) I know that this is well known but people always want to check if a path is right, a directory exists, a file exists, before they load this one file ... yeaahh ... so our run-time file system prevents that from happening.

Window System Refactor Phase 1

With the on-going challenges in the area of upscaling and general window management on Operating systems that support windows, we decided to refactor our window system to bring it