Christopher Vedlund Portfolio

☰

Zengine

Is my own C++ Game Engine using the DirectX graphics API.
Began as a part of the Applied Graphics Programming course at TGA, but extended into my own interest and something I started developing further on my own.

So the things that I will list is stuff I've done on my own, and not part of the course.

What I've implemented:

ImGui Editor
ECS
Shader Compiling
Inverse Kinematics (Specialization)
Asset Management
And more!

ImGui Editor

During the course of Applied Graphics Programming, I wanted a way to test different values, such as lighting or camera settings, without needing to rebuild the engine each time. To address this, I decided to integrate ImGui, a graphical user interface library, directly into my engine. This allowed me to create sliders, buttons, and input fields for real-time adjustments of parameters like lighting intensity or camera position while the engine was running. Using ImGui, I could modify values and instantly see the effects without stopping the engine or recompiling. This made testing much faster and more efficient, improving my workflow and reducing downtime during development.

ECS

After we had a presentation about ECS, I wanted to learn more about how they functioned. I implemented a way to store entities in pools, which the components then gets added to. This made it so the components were stored next to eachother lowering the chances of cache misses.

Since in ECS the logic are in systems, i made an interface system which also makes so I can store the ISystsem type.

After implementing ECS I understand how it works more working with only entities instead of gameobjects. I much more prefer a component system were the logic is inside of the components. With my current implementation the logic of multiple components is in the same system, which makes the code unclear and hard to follow.

Shader Compiling

I wanted to find a more efficient way to add textures and variables to the shader without the need to create a custom buffer for each one. During my research, I discovered that DirectX 11 provides a powerful feature called shader reflection. This feature allows you to reflect the data within the shader, which makes it possible to read every texture and buffer that is currently bound to the shader program.

However, I encountered a small challenge: variables had to be placed inside a constant buffer to be properly reflected. This required some extra setup on my part. Essentially, the reflection process looks for a specific buffer—named "PublicContainer"—which holds the necessary data for the shader. Once the reflection process identifies this buffer, it extracts the relevant data from it.

To further optimize performance, I decided to store the reflected data into a material file. This file contains the necessary information about the textures, variables, and buffers. By doing this, the shader doesn’t have to undergo the reflection process each time it is loaded, thus significantly reducing redundant computations and improving efficiency during runtime.

This method of storing material data makes the workflow much more flexible, as it eliminates the need to re-reflect the data on every shader reload. Instead, the system can simply load the material file and reapply the variables and textures as needed, streamlining the shader management process.