Home Artists Posts Import Register

Downloads

Content

Patreon video quality is terrible! The original video is available here

Sector's Edge and the Vercidium Engine are both intertwined within the same codebase. This is not ideal if we want to make more games!

I've spent the past 3 weeks extracting parts of the engine out into their own codebase, then re-implementing them back into Sector's Edge to ensure it still works.

I've been dreading doing this for a while but it's been much easier than I expected. Over the past 3 weeks I've extracted and cleaned the following engine code:


Engine Features

Audio

This code manages OpenAL devices (e.g. speakers and microphones) and playing spatialised sounds (no raytracing yet). It also handles loading audio from disk on background threads for fast startup times, and encodes microphone data for voice chat networking.

Buffer

This code is all related to creating, updating and rendering OpenGL buffers. Boring stuff but super important for utilising modern OpenGL rendering methods, which are very quick!

Client

Client code relates to the game client you run on your PC, i.e.:

  • Window creation
  • Gameplay loop
  • Keyboard and mouse input
  • Loading resources from disk

Constants

It's common for programmers to avoid global variables because they're 'unsafe'. This is one of many programming paradigms that I completely ignore.

This folder contains constants (e.g. weapon damage values) and user-customisable settings (e.g. mouse sensitivity) and these variables can be accessed from anywhere.

CX

Regular UI elements (e.g. a checkbox in settings) are called 'UX elements' and are rendered on the main thread. To reduce stuttering while playing the game, elements like ammo and health are instead rendered on background threads. These are called CX elements. I can't remember what CX stands for.

GL

This folder contains helper functions for preparing OpenGL commands and profiling how long they take to execute.

Model

This part of the engine is dedicated to loading Simon's models and animations from Blender and onto the GPU. It also categorises them into parts - for example the Assault Rifle is composed of 20 parts that are hidden/visible depending on what attachments are equipped.

Particle

This is my favourite part of the engine - I love particles! All VFX in Sector's Edge are particle based and this is where I learned most of the multithreading and rendering techniques that are used throughout the engine.

This particle code manages spawning, updating and disposing particles at a rate independent to your visual FPS, meaning particles can render at a slower FPS to prevent lagging the game. This framerate-independent technique was then applied to map meshing, animations, audio and UI rendering to ensure that they never slow the game down or cause stutters.

Shader

There are some shaders that will be reused in all our 3D games, such as anti-aliasing and dynamic exposure. Not much to see here!

Shadow

Shadows are the bane of my existence and I still struggle with them to this day. In an attempt to understand how to render high-quality shadows that don't flicker, I've recently taken a step back and started to learn the maths behind modern shadow rendering techniques.

I will report back in 8 years time when my shadows finally look good.

Texture

This folder contains the oldest code still alive today, dating back 6 years ago when I first started working on 3D games. That's not because I got the code right on the first go - it's because I have an irrational fear of textures.

I recently ventured back into this texture code because Sector's Edge was using too much RAM. There is a lot to unpack here and I'll write a detailed blog post on normal map generation, palleted textures and texture arrays, all of which lead to some nice optimisations.

Thread

This code is pretty light and consists of some helper functions that schedule work to be executed on background threads, e.g. updating particles and animations, rendering UI, meshing voxel worlds and audio raytracing.

Types and Utils

These folders contain classes and simple functions that I reuse everywhere - generating random numbers, interpolating between two values, allocating memory, etc.

Experiment 1 - Terrain Generation

As I've been extracting all this code into the Vercidium Engine codebase I've been creating demos and experiments to ensure everything is working correctly. I then fell down the rabbit hole of terrain generation and heightmap rendering and became addicted to it!

So far I've managed to get it rendering lightning fast using techniques I've learned this year, such as indirect voxel rendering, instanced particle rendering and multithreaded mesh streaming.

The video attached to this post is rendering a 64x64km plot of terrain in 2.5ms on my RTX 3070, has stutter-free terrain terrain generation and streams heightmap mesh data to the GPU in real time as you move around.

I have a fair way to go to make it as fast as voxel rendering in SE - which renders the entire Capital map in 0.28ms - but I am thoroughly enjoying working on it!


Comments

Anonymous

Very cool! I think I might know the answer, but are all of your games going forward going to prioritize accessibility (in terms of hardware requirements)? Thankfully I have a nice machine so I'm not too concerned, but I know that was important for SE and I'm curious if you have any thoughts/plans on something a bit higher fidelity

vercidium

I won't create another entire rendering pipeline like bare minimum, but you'll still be able to customise rendering settings to ensure you can play the game smoothly.