Welcome back to another one of our Corporeality weekly updates! This week, as we mentioned previously, we’ve taken a step back from weapon collisions briefly to look at a few longstanding engine issues.

Vulkan

As mentioned last week, we’re looking at finishing up the Vulkan renderer in our engine and making it the default on systems that can support it. This is a multi-stage project that won’t be done for quite some time, and right now we’re just taking the opportunity to chip away at it as a healthy distraction.

I spent quite a while earlier in the week just trying to get Vulkan to work on macOS, and it was actually incredibly enlightening. As a result of these efforts, I think we now better understand how exactly Vulkan works on an architectural level (i.e. the library, ICD, layers, and available devices).

Quality of Life

During this time, we’ve been refactoring the very oldest parts of the engine codebase like for example replacing raw globally namespaced type names with properly namespaced, more sensical names. Like, what does DeltaTicks even mean to someone not familiar with the engine?

We’re also in the process of moving some of the non-functional stuff in the engine into a separate library intended for core types, mathematics, etc, in order to keep things better organized and avoid a naming scheme that doesn’t make sense half the time. Why do we have polar::support::phys::detector::ball instead of just ptl::detector::ball? These and other things will look a lot better and not cause naming sanity to be questioned every week!

Next Steps - Asset Pipeline

This coming week, we’re going to be finishing up the in-progress quality of life changes, and then we’re going to move on to the asset pipeline.

Our asset pipeline is the build step that runs just before we test/distribute a build of the game. Our assets directory is scanned and any supported files (.png, .wav, etc) are packaged in our internal engine format. However, due to the nature of how the pipeline currently works, we’re unable to do things like:

• Convert an asset back to a source format
• Convert an asset to any number of formats
• Convert any number of formats to an asset
• Allow an asset to add a required dependency on another asset
• Convert to an asset in-engine rather than at build time.

These are some of the things we’re going to address in the coming week as we rework how the asset pipeline works. This step will be required in order to support Vulkan, as we need to take our existing shaders and package them up such that we can use them in our OpenGL renderer as well as our Vulkan renderer.

All in all, it’s going to be a busy but exciting week, and hopefully we can complete a lot of the stuff we’ve talked about.

Thanks again for sticking with us on our journey, and, until next week, jumpa lagi!

⚡ Shockk, Lead Programmer