DirectQ Update - 31st May 2011 (Part 2)

The test release is going to happen any day now. I'm thinking that with the extent of changes since the last time around a bump in the version number is now appropriate, so say a big "hello and welcome" to DirectQ 1.8.8.

As I have said, this is going to be a test release. I personally consider it quite stable, and it has circulated privately among a few people at various stages recently, but the real proof doesn't happen until something goes public.

One thing that has been on my mind lately.

The quality of DirectQ's external texture loader is something that I remember mentioning some months ago. This is probably some of the most horrible code I've ever written and it was really brought home to me when I gave a copy of the full code to someone a coupla days ago. It works for sure, but it's messy, it's difficult to follow, it's not always clear what's going on in it, and it's a maintenance nightmare for me.

Adapting it to load .lmp files for Kurok skyboxes was the final straw. I tried once, gave up, and wrote a separate skybox loader for Kurok.

It's now clear that this was a misguided attempt at being all things to all people. The ability to load any texture from any directory, and caching of all external textures when a game directory is loaded - they're nice features for sure, but they're pretty damn marginal.

So this has been on the cards for being ripped apart and replaced with something more sensible for quite some time now, and it's going to happen soon. I won't hold up the release on account of it, but it will happen over the next few weeks.

The way I see the new code working is that it will first attempt to load a texture directly from the path specified, then fall back on /textures if not found. I can cache info about previously found textures for faster loading next time they're needed, but building a cache on startup will go.

Textures in BSPs are the only real special case (there might be one other...) - in this case the search paths are /textures/mapname and /textures. I personally object to /textures/mapname on religious grounds (I think it should use the WAD name specified in worldspawn) but I'm going to be pragmatic and swallow my pride.

The one other special case might be player models. DirectQ doesn't really support external textures on player models owing to the need to support different shirt and pants colours, and that needs to change. I have some ideas on how to do it, one of which is greyscaling the texture and doing some pixel shader magic, but overall compatibility with other engines will be an important factor so I need to study before I commit.

All of this will finally and definitively resolve the ongoing glitches with external textures that have been reported to me, and that are another motivation for tackling this.

And there we have it, one part of the roadmap for the future (no, I haven't forgotten sounds...)