Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Page 2 of 2 FirstFirst 12
Results 11 to 18 of 18

Thread: Compatibility state

  1. #11
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948
    I really do not know what the big point of the core-profile is. If an attribute is specifed with vertexAttrib or texCoord and thus named myVertexAttrib or gl_MultiTexCoords in the shader - what is the big difference?
    Well, let's ignore the obvious points of having a variable name that actually describes the contents of its data, instead of pretending `gl_MultiTexCoord3` really means "matrix bone weights". Let's look at purely practical issues: things you cannot do with compatibility attributes.

    Non-generic vertex attributes cannot:

    1: Be integer or double-precision. `gl_Vertex` is, and always will be, a `vec4`. Not an `ivec4` or `dvec4`.

    2: Use more resources than specified. There are exactly and only 8 texture coordinates, one position, two colors, one normal, and a single floating-point fog coordinate. If you happen to need more per-vertex attributes than that, tough. Even if your hardware could provide more of them, you can't use them.

    3: Use the new split-format syntax.

    4: Use instanced arrays.

    And this is just for attributes.

    The "big point of the core-profile" is to define a reasonable API that doesn't include superfluous cruft. Like `gl_Vertex`. Generic vertex attributes are the more flexible mechanism, so they are the only mechanism. Shaders are the more flexible mechanism for doing various processing, so they are the only mechanism. And so forth.

    The only fixed-function stuff left are things that need to be due to being connected to fixed processing stages. `gl_Position` as an output from the vertex processing is there because there needs to be some way for a shader to say, "This is the clip-space position of the vertex, go use that in the primitive." `gl_FragDepth` is there as a fragment shader output because it has very specific meaning for the depth test. And so forth.

    Core OpenGL is a cleaner, more focused API that doesn't have as much redundancy in it. Though thanks to that split-format syntax, we're getting new redundancy...

    This is why I would call

    It was never the intent to be able to do so with no changes, only relatively few.
    that a poor design decision.
    Well, to me, the compatibility profile itself is a poor design and should never have been brought back in GL 3.2. So it's a matter of personal taste.

    But as I pointed out earlier, what you wanted to write would never have compiled on most hardware of the day when this system was devised. It simply would not have been possible for hardware to run such things. And nowadays, most people don't need the GLSL-to-fixed-function interop code. So even now when you could write it, you wouldn't.

    The ARB is not going to create a new feature solely for compatibility OpenGL. While they do keep it up-to-date to some extent, many features (like split-format syntax) don't get back-ported to the old stuff (one of the only useful side-effects of deprecation&removal is that they don't add functions solely for compatibility GL anymore). And unless a new feature brings something to core OpenGL, it's highly unlikely they'll bother with it.

  2. #12
    Junior Member Regular Contributor
    Join Date
    Nov 2012
    Location
    Bremen, Germany
    Posts
    167
    I should not have come up with vertex-attribute I see. My Point was simply the following: Trying to enhance old gl-code is easy and can be done in a smooth fade up to a certain point when suddenly a large portion of application code Needs to be changed or the whole OpenGL-api has to be hooked to keep track of the state changes - not only the functions that got thrown out of the core Profile.

  3. #13
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948
    or the whole OpenGL-api has to be hooked to keep track of the state changes
    No, only glTexEnv and texture enable state needs to be tracked. Everything else is tracked for you.

    not only the functions that got thrown out of the core Profile.
    What core functions need state tracking? I certainly don't need it.

  4. #14
    Junior Member Regular Contributor
    Join Date
    Nov 2012
    Location
    Bremen, Germany
    Posts
    167
    And why aren't those tracked for compatibility?

  5. #15
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948
    I told you why: tracking it would have been pointless. In the GL 2.0 days, hardware would not have been able to compile code like that. And now that hardware can, nobody actually wants to do it or needs the functionality.

  6. #16
    Junior Member Regular Contributor
    Join Date
    Nov 2012
    Location
    Bremen, Germany
    Posts
    167
    ! ........

  7. #17
    Advanced Member Frequent Contributor
    Join Date
    Apr 2009
    Posts
    593
    I think you are missing a big point that Alfonse is trying to make: glTexEnv changes are akin to changing what fragment shader is run. The entire multi-texturing API was for the pre-shader age. glTexEnv is a great deal clunkier to do that a fragment shader (and for that matter glTexGen is a great deal clunkier than writing a vertex shader).

    My suggestion: Let the compatibility profile go.

  8. #18
    Member Regular Contributor
    Join Date
    Mar 2001
    Posts
    469
    Have you looked at Regal?

    https://github.com/p3/regal

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •