Announcement

Collapse
No announcement yet.

The Many Problems With OpenGL

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    skimmed through his blog post... very pointed complaints- maybe it's time for Khronos to create a brand new/simpler API, not necessarily backward compatible at the API level with all the legacy crap he's alluding to, but functionally compatible yet simpler API that hopefully draws game programmers to it (and hopefully puts more nails in DirectX's coffin) for new development.... and hopefully porting of engines to this new API.

    Comment


    • #12
      Originally posted by phoronix View Post
      Phoronix: The Many Problems With OpenGL

      Rich Geldreich of Valve has written a opinion piece on the gripes he has with OpenGL...
      He should have commented on OpenGL ES which supposedly resolves a lot of the legacy issues he refers to.

      Comment


      • #13
        Originally posted by DanLamb View Post
        He should have commented on OpenGL ES which supposedly resolves a lot of the legacy issues he refers to.
        Isn't GL ES only for embedded tho? (not a GL programmer here).

        Comment


        • #14
          With OpenGL beeing the only API on linux, I wonder how much politics is working in the background to sabotage it?! (And now a totaly unrelated HELLO to M$ in the Khronos board!)
          Ignoring GLES and the mobile stuff. The two big vendors that really matter in the performance arena are Nvidia and AMD. Both for example support DSA that was first drafted in the end of 2007. But still there are no known plans to make it core!

          Sure there is a need for a legacy OpenGL support. But that can be put into a user space library that uses a decent graphic API as backbone. There is no excuse to not ditch the legacy clutter already.

          Originally posted by GreatEmerald View Post
          I haven't worked with OpenGL all that much, but while the attitude of "throw legacy away" makes sense in a way, on the other hand it makes me think it might overcomplicate things... My card game uses OpenGL 2 commands, instead of shaders, because I literally need only textured squares. Doing the same thing with shaders would be more complicated than just calling functions that do it. And yet the function pipeline is considered legacy.
          Of course, that could be solved by making a library in which those functions create shaders and whatnot, but at the moment I'm not aware of such libraries...
          The Hardware API is not supposed to micro manage that much for you. For that you use/make user space librarys like the already mentioned 2D functions from SDL2.
          And user space librarays would be way easyer to develop for an API that is not bloated by 20 years of accumulated design changes.

          Except for very small programs you write your own layer betwin your program and the graphic api. Thats why DSA (and it NOT beeing part of core) matters so much.

          Comment


          • #15
            Originally posted by MartinN View Post
            Isn't GL ES only for embedded tho? (not a GL programmer here).
            If you can run full GL 4.3, you can run GLES 3.0 on it without rewriting anything, it has the GLES link table. I think version 4.1 or something matched GLES 2. Which means you could write GLES 3.0 code, and have it run on all Android devices, and any GL 4.3 driver, without rewrites.

            The problem is that even GLES has legacy stupidity in it. It didn't start out as a programmable pipe, so they made the same mistake twice and it wasn't until ES 2.0 that the shader language was added. So once again, you have all the GLES 1.X legacy crap nobody will use on a programamble chip but you gotta carry it along for the ride.

            It isn't as bad as the mess of pre GL 3 nonsense, though. I'd definitely write a game to GLES3, just so that it has portability on everything, even if everything isn't necessarily modern - by the time any project I'd start today was ready, it would take two years, so you could expect GL 4.3+ and ES 3.0+ on all major platforms and on a huge percentage of peoples devices.

            Comment


            • #16
              Originally posted by Kushan View Post
              I think that's the point, modern OpenGL still has support for that old hardware. And by "support", I mean a lot of legacy cruft in the codebase, not that it'll actually run on that old hardware. Rich wants to dump said cruft in favour of a modern, simpler API. Remove all the old, "legacy" stuff, the "compatibility" modes and so on to create a leaner, simpler API.
              Wrong, the compatibility problems aren't related to the hardware, it's about the compatibility with software that relies on the legacy features. That software might be 20 years old or maybe written last week.

              Comment


              • #17
                Originally posted by berarma View Post
                Wrong, the compatibility problems aren't related to the hardware, it's about the compatibility with software that relies on the legacy features. That software might be 20 years old or maybe written last week.
                I agree with berama: HARDWARE has potentiality, but software has to make working hardware properly. Example: the same DEVICE 2 different drivers 2 different results.

                Comment


                • #18
                  Simple solution: OGL is unsalvageable. Make a new API and move on. He's simply stating what devs have known for years now.

                  Comment


                  • #19
                    AFAIK OGL has the Core functionality which doesn't use any of the legacy things.

                    You aren't oblied to use legacy API on OGL 3 and onwards.

                    Comment


                    • #20
                      Originally posted by Filiprino View Post
                      AFAIK OGL has the Core functionality which doesn't use any of the legacy things.

                      You aren't oblied to use legacy API on OGL 3 and onwards.
                      obliged*

                      Comment

                      Working...
                      X