![\"\"](\"http:\/\/www.anguishgames.com\/download\/images\/GoodGraphics27.png\")
<\/a>GoodGraphics27.png, toxic tables!<\/p><\/div>\n
So, that’s what you can see; let’s talk about what you can’t see. \u00a0Last year, I built my render target class to own a back buffer and a depth buffer, and created a system to copy a depth buffer from one render target into another. \u00a0I was told it was strange to not share a single depth buffer across my render targets, but there were cases where I wanted the main geometry buffer for a process and I wanted to change it for current use without changing it for geometry. \u00a0There were also cases where I down and up scaled render targets, which necessitated different depth buffers with different sizes; it’s how I achieved my geometry occluded outlines last year. \u00a0It worked for me, but it didn’t come without it’s difficulties. \u00a0And as I was re-implementing render targets this year, I realized that I overlooked a lot of potential performance gains last year.<\/p>\n
I was re-using depth information for geometry occluded outlines, and I was using it to generate lighting information, but I wasn’t actually using it to cut down on overdraw. \u00a0And overdraw was a huge problem in Evac (especially the final level, which was huge). \u00a0So, I re-factored my render target system to instead keep a pool of back and depth buffers, and a render target now makes associations to the buffers in the pool that it wants. \u00a0This allows easy sharing of buffers between targets (and without DirectX complaining about binding a buffer for read and write simultaneously!) in a way that let me do a Z Pre-pass process that is intended to build the shared depth buffer but remain lightweight by only ever engaging the vertex shader. \u00a0Once that depth buffer is built, all processes that utilize it can set their depthstencil state to D3D11_COMPARISON_EQUAL to ensure that each screen pixel is engaged by a pixel shader only once. \u00a0And since the pixel shader is often where you can find pipeline bottlenecks, optimizing it’s usage can be key to keeping a high performing renderer. \u00a0So, ensuring that each process pass at most engages a pixel shader once per pixel is a huge boon and I was very pleased with the results.<\/p>\n
The other thing you can tell from the image is that I’ve started work on my post-processing system. \u00a0It’s not going to be terribly different from last year’s base system, but I’m looking to implement a new set of effects to give the game a filmic look. \u00a0It starts with the depth of field effect you can see here, but there’s a lot more in the works to eventually make the game look good. \u00a0I hope. \u00a0Also, with the re-organization and re-optimization of the whole system, I’m hoping to have the frame time available to do a LOT more post-processing this year.<\/p>\n
So, that’s all for this time. \u00a0There were actually a lot of errors going on behind the scenes around this time that looked correct enough to not notice them right away, but which created huge problems when I tried to tweak data. \u00a0I’ll probably talk about them next time as I think that they’re pretty interesting, and might be useful to anyone implementing a similar system. \u00a0Also, I’ll be talking about my initial work on terrain, so look forward to that. \u00a0Hopefully it won’t take a month.<\/p>\n","protected":false},"excerpt":{"rendered":"
So, in my last post, I said that my big goal was to thread my renderer and to do a better job of writing it against a public interface so that it could be a stand-alone library. \u00a0Good goals, but now that they’re basically finished I have a lot of \u2026 Continue reading