Monday, February 21, 2011

DirectQ Update - 21st February 2011

I've been undoing a lot of the experimental work I did on DirectQ late last year. At that time I was using it as a testbed for stuff that was potentially going to be in RMQ, and unfortunately I had made a slight mess in places. While it didn't actually have any negative effect, it was very untidy and would have caused trouble in the future; better to get rid of it now.

The primary changes are that the timers have gone back to floating point in the majority of places, and protocol support has been revised somewhat. I'll deal with these in turn.

Reverting the timers to floating point was an easy change to decide on; after all, QC uses floating point so at some point in time they have to be converted over. This was really the deciding factor, but a secondary one was that network time transmission (svc_time messages) also uses floating point. Changing that is a protocol change, and then we start digging up a whole heap of dependencies.

The main host still uses integer milliseconds (because it's the only way to get rock-solid timing on Windows), and time advancement and differences there are still measured in integer milliseconds, but these are converted to floating point as soon as it's been decided that we're going to run a frame.

This keeps the code cleaner but still keeps the timer steady: any floating point drift in one frame will be cancelled out by the next.

Protocol changes might be a little controversial, but I believe that it's the best decision in the longer term. Up to now DirectQ has supported a whole mess of different protocols, including the original, Fitz, the BJP protocols, an experimental enhancement of one of the BJP protocols I made, and an experimental RMQ protocol (which had become different from the real RMQ protocol, and which - unfortunately - I had set as the default in a released version - ow ow ow).

This created a hugely complex architecture around messaging, which has now been completely gutted. Protocol selection has been reduced to the original, Fitz or the real RMQ protocol. I'm not going to maintain compatibility with the others going forward.

The only impact that this has on released content is that the WarpSpasm demos will no longer play. I don't think that this is a big enough deal to worry over. However, demos recorded in previous versions of DirectQ will also no longer play, and some of these were circulated on Func. This might cause some pain in the shorter term, but I believe that it's best to do it now and get it over with rather than have to maintain the wrong RMQ protocol in addition to the real one going forward.

Speaking of the RMQ protocol, I do believe that it's now been finalised and that the upcoming release of DirectQ will be the first unveiling of the final version. This will be a Good Thing as it will let everyone see it well in advance, and those who want to implement it can do so.

This protocol is functionally identical to Fitz 666 with the exception of an additional MSG_WriteLong (on the server) and MSG_ReadLong (on the client) following the version in an svc_serverinfo message. If this value is 0 then the protocol is otherwise identical to Fitz; if it's non-zero then it's a set of flags that define what's different. Currently defined flags are:

#define PRFL_SHORTANGLE  (1 << 1)
#define PRFL_FLOATANGLE  (1 << 2)
#define PRFL_24BITCOORD  (1 << 3)
#define PRFL_FLOATCOORD  (1 << 4)
#define PRFL_EDICTSCALE  (1 << 5)
#define PRFL_MOREFLAGS   (1 << 31)
Doing it this way, all future revisions of the protocol can maintain full compatibility with each other and nothing should break any more.

That's about that for now; still on track for the Beta 1.8.7 release later on this week.

0 comments: