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.

The last week has been mostly spent writing generators for the various objects required by the game. If anyone is interested, the objects are: assorted pressure pads, a simple switch, a ‘capture’ switch, a door target selector, a power selector, a sphere, a pole, a bridge, assorted boxes and stair generators.

Still a bit of work to do on some of them and I have some shader work to make others operate properly.

The biggest advantages of using generators rather than building and loading models, is the ability to have variations on a theme and dynamic configuration with little cost. For instance the number of sides of a switch can be adjusted on demand and the iconography dynamically selected to match whatever is needed.

Anyway, as I said, there is still a bit of work required on this and I need to add some additional support for procedural textures, including decent Perlin and Simplex noise generator in the shaders.

Well getting the keyboard and mouse controls in and playing nicely with both windows and my existing debugging input was a lot fiddlier than I had expected. It is in now though and you can check out the changes by getting the latest demo from the downloads page.

Also new is in-demo controls information which you can bring up at any time by pressing the ‘tab’ key.

Other changes are not visible to the user but include some architectural tidying up, optimisations and bug fixes.

Putting in the mouse controls raised an interesting issue. I’m developing on a 2011 HP laptop, which is generally pretty good. Unfortunately there was an issue with Radeon graphics drivers around 2011 which causes them to stutter, chewing through CPU time and locking the GPU when discarding constant and vertex buffers. Even more unfortunately I can’t update the drivers to a later version without the problem.

With the mouse controls in, the stuttering became even more apparent, though I’ve partly dealt with the issue by scaling the mouse input by the inverse of the update time.

Having older hardware is a double edged sword, it can be frustrating and slow down development progress – but the positives are also significant. It makes fixing these kinds of issue (which might not effect players with newer hardware) a priority and means that there are less likely to be nasty surprises once the game is released. With older hardware you also have to pay attention to performance early in development, which means better support for slower hardware and as a result the game is likely to be accessible to more people.

Most of the work for the last week or so has been behind the scenes changes fixes, optimizations and prep work for the main physics.

I have added support for door frames and enabled them on some of the doors. I’ve also added outlining to the geometry which proved to be a useful test of the geometry building code and got used to validate the collision data. The outlining will also prove useful when it comes to dealing with anti-aliasing, but that’s still quite a way off.

Tomorrow I’ve got a little shader code to tidy up, but then I think it’s about time I hooked up keyboard and mouse controls. A lot of the input work has already been done, so hopefully it should just be a case of hooking it all up.

Anyway, the demo on the downloads page has been updated, so if you are interested in seeing the changes head on over and get it.