Bug in _types.h

[Vitek1425]

https://github.com/OpenXRay/xray-16/blob/70f130c6fc719293c3b6abb1ccacbb084eaee6d1/src/xrCore/_types.h#L31 Is there problem with determination min values here ? For example -std::numeric_limits::max() != std::numeric_limits::min() also for signed types. http://en.cppreference.com/w/cpp/types/numeric_limits Also can replace type_zero to std::numeric_limits::lowest() ?

[Xottab-DUTY]

https://github.com/OpenXRay/xray-16/commit/6f94e86fd5b7c82bc4adc7b6a602bb67d2a17c22#diff-1fca930358f9b19260308c7a36188cacL34

I don't know why, but -std::numeric_limits<int>::max() for type_min was used in original and this behaviour was not changed. I don't know why honestly. This issue needs investigation.

@Im-Dex, @nitrocaster, any thoughts?

[NeoAnomaly]

That expression is used because the std::numeric_limits::min returns for floating-point types with denormalization the minimum positive normalized value.

For example:

std::numeric_limits<T>::min():
        float: 1.17549e-38 or 0x1p-126
        double: 2.22507e-308 or 0x1p-1022
std::numeric_limits<T>::lowest():
        float: -3.40282e+38 or -0x1.fffffep+127
        double: -1.79769e+308 or -0x1.fffffffffffffp+1023
std::numeric_limits<T>::max():
        float: 3.40282e+38 or 0x1.fffffep+127
        double: 1.79769e+308 or 0x1.fffffffffffffp+1023

In current codebase it would be working correct if std::numeric_limits::min was used

[Xottab-DUTY]

So, instead of -max() we can use lowest() and leave type_zero as is?

[NeoAnomaly]

Yes, we can... and remove type_zero. IMO, it's absolutely useless )