• Create Account

# lomateron

Member Since 03 Feb 2012
Offline Last Active Sep 15 2016 04:51 PM

### In Topic: request HLSL support for sqrt() for integers

31 January 2016 - 09:30 PM

HLSL trigonometric functions are sin() cos() tan() etc...

### In Topic: request HLSL support for sqrt() for integers

31 January 2016 - 09:19 PM

As I already pointed out, since you're calculating (x *x) + (y * y) you can't guarantee avoiding overflow unless you ensure X and Y don't exceed 2^15.

HLSL trigonometric functions have some magic going on behind it, that's why I want them to do a length() for uints, they could make something that will let the function calculate all vectors that have a length less than 2^32

### In Topic: request HLSL support for sqrt() for integers

31 January 2016 - 08:23 PM

If large errors are less important to you than predictable results across different hardware

wait what?

uint operations are more accurate than float operations, as I said you can change the definition of 0 to 1 at your own taste, so I can make (0 to 1) = (0 to 2^25) and this will make it 2 times more accurate than (0 to 1) float

### In Topic: request HLSL support for sqrt() for integers

31 January 2016 - 08:03 PM

Your function is going to give incorrect results every time the the length of the vector isn't a whole integer, so why not do it in floating point where you'll get a far closer to correct result?

float operations have a margin of error too, when using uints you just have to change your definition of what 0 to 1 means, for example 0 to 1 in my world physics engine is 0 to 2^9 uint.

### In Topic: request HLSL support for sqrt() for integers

31 January 2016 - 07:20 PM

just tested HLSL intrinsic length() vs my integer length2D() and length3D() my functions are deterministic, HLSL intrinsic length() isn't, tested on an old ATI vs a new NVIDIA, on HLSL 4. You should test it yourself and that should be enough reason, for the people that want determinism.

PARTNERS