Thursday, November 24, 2011

Fun with Doom 3

Still uncertain if I'm going to actually do anything serious with the Doom 3 source. Been playing around with it a bit more, and I find myself making what are relatively minor changes here and there - there may sometimes be quite a bit of work involved for sure, but nothing is leaping out as a "oh yeah, this would really improve the engine for me" type thing.

In other words, I don't actually have that much that I'd like to change about it; I can play using the original engine just fine and nothing really annoys me or makes me think that it needs fixing.

So far with the source code I've ported it to MSVC 2010 Express; this just involved removing all of the tools code (except for the AAS compiler which it still needs) and getting rid of a few other MFC-dependent things. This hugely reduced both compile times and the executable size to maybe one third of what they were before.

I've also played around a little with texture loading, which seems to be the main bottleneck in map load speeds. There are quite a few CPU-side passes over the texture data, and getting rid of some of them got me maybe 25% faster, but at the expense of less flexibility than the original had. It's OK.

Other stuff I've done is go over one of the shaders (the main Interaction shader), converting a normalization cubemap lookup to shader math (the code was already there but commented out) and getting rid of the red/alpha switch for normal maps (since I also got rid of the CPU-side switch). Nothing dramatic.

Finally I switched the stencil shadowing to use two-sided stencil for a good performance boost. The original also used two-sided however (it was removed from the released source) and with Carmack's Reverse in place it was still faster than even my souped-up version. I did successfully recreate the Reverse (based on a GLIntercept log of the original) but obviously that can't be released (even if I do release anything).

All in all it's looking as though there's not much in the way of what I consider fun in this code. With Quake 1 it was cool as there was just so much to fix, to tidy up, to rearchitect, to make better. Quake II less so; I do dabble from time to time alright. Subsequent code releases - it's just not there (that's why I've never done - for example - a Q3A project, although converting it's fixed-func "shaders" to real shaders seems like a fun project I may try sometime).

Glacial compile and load times make the turnaround time quite frustrating too, and the ultra-sluggish performance of MSVC 2010 isn't helping matters.

I'll probably play with it a little more just to see if anything cool comes out, but right now it's looking doubtful. Doom 3 is coming across more as a source to mine for ideas that I can use elsewhere rather than something I'd consider doing a serious project with at the moment.

3 comments:

Anarchist Muse said...

please, please release a version compatible with express. I have windows, and I lack the funds for the commercial software. also, that shader stuff looks sweet. also, have you enabled bump maps for visual depth as well as shadows?

Anonymous said...

"I did successfully recreate the Reverse (based on a GLIntercept log of the original) but obviously that can't be released"

99.9% of the world doesn't care about patents in one country. Just release it and get over it.

Anonymous said...

Areas of interest:

Can a deferred renderer in OpenGL flatten the cost of overlapping lights as was shown in Direct3D (Wolfenstein) or is that a pitfall for OpenGL (see BRINK's poor performance).

What about moving the Shadow Volume calculation entirely to the GPU? Would that help for pathological shadow casting scenes on CPU limited systems?

How about implementing new light volume projection types:

Cubemap lights
Volume Light Maps

http://www.humus.name/index.php?page=3D&ID=47