Extremely minimal support for 4x4 transforms

[kenpower]

I'm an educator who uses SFML to teach some graphics programming. I love it. My students can be up and running quickly writing 2D games, then later we can incrementally add raw 2D- OpenGL, eventually moving on to GLSL shaders and then 3D OpenGL, all in the same SFML framework.

SFML is great because it hides a lot of the nitty-griitty around setting up windows, loading textures loading compiling and linking shaders, while allowing me the freedom to do relatively advanced stuff like GLSL and 3dOpenGL.

However, there is one small issue which would help me out greatly, that is passing full 4x4 matrices to the shaders using SFML, which of course is necessary for any non-trivial GLSL shader.

SFML does pass 4x4 matrices to shaders, via trasforms, but the code only allows us to write to the 3x3 submatrix. All I ask is either

a new  transform constructor which takes a float[16] as a parameter,

or a new method on the shader like this one;

Shader::setParameter(const std::string& name, const float m[16]); // can reuse the code from the trasform version  

I'll use GLM to generate the actual matrices, I just need a sfml native way to get the 4x4 matrix into the shader

I know Laurent has often said that he will only support 2D features, but this is such a small change and would help so much.

[Laurent]

You're right that my philosophy is to provide support for sfml-graphics (and more generally 2D) stuff only. But I think it's ok to add support for more uniform types in sf::Shader; especially since it already supports 3D and 4D vectors.

I'll add a task for that, and it should be done for SFML 2.2.

Thanks a lot for your feedback.

[Nexus]

Here is the GitHub issue #538. Sounds interesting, I'll take care of it

One problem I see is that the parameter types are implicitly deduced, there are several sf::Shader::setParameter() overloads. For const float[16] and const float[9], this would lead to problems -- both are the same type, namely const float*. So we would have to think about a slightly different API, maybe something general for arrays.

[wintertime]

While you are at adding support for more dimensions, I can add I often thought it would be nice to be able to give a z coodinate to shapes/sprites/... .
That would be nice to use the z buffer for layering sprites, for example, 1st layer rain/snow, 2nd a bit deeper characters, 3rd trees/other objects, ..., 2nd last floor, last sky. They could then be drawn in the most convenient order without having to follow the painters algorithm.
Drawing a GUI could also profit from reordering some windows by setting a z-order.
Though blending may need to be tweaked to make it look right.

[Laurent]

One problem I see is that the parameter types are implicitly deduced, there are several sf::Shader::setParameter() overloads. For const float[16] and const float[9], this would lead to problems -- both are the same type, namely const float*. So we would have to think about a slightly different API, maybe something general for arrays.

True. Let's discuss that on the tracker

While you are at adding support for more dimensions, I can add I often thought it would be nice to be able to give a z coodinate to shapes/sprites/... .

This is a totally unrelated issue, that has already been discussed in the past. Please stay focused on the initial request.

[Lo-X]

I'm wondering what kind of changes in the API you consider.

Something like adding Matrices structs ? Matrice<9>, Matrice<16> ? That just would be hiding a float[9] and float[16] ? (<- this was said in a very simple and naive way ofc)

[Nexus]

I'm wondering what kind of changes in the API you consider.

See GitHub.