You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is an interesting request.
It reminded me of an earlier issue here in glbinding: #236
However, I want to refer to other official, normative information on the GLhalf data type.
In the official C headers from Khronos, GLhalf is defined as follows:
Which is of little surprise, as this XML mirrors the C header.
Coming from this, I think most platforms expect a GLhalf to be just storage from a CPU and RAM perspective. Only the GPU performs meaningful operations on them.
From what I see, I think that we just need some kind of placeholder type and not actual FP semantics.
I had a look into glm, a common dependency of our downstream projects that also use glbinding, and they even removed their half data type in the past.
Can you be a little more specific what you expect a GLhalf to behave?
In which scenarios do you need FP semantics?
Hello, great library, I have been enjoying using it with strong typing guarantees and enum classes :)
I have been implementing some conversion code to associate opengl types with associated enum values for
glVertexAttribPointer/Format
According too this and to the enum value (I would get you a line permalink but my browser is viewing glbinding/gl/enum.h as raw, but it is line 6999).
However it is defined as a short integer type.
Thanks - TFB :)
The text was updated successfully, but these errors were encountered: