3 ms·

OpenGL is a terrible API with 25 years worth of legacy baggage. There are many ways of doing everything and a portable engine needs to support many methods for

by exDM69 9y ago

OpenGL is a terrible API with 25 years worth of legacy baggage. There are many ways of doing everything and a portable engine needs to support many methods for even the simplest of things because the newest and best methods aren't supported everywhere. Vulkan is a much better designed API with a lot less legacy crap in it. It's lower level and gives more control to the app/engine developer. The bad news is that Vulkan is a bit verbose, but this stops being an issue once you move past "hello world" level apps. OpenGL gets really difficult once you start doing complex things.

megaman22 9y ago
The multiplicity of ways to do everything in OpenGL was always a stumbling block for me in the past; it's been a big driver towards leaning in the direction of DirectX, or Monogame or Unity for cross-platform, in the past. There still seems to be a lot of fragmentation from the handful of samples I've looked at so far; is there something like a canonical example of "the right way" to do things?
- pjmlp 9y ago
  Yeah, first thing you have to do is dynamically collect extensions on program startup. https://vulkan-tutorial.com/Drawing_a_triangle/Setup/Instance https://vulkan-tutorial.com/Drawing_a_triangle/Setup/Instanc...
  - exDM69 9y ago
    That's a bit dishonest way to put it. The situation with extensions has vastly improved w.r.t. OpenGL. In the link you provided, it only needs to enable the appropriate window system extension. It also prints out some info about other extensions but that is not required. It's a huge improvement that extensions need to be explicitly requested at init time. It's massively better than OpenGL, and API extensions can't be completely avoided in a multi-vendor cross-platform API without limiting to lowest common denominator.
    - pjmlp 9y ago
      It doesn't look much different from OpenGL multiple execution paths for each GPU, and possible workarounds when they aren't available. Specially given the amount of extensions that have been added since Vulkan was released.
planteen 9y ago
OpenGL ES 2.0 and higher cleans a lot of that up. Crufty old calls are removed. You simply include a header and link a library without the need for a complex loader (though there still are extensions).

by exDM69 9y ago

megaman22 9y ago

The multiplicity of ways to do everything in OpenGL was always a stumbling block for me in the past; it's been a big driver towards leaning in the direction of DirectX, or Monogame or Unity for cross-platform, in the past. There still seems to be a lot of fragmentation from the handful of samples I've looked at so far; is there something like a canonical example of "the right way" to do things?

pjmlp 9y ago
Yeah, first thing you have to do is dynamically collect extensions on program startup. https://vulkan-tutorial.com/Drawing_a_triangle/Setup/Instance https://vulkan-tutorial.com/Drawing_a_triangle/Setup/Instanc...
- exDM69 9y ago
  That's a bit dishonest way to put it. The situation with extensions has vastly improved w.r.t. OpenGL. In the link you provided, it only needs to enable the appropriate window system extension. It also prints out some info about other extensions but that is not required. It's a huge improvement that extensions need to be explicitly requested at init time. It's massively better than OpenGL, and API extensions can't be completely avoided in a multi-vendor cross-platform API without limiting to lowest common denominator.
  - pjmlp 9y ago
    It doesn't look much different from OpenGL multiple execution paths for each GPU, and possible workarounds when they aren't available. Specially given the amount of extensions that have been added since Vulkan was released.

planteen 9y ago

OpenGL ES 2.0 and higher cleans a lot of that up. Crufty old calls are removed. You simply include a header and link a library without the need for a complex loader (though there still are extensions).