Onze vriend John heeft de moeite genomen om z'n .plan te updaten met bruikbare info over QIII Arena:
A while ago I had changed Q3 so that the number of fractional bits was a compile time option, which allowed you to trade off fine grain precision for larger size. I was considering automatically optimizing this for each level based on its size, but it still didn't feel like a great solution.
Another aspect of the problem that wasn't visible to the public was that the fractional quantization of position could cause the position to actually be inside a nearby solid when used for client side prediction. The code had to check for this and try to correct the situation by jittering the position in each of the possible directions it might have been truncated from. This is a potential issue whenever there is any loss of precision whatsoever in the server to client communication.
The obvious solution is to just send the full floating point value for positions, but I resisted that because the majority of our network traffic is positional updates, and I didn't want to bloat it. There have been other bandwidth savings in Q3, and LANs and LPB connections are also relevent, so I was constantly evaluating the tradeoff.
Dealing with four or five players in view isn't a real problem. The big bandwidth issues arrive when multiple players start unloading with rapid fire weapons. (as an aside, I tried making 5hz fire weapons for Q3 to save bandwidth, but no matter how much damage they did, 5hz fire rates just seemed to feel slow and weak...)
Sure...en voor wie niet helemaal begrijpt waar meneer Carmack hierboven allemaal over aan het lullen is, heeft Voodoo Extreme een handig vertaling:
"Dude, I was hax0ring with this Quake3 code and stuff and I made it so maps can be totally bigger dude, CRAZY! Then I was looking at these rockets things, and I thought, hey.. I can go buck wild and make the network code cooler for this! Let me try a few things. Nope, that didnt work.. Oh maybe this will though. OMG! I like it!"
Lees meer over