Sunday, June 6, 2010

ProQuake netcode features

In among all of the other small enhancements for 1.8.5, there is going to be a full port of the ProQuake netcode. Whether or not it's going to fully functional is another matter entirely, but it will be there.

The primary problem is that the ProQuake code contains a collection of quite evil hacks piggybacked on top of protocol 15. These involve a concept of "mods", stuffing data into strings, and generally doing a lot of nasty stuff that would have been better implemented in a new protocol. It also puts lots of tentacles out into other parts of the engine, which can frequently be difficult to find.

Porting the code to DirectQ is non-trivial:

  • Convert it to C++ and fix any conversion errors.
  • Rework cvars and cmds to my new systems.
  • Reintegrate any other changes I had made.
  • Ensure that it doesn't break anything else (hint - this is the hard part).
If DirectQ was a simple engine that just supported protocol 15 and didn't need to care about compatibility elsewhere this would be easier, but that's not the case. Code evolves over time, and it's not always as straightforward as one would like to take existing code that has been crafted over a number of years (and was originally written at a time when fiddly stuff like protocol compatibility wasn't cared about as much) from one engine and just drop it into another engine that has a completely different structure in a number of critical areas.

Example: I've already broken the ability of FitzQuake to playback a demo recorded with protocol 666 in DirectQ just as a result of the recent NAT fix. Now this may not be a big deal for somebody who's only concerned with the multiplayer capabilities of DirectQ, but you can bet that it will be a big deal for somebody else somewhere.

Depending on the feature that gets broken it may even be a deal-breaker, something that's enough to prevent somebody from using DirectQ. That puts me in a "damned if I do, damned if I don't" situation. Porting the code is only 20% of the work, finding and fixing all of these little incompatibilities is the other 80%.

When it comes to prioritizing one feature over another, it needs to be realised that the hardcore multiplayer community is only a very small part of the user base. Releases of DirectQ typically get 400-700 downloads; most of those I suspect are just casual gamers, people on a nostalgia trip who fancy a bit of Quake and just put "DirectX Quake" into Google to see what comes out.

I do however also like to give something to the hardcore crew (otherwise I wouldn't be writing about this!), so the whole setup is by way of explanation that while better multiplayer capabilities are coming, you should not expect them to all come at once and in a relatively short timescale.

Stay tuned.

3 comments:

Pottenham said...

When reading about this stuff i´m also very concerned about how all this is going to affect the overall performance of the engine.

Right now Performance and Smoothness of Gameplay is so great in DirectQuake that it is far above everything else available.

I don´t know nothing about how all this stuff works since i´m nothing more than a Quake-Player,but somehow i´m always afraid that more features could result in less performance.

Can you say something about this that can nullify my concerns about this matter?

mhquake said...

Netcode changes aren't going to affect performance at all, don't worry. Quake's network code is INCREDIBLY lightweight as it is, and all of the changes here only affect things that happen either at initial connection to a server or in special multiplayer-only modes (and with the console down, even).

The only real performance bottleneck in any Quake engine is the renderer, and this code has absolutely nothing to do with that.

Even so, I'm always on the lookout for anything that's going to increase performance, so if anything it's going to get even faster as time goes by.

Also, any new graphical effects that I might add and that might slow things down (as extra graphical effects tend to do) will always be disabled by default. My policy is a faithful recreation of the original Quake look, and I'm not going to change that. Not ever.

Pottenham said...

Thanx,that was a really nice explanation.

Now i feel much better about the future of DirectQuake...(gg)