Wednesday, January 14, 2009

Towards an unlimited capacity engine...

I'll start by qualifying "unlimited" - the amount of RAM, video RAM, CPU and GPU performance, highest number you can store in an int, and so on will always be limits.

Anyway, I had done a lot of work on removing hard limits in the GL engine, and some of that is now starting to come across to DirectQ. The eventual goal is going to be having the sole limit being what your PC can handle, and this won't happen in the course of 1 or even 2, 3 or 4 releases, but I will aim to get as close to it as possible, and closer each time I release.

In some cases I have retained hard limits; for example I support up to 8192 loaded models, and no more. Memory efficiency is a consideration, and in cases like this I use an array of pointers rather than an array of structs. Sometimes I pre-allocate a fixed number (something along the lines of what the old limit was) and expand dynamically (either by 1 or by another - lower - fixed number), in others I just go dynamic from the outset. Sometimes it's a linked list. It's horses for courses.

Doing it wrong is easy - just bump up the #define'd maxes and watch your memory utilisation balloon. Doing it right requires careful consideration of every single case. Sometimes a bump of the defined max is even the best solution - why bother putting a lot of effort into temp entities when they're only used for beams?

The big killer in Quake is Protocol 15. I seriously wish that everybody could just simply agree to move to a new higher-limits protocol which could be quickly and cleanly implemented (bump the maxes, switch from bytes to shorts, etc). In the absence of that you have to be very very careful that whatever you do doesn't break protocol 15. There are some small areas for optimisation - doing comparisons of origin and angles based on what will actually be sent rather than the raw float values is one. There are other areas where you're in a corner - model and sound numbers are transmitted as bytes, so any increase beyond 256 is a breaking change in and of itself.

I think it's fair to say that in 2009 the really ambitious mapping action is in the single player game. Deathmatch will always be cool, but it's more pure (and purist), and protocol restrictions make sense. Single player lets mappers imaginations stretch. Colossal maps with thousands of entities, ooooh yeah.

One way I'm thinking of going with this is just bypassing the protocol altogether and writing/reading the data directly. When the client and server reside on the same machine (and in the same executable instance) there is scope for all kinds of clever trickery. I'm not willing to expend the time and effort on a new custom network protocol; there are too many already and the world doesn't need another, especially in what is more of a niche engine that at most 2 or 3 people will ever use for net play.

An alternative is to just rip the BJP protocols; not reinventing the wheel makes sense here, and will create a really nice situation where my engine is protocol-compatible with another one out there, specifically the one that mappers prefer to use. I'm already higher-capacity (but with lower memory usage) in a lot of areas than that engine though, so I may start hitting limits on even those protocols!

Busy busy, as always.

0 comments: