Ryan Desgroseilliers wrote:
I think a great many people seem to be ignoring his actual
question/issue in order to add completely irrelevant details and
digressions, or to defend Valve's coding practices against some
perceived criticism that just isn't there. The suggestion that *every*
use of Vector::Normalize() was a reassignment of the result back to
the original vector is silly; just do a search of the 2.3 SDK and
you'll find plenty of counter-examples.
The member function from HL1 he's referring to, Vector::Normalize(),
was a simple inline constant member function that has *no effect* on
the vector it is called with. It has nothing to do with code speed and
everything to do with reducing the quantity of code verbiage that
needed to be written for quick, one-off uses of normalized vectors.
Basically, it's a question of:
Vector vecTempNormalized = vecUseful;
VectorNormalize(vecTempNormalized); // can also use NormalizeInPlace()
FunctionUsingNormalVector(vecTempNormalized, [...]);
// Additional code requiring vecUseful in its original form
versus
FunctionUsingNormalVector(vecUseful->Normalize(), [...]);
// Additional code requiring vecUseful in its original form
With regards to speed, I did a quick test run using two stripped-down
vector classes, with allocation being done before starting the time
count and the test vector being kept constant to avoid the square-root
causing a bias. The net result was that the global function method was
only about 7% faster after 50000000 loops of each. Given the amount of
other stuff happening in the game, and the fact that the engine can
use whatever method it wants, I suspect that the occasional call to a
member function of this kind for expediency from the game DLL would
have an utterly negligible effect on game performance.
The advantage increases to about 11% if the vector is reassigned to
itself instead of a separate variable, but [a] you can still (and
should!) use NormalizeInPlace() for that, and [b] once again, it is
overwhelmed by the amount of other stuff going on in the game. If you
consider the direct passing as a function argument (i.e. the example I
suggested above), the member function method is actually about 22%
faster, and a bit lighter on memory.
Adding a nonvirtual Normalize() function to the Vector class should
not affect the vtables -- the function will have a valid address
defined for any pointer to the class regardless of the object it
points to (you can even call the function from a NULL pointer, with
predictably undefined results), and its presence should not require
additional storage. So yes, as Tony said you can probably add it
without any problems.
====================
Ryan Desgroseilliers
Project Director, Half-Life: Nightwatch
WOW!
Finally, somebody who understands me! A thoughtful, intelligent,
relevant and useful response! I never thought one of those would appear
from this thread.
This is all good to know. I believed it's possible to add a Normalize()
when Tony said it, but was too upset with all the cruft to say so. I'll
be sure to put this information to good use.
Still, none of this answers the original question about why the method
was removed in the first place, but I suppose that's all academic now.
It was probably removed by a misinformed Valve employee years ago who
doesn't remember doing it. Either way, adding it back is no big problem.
Thanks, Tony and Ryan.
--
Jorge "Vino" Rodriguez
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
