Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Shader uniform API -- part II  (Read 27527 times)

0 Members and 1 Guest are viewing this topic.

Hiura

  • SFML Team
  • Hero Member
  • *****
  • Posts: 4321
    • View Profile
    • Email
Re: Shader uniform API -- part II
« Reply #30 on: September 04, 2015, 10:57:38 am »
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?".
SFML / OS X developer

Klaim

  • Full Member
  • ***
  • Posts: 137
    • View Profile
Re: Shader uniform API -- part II
« Reply #31 on: September 09, 2015, 10:53:51 pm »
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

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6287
  • Thor Developer
    • View Profile
    • Bromeon
Re: Shader uniform API -- part II
« Reply #32 on: September 21, 2015, 02:22:06 pm »
[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%.
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6287
  • Thor Developer
    • View Profile
    • Bromeon
Re: Shader uniform API -- part II
« Reply #33 on: October 05, 2015, 11:44:17 am »
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.
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Suslik

  • Newbie
  • *
  • Posts: 33
    • View Profile
Re: Shader uniform API -- part II
« Reply #34 on: January 31, 2016, 05:01:03 am »
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.
« Last Edit: January 31, 2016, 06:23:03 am by Suslik »

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
Re: Shader uniform API -- part II
« Reply #35 on: January 31, 2016, 09:13:18 am »
Quote
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.

Quote
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.
Laurent Gomila - SFML developer