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
--
[ Picked text/plain from multipart/alternative ]
Oh I see what Vino was getting at now. Indeed, that is odd. Especially with
Ryans tests.
On 4/8/06, Jorge Rodriguez [EMAIL PROTECTED] wrote:
Ryan Desgroseilliers wrote:
I think a great many people seem to be ignoring his actual
.
--
-- omega
Heroes of Excelsior
http://www.heroesofexcelsior.com
Blackened Interactive
http://www.blackened-interactive.com
-Original Message-
From: Jorge Rodriguez [mailto:[EMAIL PROTECTED]
Sent: April 8, 2006 3:35 AM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] Why
persist.
One of the things I added back into vector a while back was copying back and
forth between float pointers.
-Original Message-
From: Tony omega Sergi [mailto:[EMAIL PROTECTED]
Sent: March 24, 2006 8:08 AM
To: hlcoders@list.valvesoftware.com
Subject: RE: [hlcoders] Why
--
[ Picked text/plain from multipart/alternative ]
Probably because of the global function pointer that is used by
VectorNormalize to use the best performance method available (depending on
CPU), should not be used within a class. That would, I consider, be bad
practice.
On 3/24/06, Jorge
= Vector(x,y,z);
blah-NormalizeInPlace();
-Original Message-
From: Jorge Rodriguez [mailto:[EMAIL PROTECTED]
Sent: March 23, 2006 12:58 PM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] Why VectorNormalize?
Tei wrote:
Theres the C version:
float VectorNormalize (vec3_t v
and
forth between float pointers.
-Original Message-
From: Tony omega Sergi [mailto:[EMAIL PROTECTED]
Sent: March 24, 2006 8:08 AM
To: hlcoders@list.valvesoftware.com
Subject: RE: [hlcoders] Why VectorNormalize?
Looking back at all the posts, the only thing I can glean is simply
Theres the C version:
float VectorNormalize (vec3_t v){
float length, ilength;
length = v[0]*v[0] + v[1]*v[1] + v[2]*v[2];
length = sqrt (length); // FIXME
if (length) {
ilength = 1/length;
v[0] *= ilength;
Tei wrote:
Theres the C version:
float VectorNormalize (vec3_t v){
float length, ilength;
length = v[0]*v[0] + v[1]*v[1] + v[2]*v[2];
length = sqrt (length); // FIXME
if (length) {
ilength = 1/length;
v[0] *=
--
[ Picked text/plain from multipart/alternative ]
Isn't that exactly what you wanted?
Valve, why did you do VectorNormalize() instead of Vector::Normalize() ?
On 3/20/06, Jorge Rodriguez [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
By the way, there already is a member function for
[EMAIL PROTECTED] wrote:
By the way, there already is a member function for this. It's called
NormalizeInPlace()
At the risk of reviving this fruitless discussion from its grave:
NormalizeInPlace() and the Normalize() that I speak of are different.
Normalize() will return a normalized
Aaron Schiff wrote:
--
[ Picked text/plain from multipart/alternative ]
VectorNormalize actually alters the input vector and returns the length of
the original as a float, Normalize just handles the vector
I'm aware of that. Couldn't they have kept the original Normalize then?
It's more
What are talking about with respect to change? Change from what version to
what version? Looks like it's always been that way.
In any case, you can add another member function without worrying about engine
binary compatibility if you want.
At 2006/03/05 02:07 AM, you wrote:
Aaron Schiff
[EMAIL PROTECTED] wrote:
What are talking about with respect to change? Change from what version to
what version? Looks like it's always been that way.
Half-Life 1.
In any case, you can add another member function without worrying about engine
binary compatibility if you want.
Why
VectorNormalize is Quake legacy code. I have never worked with
Half-life 1, so, I'm not sure if anything has changed, but,
VectorNomalize, VectorMA VectorSubtract and etc are in all versions of
Quake, as well as the code in low level routines, like in_main.cpp
Replacing this code with a more
Why do you say that? Seems to me that if you change the function
addresses it would surely cause lots of crashes in the engine.
If you just add a new member function if it's not virtual it's not going
to change the binary representation of the class (probably anyway, there's
not absolute
There's no engine change required. That's a seperate module. The engine
maintains it's own code for class member functions.
I've never had a need to do this particular change in the Source engine, but I
don't see how this could cause a problem.
At 2006/03/05 12:50 PM, Tom Parker wrote:
Tom Parker wrote:
Replacing this code with a more C++ friendly version would require
drastic changes everywhere in the engine, and be more of a pain than a
benefit. I haven't yet done much vector math in HL2, but I do believe
that the Vector class has C++ style functions for this?
Half-Life
You can add member functions to Vector. It will not affect the structure's
binary layout.
At 2006/03/05 01:08 PM, Jorge Rodriguez wrote:
Tom Parker wrote:
Replacing this code with a more C++ friendly version would require
drastic changes everywhere in the engine, and be more of a pain than a
[EMAIL PROTECTED] wrote:
You can add member functions to Vector. It will not affect the structure's
binary layout.
I think it will affect the function address table. When the engine tries
to call a function on a Vector created by the game, a mismatched
function table would cause the wrong
--
[ Picked text/plain from multipart/alternative ]
because they wanted to return the length of the original vector...anyways,
VectorNormalize achieves the same thing...
On 3/5/06, Jorge Rodriguez [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
You can add member functions to Vector.
Aaron Schiff wrote:
--
[ Picked text/plain from multipart/alternative ]
because they wanted to return the length of the original vector...anyways,
VectorNormalize achieves the same thing...
Can I please get somebody who knows what they're talking about in here,
like someone from Valve?
--
[ Picked text/plain from multipart/alternative ]
What do you want them to do, change that single method in a core engine
function just so you can save a few operations? Apologize for not making it
exactly as you had expected? I really don't see why you're so adamant about
this.
--
Harry Bock wrote:
What do you want them to do, change that single method in a core engine
function just so you can save a few operations? Apologize for not making it
exactly as you had expected? I really don't see why you're so adamant about
this.
Presumably they can answer my question,
On Mon, 2006-03-06 at 00:02 -0500, Jorge Rodriguez wrote:
Presumably they can answer my question, because one of them removed the
function and knows why it was done. I expect that the answer is that
returning a pass-by-reference copy constructed Vector is much slower
then normalizing the
--
[ Picked text/plain from multipart/alternative ]
VectorNormalize actually alters the input vector and returns the length of
the original as a float, Normalize just handles the vector
On 3/4/06, Jorge Rodriguez [EMAIL PROTECTED] wrote:
Valve, why did you do VectorNormalize() instead of
26 matches
Mail list logo
