Sunday, December 27, 2009

DirectQ 1.8 Update

It's been a short while since I posted a solid update, rather than just providing info on what I'm currently working on, so here it is. I'm dropping the bullet-point list format I usually use for these things as it tends to repeat itself over time.

The 2 main things I had in mind for 1.8 were the restructured render and alias model cleanup. Of these, alias model cleanup is done and the restructured render is still ongoing.

I've posted before on alias model cleanup, but in summary it rearranges the in-memory alias model format a good deal to enable alias models to be stored more efficiently and loaded and rendered much faster. All alias models can now be rendered with a single API call which gives better primitive batching and follows the general principle of doing very few big things being more performant that doing lots of small things (the same applies to memory allocations, disk reads and writes and anything else that interfaces with hardware). As a bonus the code is a lot cleaner and nicer to work with too.

The restructured render is close to being done as well. All that really remains is adding support for r_wateralpha modes. There is a slight dilemma here that ties into my alpha model support. If a brush entity that contains liquid surfs has an alpha attribute set, which should take precedence? The value of r_wateralpha or the alpha attribute? The problem here is that there are some mods that rely on it one way and some that rely on it the other. My instinct is to follow what GLQuake did and just set liquid surf alpha based on the value of r_wateralpha (following the principle of least surprise towards the player, as opposed to what the modder might want, which - as I've mentioned - can be mutually incompatible between different mods).

This renderer is also optimized a LOT more highly than before, allowing in many cases an entire texture chain to be submitted in a single API call (it might be more if the lightmap changes within a texture chain). Again, there are performance improvements to be had from better primitive batching here, but they're not as dramatic as I got for alias models (mostly because alias models had more room for improvement, but also because surfs sharing the same texture can't be batched as efficiently owing to lightmap changes; I do alloc lightmaps on pre-sorted surfs but it can still happen).

When this is done - or maybe before - I'm going to work on optimizing brush models some more. Brush models are currently horrible in Quake as there are two different types and they - in some cases - need different handling. The objective is to put the engine in a position where brushmodels can also be rendered in as few API calls as possible.

I wish I could say that this new renderer is as clean as the alias model setup, but it's not. This is really a legacy of Quake having so many different formats for everything (whereas with alias models you're just dealing with one format). Anything I can do to tidy it up will be done, and I suspect that even when it's "done" it won't be "finished".

The upshot of these improvements is that scenes in currently released mods that used to drag this engine (and most other engines) to a standstill can now run a lot more smoothly. The rain in the Remake Quake summer SP demo is one example (FPS used to drop to below 20, it's now quite steady at 50 to 60). The open area in CTF1RQ is another; again something that used to drop to below 20 FPS is steady at about 35 (this will increase when I do brush model optimization).

There are some other improvements coming in aside from these two big ones. Baker mentioned that I didn't support "connect host:port" so now I do. Recording demos while a server is running is another one that will happen (although I suspect that there are reasons why this was removed from ID Quake, and I'd love to know what they were). sv_progs support is done, and most of the handling of the progs.dat file has been moved over to a C++ class (in prep for CSQC, although that won't happen with 1.8 - but it's coming). Some general bugfixes, code tidy-ups, removal and clean-up of some old code that dates back to 1.0 but had never been touched since, and so on.

All in all this is shaping up to be a good one.

2 comments:

=peg= said...

Sounds very promising, can't wait to try it out ;)

Chip said...

Ontopic: Great! Open spaces and more optimizations.

Offtopic: I wish there was a MH for each of my favourite games.