16
General discussions / sf::Shader -- API to set uniforms
« on: March 29, 2014, 05:36:02 pm »
Hello,
Several times in the past it has been requested that sf::Shader support more setParameter() overloads, in order to be able to specify other GLSL uniform types.
We recently opened issue #538, where we started to discuss about a possible API to possibly support one or more the following GLSL types:
Another idea is to provide named functions such as setFloat(), setMatrix3x3() and so on. This looks nice and expressive at first, but it comes with the drawback that it makes generic code more difficult. In particular, if we want to provide support for GLSL arrays (which can consist of almost any GLSL type), we effectively have to duplicate all the existing functions, which is of course not ideal.
That's why I personally tend to be in favor of further setParameter() overloads, combined with new types to clearly distinguish the parameters. A function template setParameterArray() or similar could be used to set a uniform array, and deduce from the parameter type which GLSL type is being set. This would avoid a large part of the code duplication.
Generic code also makes it significantly easier for SFML or an extension library to provide support for higher-level data (i.e. GLSL structs), and possibly other types like NxM matrices.
What do you think? Are there other ideas? If you are interested, consider also reading the discussion on GitHub.
Several times in the past it has been requested that sf::Shader support more setParameter() overloads, in order to be able to specify other GLSL uniform types.
We recently opened issue #538, where we started to discuss about a possible API to possibly support one or more the following GLSL types:
- 4x4 matrices (const float[16])
- 3x3 matrices (const float[9])
- signed and unsigned integers
- booleans
- arrays
Another idea is to provide named functions such as setFloat(), setMatrix3x3() and so on. This looks nice and expressive at first, but it comes with the drawback that it makes generic code more difficult. In particular, if we want to provide support for GLSL arrays (which can consist of almost any GLSL type), we effectively have to duplicate all the existing functions, which is of course not ideal.
That's why I personally tend to be in favor of further setParameter() overloads, combined with new types to clearly distinguish the parameters. A function template setParameterArray() or similar could be used to set a uniform array, and deduce from the parameter type which GLSL type is being set. This would avoid a large part of the code duplication.
Generic code also makes it significantly easier for SFML or an extension library to provide support for higher-level data (i.e. GLSL structs), and possibly other types like NxM matrices.
What do you think? Are there other ideas? If you are interested, consider also reading the discussion on GitHub.