DirectQ - Lightmaps and More - 3rd January 2012

The death-knell for my Windows XP/D3D9/Intel graphics PC finally sounded today when I switched it on and had a ton of errors pop up about failing fans and other such fun. I managed to keep it running for long enough to pull some stuff off it, but I'm wary about switching it on again.

Given the age of the machine, it's not worth hunting down replacements and fixing it up, so it's gone to the great spare parts bin in the sky. The replacement is - of course - Windows 7, 64-bit, D3D11-capable. As it's a work PC, and therefore business class, it's graphics capabilities aren't the best, but with an AMD Radeon 6450 it still hits just over 1000 FPS in timedemo demo1 with DirectQ. It's also nice to have an AMD to test stuff on.

So the way it's looking now is that the next release of DirectQ is going to be the final one where I can guarantee that kind of legacy hardware support. Following that it seems timely to bump to version number to 1.9.0 and officially raise the hardware requirements.

So there will be one more lower-spec release of DirectQ, which will be 1.8.9, following which 1.9.0 will have slightly raised hardware requirements: we're going to need Shader Model 3 or higher, hardware T&L, and a few other things. As these shake out I'll talk more about them.

One advantage of these raised requirements is that I can make use of features that previously I had to either offer an optional code path for or just ignore. This means things like vertex-texture fetch, more extensive instancing, full-on shader branching, raised instruction limits, extra texture formats and so on.

A specific first thing to do is in relation to texture formats, and their use in lightmaps. By being able to work on the basis that 64-bit textures are going to be now always available I can do things with lightmaps that were previously either impossible or messy. I've already got a setup in my experimental engine where I can bypass an intermediate array and skip over a LOT of checking and calculating; the end result is that the renderer is cleaner and faster, despite the extra overhead from reading a 64-bit texture.

The roadmap from there looks like a move to D3D11 for 2.0.0; I'm almost definitely committed to porting the experimental engine to D3D11 sooner rather than later, and a lot of the work on DirectQ over the past year has been carried out with that move in mind: switcing to shaders and vertex buffers for everthing, for example.

Regarding my intention to try a deferred renderer, I have carried out some initial work which was not too promising. A basic setup with 3 simultaneous render targets - one recieving diffuse, another lightmaps and the third fullbrights, then blending them together to the backbuffer, caused a huge performance drop. This was with D3D9; it's possible that D3D11 will offer more performant support.