Author: rambetter

Date: Thu Dec 30 21:03:13 2010
New Revision: 390

Modified:
GtkRadiant/trunk/libs/mathlib.h
GtkRadiant/trunk/libs/mathlib/mathlib.c
GtkRadiant/trunk/tools/quake3/common/polylib.c
Log:
Undoing commits r363 and r371 as it pertains to polylib.c, mathlib.c,
and mathlib.h (the regression tests have not been removed).
Trunk is now restored to a state that it was in before I started
trying to fix the math accuracy errors in q3map2.  Commits r363 and
r371 were "correct" and did improve math accuracy significantly, but
unfortunately the underlying cause of math accuracy issues is something
else, which is being addressed in branch Rambetter-math-fix-experiments
currently.  I'm taking the BSD approach here, which is "we not going to
partially fix the problem.  it's all or nothing".  Otherwise it's just
too risky in my opinion.  I don't like playing Whack-A-Mole.

Someday, we might merge Rambetter-math-fix-experiments branch to trunk.
Sorry about all these needless commits to trunk.
This commit is contained in:
Rudolf Polzer
2010-12-31 18:54:33 +01:00
parent c8524834a7
commit 7a04b6fdea
3 changed files with 5 additions and 97 deletions

View File

@@ -119,7 +119,7 @@ void _VectorCopy (vec3_t in, vec3_t out)
}
vec_t VectorNormalize( const vec3_t in, vec3_t out ) {
vec_t length;
vec_t length, ilength;
length = (vec_t)sqrt (in[0]*in[0] + in[1]*in[1] + in[2]*in[2]);
if (length == 0)
@@ -128,28 +128,14 @@ vec_t VectorNormalize( const vec3_t in, vec3_t out ) {
return 0;
}
out[0] = in[0]/length;
out[1] = in[1]/length;
out[2] = in[2]/length;
ilength = 1.0f/length;
out[0] = in[0]*ilength;
out[1] = in[1]*ilength;
out[2] = in[2]*ilength;
return length;
}
vec_t VectorSetLength(const vec3_t in, vec_t length, vec3_t out) {
vec_t origLength;
origLength = (vec_t) sqrt((in[0] * in[0]) + (in[1] * in[1]) + (in[2] * in[2]));
if (origLength == 0)
{
VectorClear(out);
return 0;
}
VectorScale(in, length / origLength, out);
return origLength;
}
vec_t ColorNormalize( const vec3_t in, vec3_t out ) {
float max, scale;