anyone know a way to use signbit inside a pixel shader hlsl file?
I need to check if a texture is signed or not and thus do a couple of different things depending on that….but unfortunately signbit isn't recognized and you can't #include <cmath>

Do you care about the sign bit of NaN values? Do you care about the difference between +0.0 and -0.0?

If the answer to both of the above is no, then signbit(x) is equivalent to x < 0.

If the answer to either of the above is yes, then you might want to rethink what you are doing.

just need to know if it is set or not… set = texture is singed, not set = texture is unsigned, checking individual channels rgba…. the goal being, that is for example T.r is signed, and some other test is true, THEN do this… else if T.r is UNSIGNED, change the range for R channel to -1/1
problem is I can't seem to get signbit to work within hlsl pixelshader code, other math functions work fine (abs, exp, exp2, etc…), bit the signbit macro can't be found

That's not what std::signbit does. It checks if a value is negative.

Maybe you're thinking of std::is_signed_v? That's obviously not something you can do in shader code. Use separate shaders for signed and unsigned textures.

@medievil Signbit tells you if the value is negative or not though. Even if it did exist, it wouldn't tell you if the texture is capable of being negative.

I don't think HLSL gives you this, since it converts the texture format for you when you sample it, so you always get a float (or other scalar defined by the shader when it declared the texture I believe) regardless of actual format. And I don't think HLSL can fetch the resource description.

I think you just need to pass this to the shader yourself.

LorenzoGatti said:

medievil said:

… set = texture is singed, not set = texture is unsigned …

It's your texture, you should track what type of data it contains or convert it to the right type. There is no reason to forget this information, or to not tell the shaders that use the textures.

not my texture (it is for an emulation project capable of signed/unsigned for different formats)

anyway to all, I understand my “misunderstanding” now….

there doesn't seem to be an easy way to determine if a texture is signed or not

for example… the device interchangeably uses the same ID for both l6v5u5 AND r6g5b5, the lvu obviously 2 signed components, but the RGB can also have signed components, or can be unsigned…device didn't care, but on PC yea, need to know

If you know a colour of a pixel that uses the signbit, you can reverse engineer whether the value is signed or not, just interpret the bits in both way, and which ever gives the correct answer is how the data should be interpreted.