6 ms·

Why not OpenGL 3.2+? It is capable of modern effects and pretty easy to use.

pjmlp 10y ago
Because for fonts, textures, windowing, effects, materials, requires the use of third party libraries outside the spec. Also it is stuck in a C world API, with each binding being a third party library with different degrees of coverage.
- shmerl 10y ago
  All of that is outside of the spec. That has nothing to do with 3D graphics. MS just lumped it all together and called it DX.
  - nl 10y ago
    I think that is kind of the point.
    - shmerl 10y ago
      Well, it's a counter point really, since all of that is unportable (without such kind of translation). As developers put it here[1]: "Don't make a game that depends on Direct3D. All the hard hard work is getting the thing to run with OpenGL". 1. https://www.gamingonlinux.com/articles/about-linux-games-being-delayed-a-chat-with-several-game-developers-and-porters.9491 https://www.gamingonlinux.com/articles/about-linux-games-bei...
      - euos 10y ago
        That's stupid. Competent 3d on Windows is DirectX. Competent 3d on Mac/ios is Metal. Competent 3d on consoles uses their propriatary API. So, what is the point of OpenGL portability? Between Linux and Android? You _will_ have to switch API if you are making anything worthy.
        shmerl 10y ago
        That's smart. Those who don't think about it in advance, are bitten by this later. Read the article above. Metal is Apple's lame attempt to tax cross platform graphics developers. That's exactly what is emphasized there.
        cwyers 10y ago
        The article you linked to is advice from people who port games to Linux on how to make games more portable. It's not advice on how to ship them on time, how to make them performant, how to minimize the amount of developer labor required to build them. Given what a small share of the market Linux is for games, developers have other priorities than what makes games easy to port to Linux. And it's not a chicken-and-egg problem; the Linux market for games isn't much smaller than the Linux market for any other commercial software.
        shmerl 10y ago
        Performance is orthogonal issue to portability. You can make it portable, and perform well too (using something like Vulkan and proper engine design). Linux gaming market is growing. Not sure about other commercial software in this context, but I'd guess it can indirectly be affected too, since bigger gaming market makes Linux desktop usage grow in general.
        klodolph 10y ago
        So, "Here, use a different API with worse developer support, and in return you get access to a market that's ~1-2% the size of the Windows gaming market?" I mean, I'm all for OpenGL. I use OpenGL. Hell, I develop OpenGL games on Linux and then port them to Windows afterwards (released ~10 made that way so far). But the choice to use it depends on what market you're going after.
        shmerl 10y ago
        Isn't it what MS is saying for DX12? Except Vulkan is not locked into MS only stuff.
Const-me 10y ago
Also on Windows, Direct3D is better supported. If you write an app based on Direct3D 9 or 11, it usually just works on any supported version of Windows. I once wrote an app that uses OpenGL 4.0 (this one: https://github.com/Const-me/GL3Windows https://github.com/Const-me/GL3Windows), and it only worked on half of my PCs. To make it work everywhere, I had to downgrade to OpenGL 3.0, and also implement S3 texture decompression on the CPU.
MaulingMonkey 10y ago
Console developers don't get much choice: You pretty much must use D3D9, D3D11, GNM(X), etc. Mobile's not much better: OpenGL ES for Android (which is a far cry from real desktop OpenGL - to the point that I consider it a completely different graphics API that just happens to confusingly reuse the names of some functions.) Maybe Metal for iOS. Real desktop OpenGL is one of the few graphics APIs I've never been forced to use - so why spend even a single dev-month porting to it? Even games with OpenGL render paths may work better using their Direct3D renderers on Linux via Wine! Even counting Linux/OS X, at this point I'm not even convinced OpenGL is actually the more portable API...
- jhasse 10y ago
  I've written an iOS app and the OpenGL code was (except very few ifdefs) identical to the desktop code. So I wouldn't say that ES is a completely different API, you can certainly reuse a lot.
  - MaulingMonkey 10y ago
    Not even our shaders went unscathed - no rectangular matrix support (mat4x3? nope!), mandatory precision specifiers (lowp-highp), no Uniform Buffer Objects. Can't even call glTexImage2D on ES 2 without perfectly fine OpenGL code failing - because format !== internalFormat is forbidden (read: documented "must be the same"), and you were a good explicit OpenGL citizen and asked for something as horrifically complicated as format=GL_RGBA and internalFormat==GL_RGBA8. Multiple render targets? Are you out of your mind? We can't have that - goodbye deferred rendering, hello old school forward rendering! Even your bread and butter - functions like glUniformMatrix3fv do things like just outright ignore the transpose parameter. This is extremely well documented: "Specifies whether to transpose the matrix as the values are loaded into the uniform variable. Must be GL_FALSE." ( https://www.khronos.org/registry/OpenGL-Refpages/es2.0/xhtml/glUniform.xml https://www.khronos.org/registry/OpenGL-Refpages/es2.0/xhtml... ) I swear I've reused more code between D3D11 and PS4 codepaths than between OpenGL ES and OpenGL codepaths, and the d3d11 and ps4 APIs don't share a single common function name betwixt them! I must assume going from OpenGL ES 2 to real OpenGL a bit easier - even if you're probably giving all the fast paths in the latter a wide berth in doing so. Or maybe OpenGL ES 3 is a bit closer to real OpenGL. But OpenGL ES 2 vs desktop OpenGL? They both render triangles, but beyond that, it's a crap-shot, and a lot of #ifdefs in my experience. Separate files, even. Not just a few. EDIT: s/codepaths/apis/, finish summarizing my thoughts.
AldousHaxley 10y ago
GL 3.x is my current go to for the case of needing simple immediate mode 3D rendering. But it's still Bring Your Own Matrices/Texture Loading/Text Rendering/Model Loading, and D3D9 + D3DX had that all in a nice package. Like I said, stitching this stuff together isn't the hardest thing ever, but it's nice to have a basic set of boilerplate that's idiomatically consistent and works out of the box.
douche 10y ago
Because OpenGL is a dumpster fire of conflicting information for a beginner. I've been looking for a decent opengl book for years, in vain. DirectX 9 was sort of the sweet spot, where the technology stabilized for a few years at something decent. Nonetheless, aside from dumping the useful parts of d3dx, DirectX 11 is a lot friendlier to work with.

pjmlp 10y ago

Because for fonts, textures, windowing, effects, materials, requires the use of third party libraries outside the spec. Also it is stuck in a C world API, with each binding being a third party library with different degrees of coverage.

shmerl 10y ago
All of that is outside of the spec. That has nothing to do with 3D graphics. MS just lumped it all together and called it DX.
- nl 10y ago
  I think that is kind of the point.
  - shmerl 10y ago
    Well, it's a counter point really, since all of that is unportable (without such kind of translation). As developers put it here[1]: "Don't make a game that depends on Direct3D. All the hard hard work is getting the thing to run with OpenGL". 1. https://www.gamingonlinux.com/articles/about-linux-games-being-delayed-a-chat-with-several-game-developers-and-porters.9491 https://www.gamingonlinux.com/articles/about-linux-games-bei...
    - euos 10y ago
      That's stupid. Competent 3d on Windows is DirectX. Competent 3d on Mac/ios is Metal. Competent 3d on consoles uses their propriatary API. So, what is the point of OpenGL portability? Between Linux and Android? You _will_ have to switch API if you are making anything worthy.
      - shmerl 10y ago
        That's smart. Those who don't think about it in advance, are bitten by this later. Read the article above. Metal is Apple's lame attempt to tax cross platform graphics developers. That's exactly what is emphasized there.
        cwyers 10y ago
        The article you linked to is advice from people who port games to Linux on how to make games more portable. It's not advice on how to ship them on time, how to make them performant, how to minimize the amount of developer labor required to build them. Given what a small share of the market Linux is for games, developers have other priorities than what makes games easy to port to Linux. And it's not a chicken-and-egg problem; the Linux market for games isn't much smaller than the Linux market for any other commercial software.
        shmerl 10y ago
        Performance is orthogonal issue to portability. You can make it portable, and perform well too (using something like Vulkan and proper engine design). Linux gaming market is growing. Not sure about other commercial software in this context, but I'd guess it can indirectly be affected too, since bigger gaming market makes Linux desktop usage grow in general.
        klodolph 10y ago
        So, "Here, use a different API with worse developer support, and in return you get access to a market that's ~1-2% the size of the Windows gaming market?" I mean, I'm all for OpenGL. I use OpenGL. Hell, I develop OpenGL games on Linux and then port them to Windows afterwards (released ~10 made that way so far). But the choice to use it depends on what market you're going after.
        shmerl 10y ago
        Isn't it what MS is saying for DX12? Except Vulkan is not locked into MS only stuff.

Const-me 10y ago

Also on Windows, Direct3D is better supported. If you write an app based on Direct3D 9 or 11, it usually just works on any supported version of Windows. I once wrote an app that uses OpenGL 4.0 (this one: https://github.com/Const-me/GL3Windows https://github.com/Const-me/GL3Windows), and it only worked on half of my PCs. To make it work everywhere, I had to downgrade to OpenGL 3.0, and also implement S3 texture decompression on the CPU.

MaulingMonkey 10y ago

Console developers don't get much choice: You pretty much must use D3D9, D3D11, GNM(X), etc. Mobile's not much better: OpenGL ES for Android (which is a far cry from real desktop OpenGL - to the point that I consider it a completely different graphics API that just happens to confusingly reuse the names of some functions.) Maybe Metal for iOS. Real desktop OpenGL is one of the few graphics APIs I've never been forced to use - so why spend even a single dev-month porting to it? Even games with OpenGL render paths may work better using their Direct3D renderers on Linux via Wine! Even counting Linux/OS X, at this point I'm not even convinced OpenGL is actually the more portable API...

jhasse 10y ago
I've written an iOS app and the OpenGL code was (except very few ifdefs) identical to the desktop code. So I wouldn't say that ES is a completely different API, you can certainly reuse a lot.
- MaulingMonkey 10y ago
  Not even our shaders went unscathed - no rectangular matrix support (mat4x3? nope!), mandatory precision specifiers (lowp-highp), no Uniform Buffer Objects. Can't even call glTexImage2D on ES 2 without perfectly fine OpenGL code failing - because format !== internalFormat is forbidden (read: documented "must be the same"), and you were a good explicit OpenGL citizen and asked for something as horrifically complicated as format=GL_RGBA and internalFormat==GL_RGBA8. Multiple render targets? Are you out of your mind? We can't have that - goodbye deferred rendering, hello old school forward rendering! Even your bread and butter - functions like glUniformMatrix3fv do things like just outright ignore the transpose parameter. This is extremely well documented: "Specifies whether to transpose the matrix as the values are loaded into the uniform variable. Must be GL_FALSE." ( https://www.khronos.org/registry/OpenGL-Refpages/es2.0/xhtml/glUniform.xml https://www.khronos.org/registry/OpenGL-Refpages/es2.0/xhtml... ) I swear I've reused more code between D3D11 and PS4 codepaths than between OpenGL ES and OpenGL codepaths, and the d3d11 and ps4 APIs don't share a single common function name betwixt them! I must assume going from OpenGL ES 2 to real OpenGL a bit easier - even if you're probably giving all the fast paths in the latter a wide berth in doing so. Or maybe OpenGL ES 3 is a bit closer to real OpenGL. But OpenGL ES 2 vs desktop OpenGL? They both render triangles, but beyond that, it's a crap-shot, and a lot of #ifdefs in my experience. Separate files, even. Not just a few. EDIT: s/codepaths/apis/, finish summarizing my thoughts.

AldousHaxley 10y ago

GL 3.x is my current go to for the case of needing simple immediate mode 3D rendering. But it's still Bring Your Own Matrices/Texture Loading/Text Rendering/Model Loading, and D3D9 + D3DX had that all in a nice package. Like I said, stitching this stuff together isn't the hardest thing ever, but it's nice to have a basic set of boilerplate that's idiomatically consistent and works out of the box.

douche 10y ago

Because OpenGL is a dumpster fire of conflicting information for a beginner. I've been looking for a decent opengl book for years, in vain. DirectX 9 was sort of the sweet spot, where the technology stabilized for a few years at something decent. Nonetheless, aside from dumping the useful parts of d3dx, DirectX 11 is a lot friendlier to work with.