As I've been working on this project I've realized that I need a space to throw a bunch of information regarding design patterns, API's, and system architecture. I can't retain all of this in my head and I've found some deep hidden blogs/research that have been extremely helpful. There will be "basic" information in this doc. I want a place where someone can start picking up on Game Engine Programming.
| Name | Platform | Reason |
|---|---|---|
| Vulkan | Windows, Linux, Switch | Hardware Abstraction Layer |
| DirectX12 | Windows, XBOX | Hardware Abstraction Layer |
| DirectXCompiler | Windows, Linux, XBOX | Runtime Shader Compilation |
| SPIRV Reflect | Windows, Linux, Switch | Vulkan Description Layout |
| STB | All | PNG, JPG, TTF, .OGG |
| WASAPI | Windows, XBOX | Audio |
| XInput | Windows, XBOX | Controller Support |
Fiber Based Job System
Asset Manager
Vulkan
COM in C
DirectXCompiler
Hardware Abstraction Layer
Frame Graph
Forward+ Rendering
This is what sparked the inspiration for Newport. I wanted to get as much juice as I could from the CPU so I decided to commit to a job system based architecture.
Parallelizing the Naughty Dog engine using fibers
Fiber based job system - Our Machiner
A lot of what I used in this asset manager came from experience. It's strongly based off of Jonathan Blow's engine for asset management. I don't use catalogs and just keep it together, but the general structure is there.
The Machinery Asset Pipeline
The Truth
Vulkan is the first graphics back end to be implemented. This means that the api is volatile until I can compere and contrast between the others
Yet another blog explaining Vulkan synchronization
Vulkan Barriers Explained
Synchronization-Examples
I had never worked with COM in my entire life. I have lots of questions about the design decisions but to be fair to the creators I'm not aware of COM's full capabilities so I will give them the benefit of the doubt.
COM in plain C
COM in plain C, Part 2
If you care to see how I solved this just checkout my DXC wrapper here
I really wanted the ability to write shaders once and then have them compile for both Vulkan and Direct X. DirectXCompiler seemed to be a great way to do it. Overrall the API is pretty easy to use. Works on Linux too which is a plus.
Using the DirectXShaderCompiler C++ API
Using the DirectXShaderCompiler C++ API - Revised
Spirv Descriptors
HLSL for Vulkan
This has been something thats been on my mind for years now. The more I dig the deeper I go. This one will be constantly updated.
An Opinionated Post on Modern Rendering Abstraction Layers
Binding Bindlessly
Vulkan Textures Unbound
Halcyon Architecture "Director's Cut"
A modern rendering architecture
A Comparison of Modern Graphics APIs
Musings on cross-platform graphics engine architectures - Part1
Vulkan Guide
Vulkan DX12 Comparison
OurMachinery Bindless
I'm going to be following in the mindset of Alex Tardif in his article An Opinionated Post on Modern Rendering Abstraction Layers. I want to keep things as simple as possible and not limit the user too much.
I've spent a good bit of time researching Frame/Render graphs to determine if I want to implement one. I'm still not sure but I think they're promising. Maybe this could be a fun stretch goal.
High-Level Rendering Using Render Graphs
Render graphs
Render graphs and Vulkan - a deep dive
Simon's Tech Blog: Render Graph
FrameGraph: Extensible Rendering Architecture in Frostbite
It seems that deferred is slowly losing the grasp it once had on the industry. Games like Doom Eternal seem to really be pushing forward what is capable with graphics by using Forward+.
Forward vs Deferred vs Forward+ Rendering with DirectX 11
Doom Eternal - Graphics Study