Here's what I'm currently working on and/or planning:
- Porting my menu framework from the GL engine. This is going well enough; I have most of the basic functionality across, and some of the actual menus implemented in it. It's basically a set of C++ classes that function as a control library for all common Quake menu items, which can have custom events hooked in as well as default handling for sliders, toggles, commands, submenus, etc. I'm taking the opportunity to clean up and streamline the class structure while I'm porting, so it's going a bit slower than simple copy and paste.
- Working heavily on input code. I've completely rewritten the mouse DirecdtInput code to be more stable and predictable, and have removed the old software support. I'll be doing the same with keyboards and other controllers (most of joysticks are already written). I've also got full support for the XBox 360 controller using XInput. See my previous posts on input for more.
- Reworking parts of the surface refresh. I currently have all surfs in a single VertexBuffer which I lock and update each frame where required, but this is far from an optimal approach. I'm going to be moving towards each model having it's own VertexBuffer, which can be then more easily transformed without having to touch any verts. That brings me to the next part, which is...
- Designing a new alias model in-memory representation. Actually the design is already done, and some proof-of-concept code has been written. This is necessary because the old in-memory representation (order, poseverts, commands, etc) may have been fine for single passes and immediate mode drawing, and was definitely memory-efficient, but it's horrible to use for more modern techniques (this would be true of OpenGL VBOs as well).
Until then, I might update the previous release with some critical bugfixes that have made it into this version. Current bugs (that I'm aware of) and their status are:
- Video menu crashes.
This was caused by me overflowing an array; I basically just reused the old GLQuake video menu code but wrote the Direct3D modes into the menu, without bounds-checking the items array. Basic mistake.
- Team colors are greyscale.
Draw_Fill was reading it's palette colours incorrectly; this has been updated to read correctly and also to standardise on use of d_8to24table rather than host_basepal.
- Crashes on changelevel in multiplayer.
This is caused by the PF_VarString function emitting the "
exited the level" text, and seems to only happen with executables built under Visual C++ 2005 or 2008 (I built on 2005). I know that Microsoft have made changes under the bonnet to the CRT in these versions, some of which are pretty drastic (such as removing single-threaded support), and this is where I'm pointing the finger. Unfortunately I'm not able to reproduce it, so it seems to have been resolved by something on my machine. Currently debating options for fixing this, but the most likely approach will be a reversion to Visual Studio 2003. Alt-Tab Crash.
This is caused by me forgetting to remove a few ChangeDisplaySettings calls. There's a related bug where Alt-Tab back to a fullscreen mode doesn't restore the screen properly at all, so for now the workaround is not to Alt-Tab.
- Sky and water surfaces in brush models not being rendered.
This one is currently under consideration. It's important to have it for mod support (it's possible to have these on even an ammo box in stock GLQuake!), but it will complicate the surface refresh quite a bit. The most likely approach will involve transforming them in software at runtime and adding them to texturechains, but I'm not sure how to best approach instanced models (i.e. ammo boxes). I can definitely see why ID moved away from using BSPs for these in subsequent engines. In other words, I don't see it being done for instanced models any time soon, but it will be done for inline models.
The last remaining item is the matter of the name. It has rightly been pointed out to me that there is already a D3DQuake, and although my version might be viewed as more entitled to the name, on account of being active and a native port, that version correctly has the right of precedence. Inside3D seem to have dubbed it DirectQ, which is fine by me, if a little bland. I want to move away from "MHQuake"; there's too many engines with that name already, and I've been guilty of confusing matters by not really differentiating as well as I should between my own releases. XQuake would also be appropriate, but that's already taken too. The interim release will likely be "DirectQ 1.1", but the next full release may be something entirely different.