Updates - December 29th 2011

The RMQ demo should be coming any day now; engine work is complete barring any last minute emergency bugfixes and content is coming together very well.

We won't be releasing source code with the main demo release, but I will be putting together a "devkit" release (separate from, but hopefully to coincide with, the main release) containing all engine and tools source, a few notes on some technical things, and so on. It's not a real devkit as it will be only focussing on engine and tools, but it will hopefully form the start of one that can grow into something useful.

One other thing that I might do sometime is a quick port of Fitz 0.85 to support the bare minimum required RMQ features. The intention here is twofold. Firstly it provides an option for those who don't want to, or can't, use the RMQ engine. Secondly, it provides a reference implementation of what is actually required to add support to an engine for anyone else who may want to do so - they can just examine the diffs and get the necessary info. This second reason is quite important, because the RMQ engine source itself has changed so radically from it's initial baseline that it would probably be a nightmare to figure out what's needed.

I'm not certain yet if this will be included in the devkit; it may be worth delaying the devkit for just in order to get everything together, but if it ends up delaying too long it will likely come a short while later.

This all indicates that the RMQ engine itself has grown beyond it's initial goals of to be that reference implementation and then become obsolete. What's happened there is that as content and requirements have evolved, the requirements of the engine to actually be able to run the stuff have also evolved, and are now more than the original intention of "QuakeSpasm with some extra - and easily identifiable - stuff bolted on". It may also be symptomatic of what happens when an engine coder works closely with a mapping/modding team and each starts feeding off the other. Something to ponder on another time, maybe.

Anyway, DirectQ is going to pick up RMQ support as well at some point in time, but that's lower priority at the moment. Most likely it will happen during January, at which stage I'll do another release of that.

My current work involves beating on the original "D3DQuake" release I made 3 years ago (what became DirectQ, and before I changed the name owing to there being another "D3DQuake" from some time before it). I'm really just knocking it's renderer into some kind of civilized shape so that I can use it as a platform for some upcoming experimental work.

I'm going to have a pop at doing a deferred renderer.

I've been studying white papers, presentations and articles a good deal recently, and have most of the theory down solid, so now I want to bash out something that works and get an idea of how viable it is (or isn't) for use in one of the main codebases.

This plays into an ongoing request for better resolution lighting in RMQ, and plays off an older real-time-lit MHQuake I made (but never released) ages ago. Of course there are tradeoffs involved - bumping the hardware requirements being a major one - but I think it's worth exploring to see how things work out. At the very least I want to be in a position where I can say "tried it, here's what worked, here's what didn't work, here are the tradeoffs, what's our decision?"

I've chosen this codebase because it's incredibly simple - no translucent stuff, no special cases for mod support, just the most basic Quake rendering - plus it's D3D, which is easier for writing experimental stuff in (at the very least if something goes wrong I know it's got a much higher chance of being in my code than of being a stupid driver bug).

DirectQ 1.8.8 Patch 2 Release is OUT!

Download from here.

This release focusses on code quality and bug fixes rather than on adding any radical new features; if the previous release of DirectQ worked fine for you there is probably no need to download this one.

It contains the beginnings of an "enhanced" particles system, but that's quite unfinished. You can turn it on and use it if you wish, but be aware that what you're seeing is NOT a finished or stable work.

Happy shambler hunting.

Updates - December 13th 2011

I've been quiet for a while but not idle. A good chunk of recent time is going into tuning the RMQ engine for the upcoming planned demo release, and things are quite exciting. It's fair to say that I'm really enjoying what I'm currently doing with it, and that it's shaping up to be a strange and interesting beast.

This is likely to continue until the demo is released, and I expect probably for a short while after as bugs shake out. While we do have great coverage of platforms and build targets, we obviously don't have everything, and the state of drivers, PC variations, etc means that there is almost certainly bound to be some follow-on required.

Consider that fair warning. ;) But at the same time - don't let it put anyone off, as the engine does get constant testing and constant use on AMD, NVIDIA and Intel graphics, Linux, Windows XP and Windows 7 operating systems, and is compiled with MSVC, Code::Blocks and makefiles. That's pretty good coverage and sufficient, I feel, to expose any howlers. Remaining bugs and incompatibilities will be quite esoteric in nature.

About the engine itself, it's also fair to warn that it's not really a general-purpose Quake engine any more, and it shouldn't be approached as if it were one. There are pros and cons to both approaches here, but ultimately it comes down to what is going to be able to run RMQ content the best (if at all!)

This means accepting a side of various tradeoffs that may not be totally suitable for use in a general purpose Quake engine. So, GPU lightmaps were one I have mentioned earlier, and the reality is that for general purpose Quake use these are going to be slower than regular lightmaps. The other side of that tradeoff however is that we get to have scenes where every single surface has an animated lightstyle on it, and where 30+ dynamic lights are going off in addition to that. With an engine programmed with general purpose use in mind, we would be talking about single-digit framerates there.

Another such tradeoff that I expect will raise a few questions (or complaints) is that of the hardware requirements. RMQ is going to absolutely require shaders and vertex buffers (as well as up to 5 simultaneous textures), and there is no fallback path for when they are not available. There are various reasons for that, one of them being to enable GPU lightmaps, another being for higher quality water and sky, and another being for general performance considerations.

The harsh reality here is that RMQ content is quite complex. There is stuff here that has never been seen in Quake before, a level of detail and complexity that is genuinely new (and that approaches or even exceeds some recent triple-A titles). Even notorious "engine breaker" maps pale into insignificance compared to some of what has been done. What that means is that older hardware will simply not have the horsepower to run this content; triangle throughput, fillrate, etc will just not be there.

So a good rule of thumb is: "if you can run Doom 3 (using the ARB2 path), you should be able to run RMQ". Our use of OpenGL extensions is much the same (and we're not really shooting for any higher), our shaders are simpler, but our world geometry can be more complex (and, using Quake formats, isn't really set up for the most efficient rendering anyway).

That's going to annoy some people who may have been looking forward to this, and that's accepted, but it's a case where it's just not possible to balance everything, so something has to give way. The available somethings were the ability of creators to realize their visions, the ability of the engine to be able to run this stuff, my own sanity, or the hardware requirements. In the end I think it was the right decision.