Shader uniform API -- part II

[Hiura]

Generally speaking for the std::string approach (instead of the C approach), but mostly for the "do we have a proof of performance boost with a more complex code?".

[Klaim]

Generally speaking for the std::string approach (instead of the C approach), but mostly for the "do we have a proof of performance boost with a more complex code?".

Same here, that's why I was asking more experienced shader users if they actually do call these kind of apis in critical loops.

I think the overload solution might work well indeed. The standard committee voted string_view in the coming standard to help library implementor later, but as already discussed it's not available here.

I didn't know the values were stored in a map... I though the values were only sent to opengl.

[Nexus]

[Link to feature/shader_uniforms branch]

I added the sf::Glsl namespace in <SFML/Graphics/Glsl.hpp>.

Furthermore, the matrix types Mat3 and Mat4 now use value semantics. As we still have the direct float* overloads for Shader::setUniformMat3/4(), there is no unnecessary copying.

Once more, I considered using setUniform() overloads, as it would allow genericity... However I still think it makes some things confusing. For example, it's not obvious that users have to pass

shader.setUniform(sf::Glsl::Mat3(transform));
shader.setUniform(sf::Glsl::Mat4(transform));
// instead of
shader.setUniformMat3(transform);
shader.setUniformMat4(transform);

With the current way, they can specify what type they need in GLSL (e.g. mat3), and they see all the possible overloads of that function (float*; Glsl::Mat3; sf::Transform). But I still don't like it 100%.

[Nexus]

I reflected again a lot about possible APIs and their advantages and drawbacks, and I'm happy to announce that I've finally reached a point where it's ready

Feel free to test and give feedback to pull request #983.

[Suslik]

So I want to pass a generic 4x4 matrix as a uniform to sf::Shader without

Code: [Select]

shader.setParameter("matrixColumn0", data[0][0], data[0][1], data[0][2], data[0][3]);
shader.setParameter("matrixColumn1", data[1][0], data[1][1], data[1][2], data[1][3]);
shader.setParameter("matrixColumn2", data[2][0], data[2][1], data[2][2], data[2][3]);
shader.setParameter("matrixColumn3", data[3][0], data[3][1], data[3][2], data[3][3]);
Do I have any options that do not include SFML git version manual recompilation?

Update:
I did recompile current git-default version that contained sf::Shader::SetUniform(...) function but when they are used in actual project, they cause linking errors due to functions like this(Glsl.h, line 40) not being labelled as library interface(it means they are not exported in .lib/.dll) :

Code: [Select]

void copyMatrix(const float* source, std::size_t elements, float* dest);

Adding __declspec(dllexport) like this:

Code: [Select]

void SFML_GRAPHICS_API copyMatrix(const float* source, std::size_t elements, float* dest);
solves the problem.

There's also some serious incompatibility going regarding z-buffer that is turned on by default on Windows in SFML 2.3.1 and turned off on linux(at least on drivers I tested). In SFML 2.3.2 it's turned off by default under both OS'es. I had to set sf::ContextSettings::depthBits manually to enable it.

[Laurent]

I did recompile current git-default version that contained sf::Shader::SetUniform(...) function but when they are used in actual project, they cause linking errors due to functions like this(Glsl.h, line 40) not being labelled as library interface

This is already fixed, check recent commits/PRs.

There's also some serious incompatibility going regarding z-buffer that is turned on by default on Windows in SFML 2.3.1 and turned off on linux(at least on drivers I tested). In SFML 2.3.2 it's turned off by default under both OS'es. I had to set sf::ContextSettings::depthBits manually to enable it.

Default context settings most likely depend on the graphics driver. Don't assume anything about them, especially since it's not documented. If you want something, enable it explicitly.