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

Author Topic: How should SFML handle non-legacy shaders?  (Read 5734 times)

0 Members and 1 Guest are viewing this topic.

MorleyDev

  • Full Member
  • ***
  • Posts: 219
  • "It is not enough for code to work."
    • View Profile
    • http://www.morleydev.co.uk/
Re: How should SFML handle non-legacy shaders?
« Reply #15 on: February 25, 2018, 03:38:11 pm »
Nobody said a modern sfml-graphics implementation couldn't co-exist with the current legacy implementation. That is the aim of this discussion. Once we figure out how to support modern shaders through the API, anybody is free to start work on a modern sfml-graphics backend.

If this is the case, then perhaps instead of creating the new Shader API alongside the existing one inside SFML for 2.X, could it be a good idea to first create an optional separate library for trialling a modern Shaders API, and then bring that API into SFML proper for 3.0?
UnitTest11 - A unit testing library in C++ written to take advantage of C++11.

All code is guilty until proven innocent, unworthy until tested, and pointless without singular and well-defined purpose.

binary1248

  • Moderator
  • Hero Member
  • *****
  • Posts: 1386
  • I am awesome.
    • View Profile
    • The server that really shouldn't be running
Re: How should SFML handle non-legacy shaders?
« Reply #16 on: February 25, 2018, 05:02:16 pm »
Maybe my formulation set some wrong expectations but the "new" API isn't going to be (and doesn't have to be) significantly different from the current one.

The only required extension to the API, mandated by the transition away from client side arrays, is the explicit specification and binding of vertex attributes within the shaders. Built-ins like gl_Vertex and gl_MultiTexCoord0 cease to exist in GLSL 3.00 along with the built-in matrix stacks (gl_ModelViewMatrix, gl_ProjectionMatrix, etc.).

A replacement mechanism for those is all that is needed to make the shader API "non-legacy". The rest of the current API can stay as it is. Uniforms haven't gone anywhere, and the compilation process has stayed mostly the same.

Sure... this won't encompass every addition that has been made to shaders in OpenGL up to 4.5, but those additions can be made iteratively on a case by case basis, like every other feature addition to SFML. None of it is necessary in contrast to what I described above.
SFGUI # SFNUL # GLS # Wyrm <- Why do I waste my time on such a useless project? Because I am awesome (first meaning).

Mario

  • Moderator
  • Hero Member
  • *****
  • Posts: 877
    • View Profile
Re: How should SFML handle non-legacy shaders?
« Reply #17 on: February 26, 2018, 11:43:49 am »
I'd just default to the non-legacy variation but add an additional parameter to the members loading shaders to enable legacy mode (which would just redeclare the legacy variables). In addition, debug builds could look for those classic names and issue warnings, if they're  found without the legacy option set to true.

binary1248

  • Moderator
  • Hero Member
  • *****
  • Posts: 1386
  • I am awesome.
    • View Profile
    • The server that really shouldn't be running
Re: How should SFML handle non-legacy shaders?
« Reply #18 on: February 26, 2018, 02:04:58 pm »
I'd just default to the non-legacy variation but add an additional parameter to the members loading shaders to enable legacy mode (which would just redeclare the legacy variables).

From the GLSL specification:
Quote
Identifiers starting with “gl_” are reserved for use by OpenGL, and may not be declared in a shader; this results in a compile-time error.
SFGUI # SFNUL # GLS # Wyrm <- Why do I waste my time on such a useless project? Because I am awesome (first meaning).

Eyfenna

  • Newbie
  • *
  • Posts: 12
    • View Profile
Re: How should SFML handle non-legacy shaders?
« Reply #19 on: July 08, 2019, 11:00:21 pm »
I'm currently learning a bit of opengl 4 and basicly was thinking about how to handel the topic of shaders in an api like sfml - as in this version of opengl a vertex and a fragment shader are mandatory for anything to be rendered - and wondered if maybe a SetShaders function for drawables and providing a basic shader libary would be a good idea.
Anyway as soon as I'm further into glsl I'm willing to assist and opengl I might be willing to assist.

 

anything