Sunday, January 16, 2011

DirectQ Update - 16th January 2011

First update for a good while because I've been sick - swine flu is a total pain, but I reckon if I'm going to get it I'm better off getting it now rather than just before I'm due to go on holiday or something.

Anyway, while the rest of the RMQ team are working on the point release, and now that I've got pretty much all of the engine requirements for that done, I'm going to be picking up some slack with DirectQ. Obviously if an RMQ requirement comes up it'll need to take priority, but for now I'm taking a change of scenery.

This will also give me the opportunity to bring on some RMQ features into DirectQ, which is quite cool. These will include the long-awaited FRIK_FILE.

Hopefully it'll finally coalesce into Release 1.8.7; this has been some time coming, and was delayed towards the end of last year so that I could focus on RMQ (among other things) as well as nail down the final feature set that I need to bring on.

Some other changes worth noting:

  • I've re-enabled non-power-of-2 texture support.  This was present in an older version, but used a more compatible (but less functional) "conditional" support, whereby non-power-of-2 textures couldn't be mipmapped and had other restrictions.   This version uses the less compatible version, but only where supported by your hardware.  I also had this in the released RMQ engine, but it caused trouble with OpenGL drivers (and is the cause of the "white textures" bug some folks got).  D3D is stricter about hardware support of features so it's safe to do in DirectQ.
  • I'm going to bite the bullet and lock SP games (and MP games if you're running a listen server locally) to a max of 72 FPS.  This is something I feel is necessary owing to the number of MP players who are used to running with a higher maxfps doing the same in SP games and then complaining about weird physics.  It won't affect running with non-local servers, i.e. dedicated servers or someone else's listen server.  I'm also going to lock it if recording a demo (for the speedrunning crew).
  • Mouse input has been totally overhauled (again!) and is now considerably smoother.
  • I'm reverting the default protocol to 666 (FitzQuake).  The previous protocol experiments were fun for sure, but they did cause some incompatibilities, particularly with demos.  The RMQ protocol will eventually become the new default, but that's nowehere near nailed down yet, so until then I've come to believe that it's not really suitable for use in a more general purpose engine.
Fog is still an item of some concern for me.  I've outlined the problems I have before, but - in summary - the main ones are how do you balance what the mapper wants with what the player wants (or even needs,  owing to hardware issues) and how do you reasonably handle visual inconsistencies (such as if you have blue fog in the world but you dive into lava) in a way that keeps everyone happy?  I know what the "Right Thing" in my own mind is, but the difficulty here is that it does clash a little with what some of the more proscriptive members of the mapping community would feel the "Right Thing" is.

The other main thing I was talking about towards the end of last year was D3D11.  OK, sooner or later I am definitely going to make the move; that's a given, because hardware support for the older D3D9 features is eventually going to die out, and there will come a time where everybody (or at least everybody who would use DirectQ) is on a D3D11-capable platform.  I'm still waiting for the tipping point to come, but I suspect that it will happen (or start to happen) over the next year or two.  Until then, my previous talk of going to D3D11 for 1.9 was a little premature.  I may yet do a Quake II port as a learning experience though.

4 comments:

tehSandwich said...

tehSandwich here and I have to say that I prefer using DirectQ over most other Quake engines. Not for the Direct3D stuff but for the actual usability of the menus. I have only a single problem with it and it's about how you can't use USB headsets. It will try to use my soundcard instead of it for some reason. Will that be fixed for the next release?

mhquake said...

I didn't know about that. I don't have a USB headset to test with, but I do know why it's happening - by default DirectSound will use the primary sound device on your machine, which I guess is configured to be your soundcard.

It shouldn't be too difficult to change it to allow you to select whichever sound device you wish; I've already got most of the code needed for that. This is a good feature request; thanks.

Thanks also for your kind words about the menus. I put a lot of work into them and it's nice to see someone getting benefit from them.

Anonymous said...

Speaking of DirectSound, what are your thoughts on XAudio2?

mhquake said...

I've read the documentation and specs and I'm not too impressed by it. It's very DirectSound-like, and doesn't do enough to resolve some of the problems and difficulties with using DirectSound.

If I was going to change the sound code I'd be more likely to switch to OpenAL or SDL than XAudio.