sf::Shader -- API to set uniforms

[zsbzsb]

Are there more drawbacks than it being a dependency? Or is that a big drawback enough?

I am not sure how much it would affect it, but you would also have to deal with changing over SFML's bindings to the GLM types. And since I haven't taken a look at GLM I don't know how much of an issue converting to the bindings will be.

[MorleyDev]

Presumably a switch over to GLM would have to wait for SFML 3?

And if C++11 required is on the cards for SFML 3, most of the current SFML typedefs for integral types could be replaced with the cstdint definitions (std::uint32_t, std::uint16_t, std::int16_t etc.)

[Ixrec]

I looked up some other C++ libraries that wrap OpenGL shaders, and these are the two best-looking parameter binding interfaces I found:

http://oglplus.org/oglplus/html/classoglplus_1_1Uniform.html

https://github.com/Overv/OOGL/blob/master/include/GL/GL/Program.hpp

I saw several other libraries and classes out there, but most of them support significantly fewer overloads/permutations than we want, so they wouldn't be good references.


Some trends I noticed that are relevant to the previous discussion:
- Everyone treats matrices as a special case.  The non-template interfaces have overloads for matrices of specific sizes, and the template interfaces have a separate function for matrices.
- I don't think anybody supports arrays of matrices.  However, the types in oglplus' interface are painfully obtuse so I can't be sure.
- Everyone seems to offer a pointer/size interface for parameter arrays, even if they also provide overloads taking std::vectors or other containers.
- Everyone seems to have vector and matrix classes for all the sizes they support.  I never saw a pointer/width/height interface for matrices.  Admittedly, they are wrapping *all* of OpenGL, and the two I linked above appear to support non-trivial math on their vector/matrix classes.
- And of course, "setUniform" and variants thereof are by far the most popular names for these functions.

Hope this helps.


P.S. Aside from adding yet another dependency, would there be any real downside to incorporating glm in SFML 3? (presumably with some typedefs so users don't need to explicitly use the glm namespace)

[Tank]

P.S. Aside from adding yet another dependency, would there be any real downside to incorporating glm in SFML 3? (presumably with some typedefs so users don't need to explicitly use the glm namespace)

Some things that come into my mind:

• Code style does not fit into SFML (typedefs are definitely no solution, as you will face the real names somewhere sometime).
• Added dependency -- GLM is header-only, so this is cheap, but it still has to be maintained
• What do Eigen users do? They still have to convert.
• SFML itself does not really benefit from it, instead it's for use cases for the user which are probably not in SFML's scope.

I'm not against this per se, but SFML does not need as much algebra as the user, and what's needed is provided.

I actually like binary1248's idea: What if the data types of SFML would be binary-compatible to other libraries' data types? They are likely not to change in the future at all, so it's rather safe to cast between them. Maybe the types are even already compatible, I haven't checked this.

[grok]

I am sorry for hijacking this thread, had no idea where should I post.
Anyway, I just upgraded to the current SFML version from git (revision 1217699fe0) and noticed that

    fooShader.setUniform("someFloatVal", someIntVal);
 

behaves differently than the previous version:

    fooShader.setParameter("someFloatVal", someIntVal);
 

I mean, if our shader has

uniform float someFloatVal;
//...

the new version stops working.
In order to fix that I had to add an explicit cast from int to float:

    fooShader.setUniform("someFloatVal", (float) someIntVal);
 

Is this a bug?

[Laurent]

It's not a bug, if you pass an integer it maps it to an integer uniform.

[grok]

thanks for the response.
weird, the previous version works fine in my case even if I pass an integer.

[Nexus]

You can post in the Help/Graphics forum.

That's not weird, there was no int overload of the deprecated setParameter(). It's about time that people use the proper C++ types