SFML community forums
General => Feature requests => Topic started by: criptych on October 09, 2015, 04:58:21 pm
-
Regarding this comment on the topic "Vertex Attributes on shaders" (http://en.sfml-dev.org/forums/index.php?topic=7167):
This is not a bad idea, but I don't think that it fits in SFML.
Just wondering whether this stance has changed any, since it's quite an old topic, apparently pre-2.0, and in the meantime there's been discussion of several (https://github.com/SFML/SFML/issues/298) other (https://github.com/SFML/SFML/issues/428) enhancements (https://github.com/SFML/SFML/issues/983) to sf::Graphics, including shaders.
I've made similar modifications myself and noticed that any decent implementation practically requires direct modification to the Shader class, because it needs the shader program name m_shaderProgram after it's created but before it gets compiled:
Active attributes that are not explicitly bound will be bound by the linker when glLinkProgram is called.
Binding them afterward has no effect until you relink the program, which sf::Shader doesn't support (compile() destroys any existing program), so subclassing Shader isn't really an option. On the other hand, writing a new Shader class from scratch would duplicate a lot of code, and wouldn't integrate with the rest of SFML.
The commit is here (https://github.com/criptych/SFML/commit/4edc93758e9950dc9f33b30b2aa50b89708eaff0) pending a pull request.
TL;DR: Yes, it's not extremely useful outside of "wrapping OpenGL," but it enables the use of custom shader attributes where needed, while taking advantage of the existing class and features without duplicating code.
-
I don't think this is a bad idea myself. Some people who are not familiar with OpenGL/GLSL might not understand why this is necessary, but since OpenGL 3.0 and thus GLSL 1.30, the built-in attributes and matrices aren't available any longer. By not supporting binding attributes, SFML is not only not supporting usage of sfml-graphics classes as OpenGL wrappers, it is also limiting the way people can use GLSL in purely sfml-graphics (non-OpenGL) code. A lot of stuff has been added to GLSL since 1.30 and SFML developers currently have to make the hard decision to either limit themselves to 1.20 or hack their way around the limitation as you stated.
-
Since OpenGL 3.0 and thus GLSL 1.30, the built-in attributes and matrices aren't available any longer.
Exactly what I'm running into. OpenGL 4+ (I think?) has the layout specifier, which may work with Shader as-is, but of course it requires OpenGL 4+. glBindAttribLocation has been core since 2.0, as long as shaders themselves.
-
I like this idea too. I actually ran into an issue regarding attributes using SDL and OpenGL ES 3 on Android. The problem is stated on this Stack Overflow post http://stackoverflow.com/questions/33204217/opengl-es-3-instance-render-fails-but-works-on-desktop (http://stackoverflow.com/questions/33204217/opengl-es-3-instance-render-fails-but-works-on-desktop) . Basically, I couldn't use layout qualifiers because the GLSL driver (or something) was not laying out the mat4 attribute like 4 consecutive vec4's like it normally should. So I had to either get the attrib location or bind it manually.
Now, this might not be an issue for SFML since mobile support isn't quite there yet but I thought it would be worth mentioning.