16 ms·

D3D9 is my all-time favorite 3D API. It was at that sweet spot of being powerful enough that you could do stunning things with it (the Xbox 360 generation is ef

D3D9 is my all-time favorite 3D API. It was at that sweet spot of being powerful enough that you could do stunning things with it (the Xbox 360 generation is effectively D3D9-level hardware), and it was simple enough that amateurs and hobbyists (and high school kids, as I was at the time) could dive in and get stuff on the screen relatively quickly. D3DX had some handy helper libraries for loading models, doing transforms, and loading textures. I get the benefits afforded by subsequent iterations, and nowadays Vulkan and D3D12, but their interfaces are so optimized toward specialists, and it would be nice if more was in place to cover that middle ground use case between "I don't need a full-on 3D game engine, but I don't need to worry about low level GPU stuff either." Of the new APIs out there, I feel like Metal is the only one approaching layperson usability, and it's trapped in the world of Mac and iOS. Of course you can stitch together something that looks like an open source equivalent of the old D3D9 SDK yourself from things like glm and AssImp, but it's nice to have all that in one package.

garaetjjte 9y ago
Why not OpenGL 3.2+? It is capable of modern effects and pretty easy to use.
- pjmlp 9y 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 9y 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 9y ago
      I think that is kind of the point.
      - shmerl 9y 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 9y 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 9y 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 9y 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.
- Const-me 9y 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 9y 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 9y 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 9y 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 9y 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 9y 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.
Merad 9y ago
Doesn't a 3D graphics (not game) engine like OGRE or Irrlicht fill this void? I don't know if either one supports DX12/Vulkan yet, but I imagine they will in the not too distant future.
- Jare 9y ago
  I'm thinking more like bgfx, which is a cross platform API to access vertex and index buffers, textures, rendertargets, shaders and render states. Primitives like models, sprites, fonts, etc are up to you but the repo contains examples with extra utilities for those things.
  - AldousHaxley 9y ago
    bgfx looks really cool, thanks for letting me know about it!
- AldousHaxley 9y ago
  Those are higher level scene graphs. D3D9 was an immediate mode API with some helper libraries, so you still were in control of your app's rendering architecture.
yuhong 9y ago
Which also reminds me of https://news.ycombinator.com/item?id=9193521 https://news.ycombinator.com/item?id=9193521
pandaman 9y ago
D3D has always been a low-level API and D3D9 is no exception. The D3D9 just supported really simple hardware where pixels were pushed through a rigid pipeline one primitive at a time. Interestingly, Xbox 360 was already beyond DX9, it had real shader units and shader stages (i.e. the same unit could execute both pixel and vertex shader instructions) and even ability to write data back from a shader (if you wanted to use shader to process non-pixel data on the DX9-level hardware you still had to write the output as pixels because the color/depth buffer was the only output of a shader). So X360's graphics library extended DX9 a lot to support that hardware.
badsectoracula 9y ago
Same here, but replace D3D9 with OpenGL 2.x or "compatibility profile" as kids call it these days. Basically the entire OpenGL instead of the crippled "core profile" that was originally made to give a chance to troubled implementors (coughATIcough) make something that works (and failed, while we still ended up with the schism). Fortunately this is still supported in its entirety by all sane desktop implementations and at least Nvidia has said that they will always continue supporting it. The only sad marks are Apple and Mesa, but Apple seems to have abandoned the OpenGL ship and Mesa (or a fork) will hopefully implement it at some point. And in the meanwhile there is Regal, although i'm not sure how complete that is.
- microcolonel 9y ago
  I find that OpenGL ES 3.0 hits the GL 2.x sweet spot for me. Main reason I prefer it over desktop 3.0 is that it doesn't require the use of vbos, which always seem to complicate simple programs (even though I keep being told that I can just set one up and bind it, then forget about it). I especially like that it's hands-off wrt a lot of things like matrix manipulation and geometry optimization. It gives you an opportunity to think about these things clearly and get an optimal solution without having to port all of your matrix code out of somebody else's library.
- vedranm 9y ago
  If you are talking about OpenGL compat profile, Mesa will not go beyond 3.0. You might or might not be able to convince the project to change that with patches, I am not sure what's the attitude on that. If you are talking about D3D9, for Gallium driver (relevant ones are r600, radeonsi, nouveau), there is Gallium Nine: https://wiki.ixit.cz/d3d9 https://wiki.ixit.cz/d3d9
  - badsectoracula 9y ago
    Yeah i am considering at some point to try and see what would take to add support for the compatibility profile. I do not see a reason to not have it considering that the functionality is mostly there (and AFAIK there is even an environment variable that sort-of allows the creation of compatibility profiles, it just doesn't fully work). If nothing else, not having it makes the Mesa implementation inferior to the proprietary ones.
breakingcups 9y ago
The original Xbox also ran D3D9. After getting my hands on the XDK for that box I had a lot of fun with it, I see your point regarding the sweet spot.
nonsince 9y ago
Vulcan blows open the doors for anyone to create a library with the power and ease-of-use of DX9, rather than it being tied to OS vendors.

garaetjjte 9y ago

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

pjmlp 9y 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 9y 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 9y ago
    I think that is kind of the point.
    - shmerl 9y 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 9y 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 9y 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 9y 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.
Const-me 9y 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 9y 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 9y 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 9y 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 9y 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 9y 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.

Merad 9y ago

Doesn't a 3D graphics (not game) engine like OGRE or Irrlicht fill this void? I don't know if either one supports DX12/Vulkan yet, but I imagine they will in the not too distant future.

Jare 9y ago
I'm thinking more like bgfx, which is a cross platform API to access vertex and index buffers, textures, rendertargets, shaders and render states. Primitives like models, sprites, fonts, etc are up to you but the repo contains examples with extra utilities for those things.
- AldousHaxley 9y ago
  bgfx looks really cool, thanks for letting me know about it!
AldousHaxley 9y ago
Those are higher level scene graphs. D3D9 was an immediate mode API with some helper libraries, so you still were in control of your app's rendering architecture.

yuhong 9y ago

Which also reminds me of https://news.ycombinator.com/item?id=9193521 https://news.ycombinator.com/item?id=9193521

pandaman 9y ago

D3D has always been a low-level API and D3D9 is no exception. The D3D9 just supported really simple hardware where pixels were pushed through a rigid pipeline one primitive at a time. Interestingly, Xbox 360 was already beyond DX9, it had real shader units and shader stages (i.e. the same unit could execute both pixel and vertex shader instructions) and even ability to write data back from a shader (if you wanted to use shader to process non-pixel data on the DX9-level hardware you still had to write the output as pixels because the color/depth buffer was the only output of a shader). So X360's graphics library extended DX9 a lot to support that hardware.

badsectoracula 9y ago

Same here, but replace D3D9 with OpenGL 2.x or "compatibility profile" as kids call it these days. Basically the entire OpenGL instead of the crippled "core profile" that was originally made to give a chance to troubled implementors (coughATIcough) make something that works (and failed, while we still ended up with the schism). Fortunately this is still supported in its entirety by all sane desktop implementations and at least Nvidia has said that they will always continue supporting it. The only sad marks are Apple and Mesa, but Apple seems to have abandoned the OpenGL ship and Mesa (or a fork) will hopefully implement it at some point. And in the meanwhile there is Regal, although i'm not sure how complete that is.

microcolonel 9y ago
I find that OpenGL ES 3.0 hits the GL 2.x sweet spot for me. Main reason I prefer it over desktop 3.0 is that it doesn't require the use of vbos, which always seem to complicate simple programs (even though I keep being told that I can just set one up and bind it, then forget about it). I especially like that it's hands-off wrt a lot of things like matrix manipulation and geometry optimization. It gives you an opportunity to think about these things clearly and get an optimal solution without having to port all of your matrix code out of somebody else's library.
vedranm 9y ago
If you are talking about OpenGL compat profile, Mesa will not go beyond 3.0. You might or might not be able to convince the project to change that with patches, I am not sure what's the attitude on that. If you are talking about D3D9, for Gallium driver (relevant ones are r600, radeonsi, nouveau), there is Gallium Nine: https://wiki.ixit.cz/d3d9 https://wiki.ixit.cz/d3d9
- badsectoracula 9y ago
  Yeah i am considering at some point to try and see what would take to add support for the compatibility profile. I do not see a reason to not have it considering that the functionality is mostly there (and AFAIK there is even an environment variable that sort-of allows the creation of compatibility profiles, it just doesn't fully work). If nothing else, not having it makes the Mesa implementation inferior to the proprietary ones.

breakingcups 9y ago

The original Xbox also ran D3D9. After getting my hands on the XDK for that box I had a lot of fun with it, I see your point regarding the sweet spot.

nonsince 9y ago

Vulcan blows open the doors for anyone to create a library with the power and ease-of-use of DX9, rather than it being tied to OS vendors.