With the Doom 3 source release hopefully coming closer, I've thought about it a little more and it's now looking likely that I will be doing something with the code. I haven't yet decided if this will be for public release or private use but it may make for some interesting discussion. There are a few things I want to try out in a more modern rendering environment than Quake allows, and Doom 3 seems like it might provide a nice platform (if nothing else the amount of work required to get it up to basic spec should be lessened).
Assuming that I do make the final decision, here's how I see it working out.
It will be Direct 3D. I haven't yet decided whether the version will be 9 or 11, as each has factors that would recommend it over the other (I know 9 better but there are some things in 11 that I'd like to play with).
Line for equivalent line Direct3D has always come out about 25% or so faster than OpenGL in any work I've ever done, so that should be good for integrated graphics chips (I have one that I played Doom 3 on once - it was a horrible experience).
Doom 3 uses OpenGL shaders, but the version it uses is the older ARB Assembly shading language. It should be relatively easy to write a simple parser to convert these to HLSL (the resulting code won't be pretty but it should work OK) and that's the first thing I want to try out. That necessarily limits use of the result to the original game (I can't recall what RoE used) but that's OK - it won't be a design goal to be all things to all people.
Because of the technology level it was aimed at it uses multiple passes to draw lit surfaces. There's one potental avenue for optimization - seeing how many of these we can collapse into a single pass. This should be easier if I normalize in a shader instead of using a cubemap, so I might also just hard-code the default game shaders into the engine. That rules out the shader parser/converter of course, so I'll probably end up flipping a coin on this one.
From my explorations so far of GL Intercept logs and shader code included with the game it seems as though there is a lot of work being done on the CPU that could be usefully moved to the GPU.
I want to explore some shadow mapping and try get soft shadows into the engine - it's always been something of an ugly visual clash that some of the pre-baked shadows are soft-edged whereas the dynamic stencil shadows are hard-edged (which I loathe to begin with). Don't know how that one will turn out, and there are obvious performance tradeoffs to consider. I've never really done any serious work with shadows and it would be nice to get something good for Quake out of that too.
Seeing if anything can be done to improve load times is interesting too. They're just too long. I know that DDS textures are available with the game, and making some creative use of these could be fun.
Some general visual improvements and nips and tucks on things that annoy me about the game seem in order. Ideas for these will probably evolve organically.
So that's a bunch of stuff that seems cool and fun to explore, but no promises, no due dates, and it will have to take a lower priority to other work.
This should be in 10-foot high letters on everyone's wall ("anatomy of a mis-feature"):
...Ah well, someone might use the feature for something, and it's already finished, so no harm done, right? Wrong. ..... The addition of a feature early on caused other (more important) features to not be developed. ..... The important point is that the cost of adding a feature isn't just the time it takes to code it. The cost also includes the addition of an obstacle to future expansion.It's also the reason why I sometimes remove features from DirectQ, or sometimes resist the addition of new ones.
Sure, any given feature list can be implemented, given enough coding time. But in addition to coming out late, you will usually wind up with a codebase that is so fragile that new ideas that should be dead-simple wind up taking longer and longer to work into the tangled existing web.
The trick is to pick the features that don't fight each other. The problem is that the feature that you pass on will always be SOMEONE's pet feature, and they will think you are cruel and uncaring, and say nasty things about you.