Post Haste

This is the first project in the second year where we got to build our own engine, me and Emil Löfling migrated the base for rendering from the graphics course and later we also implemented multithreaded rendering to go with our ECS.

At the start of the project our group discussed on what the pros and cons for different systems, the two most discussed systems were a component system and an entity component system, in the end we decided to go with the ECS. 

When we started to build our engine and me and Emil started to do prototypes, research and talk about design choices. The idea was that an ECS would give us a modular engine that could add and remove components with ease and gain performance by both cache alignment and trying to make it as data oriented as possible without sacrificing too much of the readablility. At the start of the project we wanted to create a solid base to build the rest of the engine on while also get forward with the project. Me and Emil started to design the ECS while the others started to build gameplay without the ECS. A few things we agreed upon we needed to do was having the logic run lock-free outside the sync, by doing that we had to also handle all changes to the entities with delta values instead of absolute values to handle multiple changes to an entity through different threads. We tried to follow how Blizzard implemented an ECS for Overwatch where the components contains no logic and the data in the components is read and used by systems which only has logic and no data, that way all the data is structured nicely for the cache. Sadly in the end I had to take other tasks as this took more time than first anticipated and Emil finished the ECS implementation. 

ECS overview

This diagram shows how our systems sends data in form of delta values to make multiple systems able to output data to the sync to the same components even if all systems are threaded. The systems reads the data from the components which are aligned in memory as all components are 



This also allowed us to use ImGui in our engine without having to worry about it's device context to fail in a race condition.

Using ImGui I implemented things many debug windows to help people, like FPS counters, triss counter, cheat buttons etc.


I wanted to be able to turn off ImGui so for all debug tools and things we could want to turn off I created an Engine Defines file where we could define things to help with this. 

In the left picture I just created a simple tool to help track FPS and on the right side I add all indicies from the models to a counter then divide by 3 to get an estimate of the trisscount. 

I also handled the input, the menus, buttons and an asset viewer which would have allowed our artists to view their models in engine, sadly this was implemented a bit too late which hindered the usage of it. I also implemented a statemachine to handle the state between game and the menus.