It’s been over a month but there hasn’t been much to say about the features I’ve been working on, they’re necessary rather than exciting. Here’s what I’ve been up to:
On the Visibly Improving (i.e. D3D 9) branch
Shadows! The sun now casts shadows on everything. For now, they’re a fairly standard implementation of split-frustum (or cascaded) shadow maps, which is to say that I render three or four depth-maps from the sun’s perspective, all the same resolution but with each map containing a larger and more distant chunk of the main camera’s view frustum. It’s looking decent but has a few downsides:
- You have to draw the world four extra times.
- Each map has to be able to fit the entire view frustum inside it even at its most awkward orientation, but to avoid flickering as the camera moves, it can’t shrink to make use of the wasted pixels when the camera’s at a more convenient rotation.
- If you have anything far away (like the hills) they don’t get a shadow.
- If you have anything with giant polygons (like going near the hills) you get hideous artifacts that totally ruin the illusion of a smooth surface.
On the Everything Is Broken (i.e. D3D 11) branch
I’ve taken a break from trying to get the engine itself to behave, to help brace for the scary but ultimately character building experience of losing D3DX (and its various resource loading capabilities) in the latest versions of D3D, which has forced me to actually Do Resources Right. My previous system (aka Doing Resources Wrong) worked pretty simply: a material file said which textures I have, then I let D3DX load them with default settings. I stored them in a separate resource directory rather than where the game looks for them, but all my “build” did was copy a list of needed files into the right place. This meant that anything I haven’t saved in a D3D friendly format had to be converted (into an arbitrarily chosen format), and given an arbitrary number of mip levels according to an arbitrary filtering algorithm. If I wanted to convert a height map into a normal map, I had to do it using an image editor plugin by hand any time the height map changed, which rather defeats the point of having a resource pipeline.
Now, suddenly, standard support for non-D3D image formats is gone, so I’ve written a tool to do the conversion up front. Since I’m now Doing Resources Right, the new material file format has to actually say what format it wants to output in, whether its input is sRGB or linear colour, how many mip levels it expects me to produce, etc. The textures are processed and all the information for loading them is saved in a more engine-friendly binary format.
What’s nice is that as I continue to Do Resources Right, I can start adding fields to the input material file that say things like “here are six images, make them into a cube texture” or “here are low- and high- poly versions of the same model, bake the high detail into a normal map”. Meanwhile, the game itself won’t have to know anything about how it got its inputs and I won’t have to remember to do esoteric stuff in art tools. None of this is in any way ground-breaking, and I’m kicking myself for not having put in this work earlier.