Tuesday, November 17, 2009

FitzQuake Protocol Is Even More Done!

Just added in the necessary server-side support for > 8192 entities. This was semi-supported previously in that a DirectQ server would just not send the messages, whereas a DirectQ client would just blindly gobble them up.

The major reason why I left this until last was because I needed to do some work on memory allocation in other functions in order to better support the bumped number. Some of the physics code was allocating large arrays of edict_t * and vec3_t of length MAX_EDICTS on the stack, with would have totalled 1MB, so I had to move that to a proper one-time-only dynamic allocation. There was also a static allocation in the world code which I wanted in one of my memory pools in order to give a better reflection of memory used with heap_report. I also needed to tweak the initial sizes of some memory buffers (to cut down on run-time allocations) and bump the MAX_VISEDICTS value client-side.

Getting the protocol itself working had taken priority; I always knew that I was coming back to this stuff but I needed to be certain that everything else would work fine (and coexist peacefully with the other 5 protocols) before doing so.

The remaining item that's not fully supported is the U_LERPFINISH bit. Again, servers don't even send it and clients just blindly gobble it, so it's supported sufficiently to not cause a crash. There's a lot of auxillary code about this that's specific to the FitzQuake interpolation system which would need careful studying and translating into DirectQ-language (I don't just blindly copy 'n' paste other folks code!) before I could tackle it properly. Most likely is there's a one-to-one mapping of almost everything, but I need to be certain.

I think right now that sufficient support to run without crashing is preferable to risking ripping apart some of my alias model drawing architecture (even though I'll be first to admit that there are parts of it that need ripping apart, but let's do it in a careful, controlled and deliberate manner).



Did I say "testing" a while back? I've done the ID1 run with protocol 666 up as far as e4m3 now, and no problems at all have occurred. I've also done some brief WarpSpasm testing. RemakeQuake is still required for .alpha tests, and once I know all the SP stuff is solid I'm going to do a network test (mental note: also need to test SDQuake).

All going well I'm now inclining towards releasing with protocol 666 as the default. There are enough kludges in the BJP protocols (which he admits freely in his comments) to make replacing it a desirable goal, and 666 just fixes these in a fairly elegant manner.

0 comments: