Monday, November 2, 2009

Fun with Multithreading and Overbrights

Two main topics today.


I've posted before on the difficulties I've had with the multithreaded C runtime in Visual Studio 2008, and recently I've been working on a multithreaded .NET application (nothing to do with Quake, this is my day job). Multicore/multithreaded environments and applications are no longer just the future, they are the now, and it's something that everyone has to adapt to. The big problem though is that most threading APIs (or at least the ones I've used) are just horrible. I've written multithreaded code before in C/C++ and I was astonished by the ancient terminology in use, by the awkwardness of the API, and by all the bear traps that exist that you need to avoid. It's quite amazing that the .NET System.Threading namespace doesn't really attempt to hide any of this.

There's been a lot of talk about potential things that could definitively swing the desktop market away from Windows and to Linux, but in my opinion the one crucial and critical factor would be the provision of a good API that makes it easy and painless to write safe and performant multithreaded code. Because whichever OS gets that API first will be the one that the besp apps are going to become available for, and with the shortest turnaround time.
On to DirectQ.

From the start, DirectQ has supported and actually enforced overbright lighting. Have a read here for more info on this feature. One consequence however is that some maps - in particular those made by mappers who are slaves to the great god GLQuake - are just not made with overbright lighting in mind. I had been fairly bullish in my attitude towards this: "it's an original and intended software Quake feature, it's the way Quake is meant to look, and tough luck, the mappers should have gotten it right". However, this attitude means that players suffer as maps that are lit without overbrights in mind can look at best weird and at worst bad in an engine that supports overbrights. I've relaxed my opinion on this, and will now be providing the ability to disable overbrights via an r_overbright cvar. The default value will be 1 (overbrights enabled) but you will be able to switch them off any time you like, so if you're playing a map that looks bad (or if you just prefer the look of Quake without them) you can set it to 0, and the change will take effect immediately without needing to reload your map.

One other unintended feature of DirectQ overbright support is that my fullbright colours have always been oversaturated. With hindsight I should have been aware of this from the start, but I only really noticed it while toggling between different values of r_overbright. This is something else that is going to be fixed.

0 comments: