Re: [hlcoders] Why VectorNormalize?
--
[ 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 Rodriguez [EMAIL PROTECTED] wrote:
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] *= ilength;
v[1] *= ilength;
v[2] *= ilength;
}
return length;
}
Quake 1 source:
http://www.untitled-game.org/source/mathlibc.html
Thats why return a float. Because is C code. And is the right thing
for Think in C mode. But is the wrong thing for Think in OOP mode.
So is right that Valve change this stuff.
Nevermind.
--
Jorge Vino Rodriguez
___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
--
Programmer for RnL
www.resistanceandliberation.com
--
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Why VectorNormalize?
Looking back at all the posts, the only thing I can glean is simply this;
If you look at hl1, everywhere that valve used CVEctor-Normalize(); it was
like this:
Vector blah = Vector(x,y,z);
blah = blah.Normalize();
so you're copying the vector around.
They simply replaced that with
Vector blah = 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){
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;
v[1] *= ilength;
v[2] *= ilength;
}
return length;
}
Quake 1 source:
http://www.untitled-game.org/source/mathlibc.html
Thats why return a float. Because is C code. And is the right thing
for Think in C mode. But is the wrong thing for Think in OOP mode.
So is right that Valve change this stuff.
Nevermind.
--
Jorge Vino Rodriguez
___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
__ NOD32 1.1454 (20060321) Information __
This message was checked by NOD32 antivirus system.
http://www.eset.com
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Why VectorNormalize?
Adding to that.. VectorNormalize was there as well, to do the same thing as NormalizeInPlace. Ie: Vector blah = Vector(x,y,z); VectorNormalize(blah); Oh and you can add functions to vector in hl2 and no problems 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 VectorNormalize? Looking back at all the posts, the only thing I can glean is simply this; If you look at hl1, everywhere that valve used CVEctor-Normalize(); it was like this: Vector blah = Vector(x,y,z); blah = blah.Normalize(); so you're copying the vector around. They simply replaced that with Vector blah = Vector(x,y,z); blah-NormalizeInPlace(); ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] TraceRay not hitting player's head
-- [ Picked text/plain from multipart/alternative ] For debugging purposes, in a MP game, I'm drawing a line to the endpoint of the trace. If I aim at a foot, body, hand, etc. the player entity is returned and the line gets drawn to that point. But if I aim at the head, the trace doesn't see the player and it draws the line right through the player's head to whatever is behind him. CTraceFilterHitAll traceFilter; enginetrace-TraceRay(ray, MASK_ALL, traceFilter, tr ); Do I need to change my mask or trace filter I need to use to include the a player's head? Why won't this work? Grant (L. Duke) -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] the vphysics bug worse in latest srcds?
Here's a new one - slightly different, note the 260d0590... vphysics.dll!260a2426() vphysics.dll!260d3eae() vphysics.dll!260d0590() vphysics.dll!2608af8e() vphysics.dll!2608b01b() vphysics.dll!260a2697() vphysics.dll!260c6716() vphysics.dll!260aabf2() vphysics.dll!260aac2b() vphysics.dll!2609cd5b() vphysics.dll!2609cae9() vphysics.dll!260967d8() vphysics.dll!2601d878() server.dll!PhysFrame(float deltaTime=0.01500) Line 1341C++ server.dll!CPhysicsHook::FrameUpdatePostEntityThink() Line 441 + 0x9 C++ server.dll!InvokeMethod(void (void)* f=0x223f4be2) Line 244C++ server.dll!IGameSystem::FrameUpdatePostEntityThinkAllSystems() Line 221 + 0xa C++ server.dll!CServerGameDLL::GameFrame(bool simulating=true) Line 912 C++ engine.dll!0daa0691() engine.dll!0da9b0e7() engine.dll!0da9cc75() engine.dll!0da03cd7() engine.dll!0da04376() engine.dll!0da0f025() engine.dll!0da0f112() user32.dll!77d496b8() engine.dll!0da0f1af() engine.dll!0daacefc() engine.dll!0daac4ed() dedicated.dll!1000c084() engine.dll!0daacd4e() engine.dll!0daac48b() dedicated.dll!1000c535() dedicated.dll!1000c553() materialsystem.dll!00cd0dae() materialsystem.dll!00cd0f38() materialsystem.dll!00cd0dae() materialsystem.dll!00cd0f05() materialsystem.dll!00cd7f64() materialsystem.dll!00cd9502() tier0.dll!0087299f() materialsystem.dll!00cda349() tier0.dll!008764b5() tier0.dll!0087105a() tier0.dll!008731d0() tier0.dll!008738de() datacache.dll!00e7daa2() datacache.dll!00e7e08e() datacache.dll!00e733ae() datacache.dll!00e73e6b() engine.dll!0db556b8() engine.dll!0db552dc() engine.dll!0d9adc0d() dedicated.dll!10021d0b() dedicated.dll!10022c00() dedicated.dll!10022c00() dedicated.dll!1000c7f7() ntdll.dll!7c9106eb() At 2006/03/16 08:13 PM, [EMAIL PROTECTED] wrote: Hmm this one's seemingly identical to the last one. vphysics.dll!260a2426() vphysics.dll!260d3eae() vphysics.dll!2608af8e() vphysics.dll!2608b01b() vphysics.dll!260a2697() vphysics.dll!260aac2b() vphysics.dll!2609cd5b() server.dll!221a22cc() vphysics.dll!2609cae9() vphysics.dll!260967d8() vphysics.dll!2601d878() server.dll!22196475() server.dll!22194661() server.dll!221946c0() server.dll!22156317() server.dll!22156292() server.dll!2213d340() engine.dll!0da9e42f() engine.dll!0daa0691() engine.dll!0da9b0e7() engine.dll!0da9cc75() engine.dll!0da03cd7() engine.dll!0da04376() engine.dll!0da0f025() engine.dll!0da0f112() user32.dll!77d496b8() engine.dll!0da0f1af() engine.dll!0daacefc() engine.dll!0daac4ed() dedicated.dll!1000c084() engine.dll!0daacd4e() engine.dll!0daac48b() dedicated.dll!1000c535() dedicated.dll!1000c553() materialsystem.dll!00cd0dae() materialsystem.dll!00cd0f38() materialsystem.dll!00cd0dae() materialsystem.dll!00cd0f05() materialsystem.dll!00cd7f64() materialsystem.dll!00cd9502() tier0.dll!0087299f() materialsystem.dll!00cda349() tier0.dll!008764b5() tier0.dll!0087105a() tier0.dll!008731d0() tier0.dll!008738de() datacache.dll!00e7daa2() datacache.dll!00e7e08e() datacache.dll!00e733ae() datacache.dll!00e73e6b() engine.dll!0db556b8() engine.dll!0db552dc() engine.dll!0d9adc0d() dedicated.dll!10021d0b() dedicated.dll!10022c00() dedicated.dll!10022c00() dedicated.dll!1000c7f7() ntdll.dll!7c9106eb() At 2006/03/12 02:49 PM, [EMAIL PROTECTED] wrote: Well I see the vphysics crasher is alive and well after the srcds update last week. vphysics.dll!260a2426() vphysics.dll!260d3eae() vphysics.dll!2608af8e() vphysics.dll!2608b01b() vphysics.dll!260a2697() vphysics.dll!260aac2b() vphysics.dll!2609cd5b() vphysics.dll!2609cae9() vphysics.dll!260967d8() vphysics.dll!2601d878() server.dll!22196475() server.dll!22194661() server.dll!221946c0() server.dll!22156317() server.dll!22156292() server.dll!2213d340() engine.dll!0da9e42f() engine.dll!0daa0691() engine.dll!0da9b0e7() engine.dll!0da9cc75() engine.dll!0da03cd7() engine.dll!0da04376() engine.dll!0da0f025() engine.dll!0da0f112()
