We already had this discussion and it was I who suggested Direct3D 11 to you.
Yes it works in mysterious ways. Create a texture, and then a resource view, and then a target view? What’s all this jazz?
I had assumed you were going to base your decision off what would be more relevant to your future. All platforms are slowly switching to a Direct3D 11 model. Windows Vista SP1, Windows 7, Windows 8, Xbox One, and
PlayStation 4 are already there. Yes, even Sony, competitor of Microsoft, uses Direct3D 11 (99% anyway). Microsoft will be around longer than you will be alive, but it doesn’t really matter because Sony proves it is the future of graphics whether Microsoft is here or not.
Even OpenGL is switching to the Direct3D 11 model. They are just trying to do it while sticking to a state machine and keeping as much back support as they can.
Direct3D introduces a feature such as constant buffers and OpenGL follows suit. No other graphics API (Nintendo DS Nitro, Nintendo 3DS GR, PlayStation Portable native, PlayStation Vita native, PlayStation 3 native, Xbox 360 Direct3D 9, all mentioned above) use a state machine or the especially
problematic bind-to-edit mechanism. Recent extensions (and the future standard) of OpenGL are also trying to
get away from the bind-to-edit model, acknowledging it as a flaw.
If I had known you were going to choose based on which is easiest to learn, I would have recommended Direct3D 9.
In terms of
ease to learn, Direct3D 9 and OpenGL are fairly similar, but Direct3D 9 isn’t exposed as a state machine and is better documented.
As I mentioned the first time you asked this question, OpenGL’s only selling point is that it is cross-platform, but
that really isn’t the case.
Even Minecraft apparently did not support certain Intel cards.
You will have fine support on Mac OS X and Linux, but it will be hit-and-miss on Windows.
Based on our previous discussions, I retract my suggestion for Direct3D 11 and suggest Direct3D 9 instead. Being object-oriented, a lot of it just makes more sense and is easier to grasp (something to which you already admitted).
And to quote John Carmack, “…DX9 is really quite a good API level. Even with the Direct3D side of things, where I know I have a long history of people thinking I’m antagonistic against it. Microsoft has done a very, very good job of sensibly evolving it at each step—they’re not worried about breaking backwards compatibility—and it’s a pretty clean API. I especially like the work I’m doing on the 360, and it’s probably the best graphics API as far as a sensibly designed thing that I’ve worked with.”
The bit about them not being afraid to break backwards compatibility is something I have also been considering as the main reason for many of OpenGL’s current and future problems. OpenGL could really make big progress if they would be willing to just release a clean new API in which you simply know the whole time you are using features from this version and only this version. Nothing deprecated or poorly supported or something that will cause it to go into software mode (as pixel buffers are known to do).
This is one thing OpenGL ES 2.0 does right. It’s still a state machine and uses the bind-to-edit model, but it’s a compact API with no feature support used just as carry-on. They don’t try to just give you the
option of using shaders, they
force you into it. And that is a
good thing.
In fact, despite being a state machine and bind-to-edit, if OpenGL ES 2.0 is an option for you I would recommend learning it equally as much as I would recommend Direct3D 9. And I would
definitely recommend it before learning desktop OpenGL.
L. Spiro