Free DX 12 Rift Engine Code

No, I didn't compare performance to other examples. But performance is a big topic for me. And the Microsoft tools are very good in showing you the bottlenecks of your code.

Some remarks with regards to performance:

• I copied the approach of the Microsoft provided DX12 examples of using 3 frames at the same time for rendering and synchronizing them with fences. Unfortunately the documentation about this topics lacks any depth, so there are a lot questions unanswered. I found it hard to come up with a system that really runs parallel and doesn't limit access to your central objects. Certainly a topic that needs to be revisited.


• Texture preloading. For a small framework like mine I think it is ok, even beneficial, to preload all textures in start up phase. It is just a lot easier when you know that all textures are already in GPU memory when you start rendering. Not something a big engine for big games could do, but for smaller applications I think it is the right way to go.


• Threaded approach. I experimented a lot with threads for the 3D text shader. Meant as a diagnostic tool, it doesn't matter if text changes are reflected some frames too late in the world. So on rendering the input buffer that is already presend on the GPU is just reused. Only some bytes with the current View/Projection Matrix have to be copied to the GPU before rendering can start. A background thread is responsible to update the GPU input buffer for all the text in the background and then just switch to the new buffer once it is ready. With this approach it doesn't really matter how much text you display (at least not until the text shader on the GPU becomes the bottleneck). In my example I display over 1000 lines of text without seeing any performance degradation at all. I still have several hundred frames per second in a window and constant 75 fps in the rift.


• Rift optimizations. One advantage to start with a completely new framework is that I do not have to pay attention to existing shader code and more traditional ways of rendering. Usually, for most existing engines, each shader updates it's data for each frame in an update method, then renders in a draw method. When you draw for the rift, you draw the two images for each eye right after another. The images are very similar, but obviously not exactly the same. There is a lot overhead involved in going through all the update and drawing code twice. My shaders are designed in a way that as much unnecessary double work can be avoided as possible. Basically, all setup (like input buffers, updating world positions of your objects) is done only once. When it is time to issue the actual draw call on the GPU, the corrected Model/View/Projection matrix for the current eye is copied to the GPU and rendering starts.