While adding some lookup textures for the shader noise functions it became apparent that I needed to do some work on the engine that I’d been hoping to leave for later. As I type, I’m about a half way through this work.

So what am I doing and why is it needed?

The engine underlying Locality (‘the Void engine’) abstracts the GPU and resources to allow easy porting to new devices and APIs and to automate most of the hardware settings such as resource bindings and shader chains. There is actually significantly more code in the tools which prepare the data for the run-time engine than in the engine itself.

In theory the Void engine has fully automatic management of physical resources (textures, render targets, constant buffers etc.), unfortunately in practice I left the creation of physical resources up to an older engine that I already had. Doing this allowed me to move forward with Locality specific work at an earlier stage in development.

Having two systems operating at the same time has now become a problem. The new system expects to be fully managing resources, but the requirements of the old system mean I have to bundle duplicate data with every new resource and manually manage it, even though the new system is automatically managing caching and garbage collection of ‘proxies’ for these resources.

This has been workable for a while, but now is starting to create a lot of additional work and is cluttering up layers of the engine with dependencies that should not be needed. On top of that is the need to keep a clear understanding of two significantly different architectures in my head all the time and watch out for interactions which don’t map well between the two.

I’m not sure if anyone is reading this blog or can take anything useful away from the above explanation, but anyway, once this update is complete I’ll try to do a new post explaining the architecture and abstractions used by the Void engine.