Examples:
/home/mrichters/Repos/Raze/source/common/thirdparty/math/exp.c: In function ‘c_exp’:
/home/mrichters/Repos/Raze/source/common/thirdparty/math/exp.c:171:48: warning: declaration of built-in function ‘floor’ without a prototype; expected ‘double(double)’ [-Wbuiltin-declaration-mismatch]
171 | double polevl(double, void *, int), floor(), ldexp();
| ^~~~~
/home/mrichters/Repos/Raze/source/common/thirdparty/math/exp.c:171:57: warning: declaration of built-in function ‘ldexp’ without a prototype; expected ‘double(double, int)’ [-Wbuiltin-declaration-mismatch]
171 | double polevl(double, void *, int), floor(), ldexp();
/home/mrichters/Repos/Raze/source/common/thirdparty/math/exp.c:200:16: warning: passing arguments to 'polevl' without a prototype is deprecated in all versions of C and is not supported in C2x [-Wdeprecated-non-prototype]
px = x * polevl( xx, P, 2 );
^
/home/mrichters/Repos/Raze/source/common/thirdparty/math/exp.c:201:17: warning: passing arguments to 'polevl' without a prototype is deprecated in all versions of C and is not supported in C2x [-Wdeprecated-non-prototype]
x = px/( polevl( xx, Q, 3 ) - px );
^
/home/mrichters/Repos/Raze/source/common/thirdparty/math/exp.c:167:8: warning: a function definition without a prototype is deprecated in all versions of C and is not supported in C2x [-Wdeprecated-non-prototype]
double c_exp(x)
^
3 warnings generated.
* Change it to a DRotator as that's what the game is expecting. Too many narrowings against DAngle objects needed.
* Utilise object methods where possible.
* Do all math against the object where possible, not its members.
* Change it to a DVector3 as that's what the game is expecting. Too many narrowings against DAngle objects needed.
* Utilise object methods where possible.
* Do all math against the object where possible, not its members.
* This narrowing constructor was causing a problem with a `clamp()` overload in the next commit.
* Believe this is a product of a by-gone time before we had the `XY()` method on `TVector3<T>` objects.
The assumption was made that every object in the ToDestroy list wasn't destroyed yet.
This assumption is wrong in case one object destroys an owned one on its own destruction.
Instead this case must be properly dealt with and duplicate destruction be avoided.
This happened with the panel sprite sentinel in SW's player object.
* Gets rid of the awkward `operator[]()` calls.
* Gets rid of `std::ref()` setup in gun.cpp.
* Ensures a copy isn't made if the caller accidentally leaves off an ampersand.
* Allows us to use a consistent getter for native code and VM exports.