Sign in to follow this  
ajmas

Why use D3D instead of OpenGL?

Recommended Posts

I have noticed a fair number of PC games these days use Direct3D instead of OpenGL. I would be curious to know what makes Direct3D more tempting than OpenGL for a games developer? Also, are there alternative cross-platform APIs that offer similar advantages as to those found in D3D? I don't intend for this to intend to turn into OpenGL is better than D3D type war, rather I would be interested in your reasons for choosing D3D over the alternative. Maybe links to indepth comparisons would be useful.

Share this post


Link to post
Share on other sites
I'm going to leave this open for now since it has a remote chance of staying reasonable and on-topic in this particular forum, but if anyone starts going off topic or ranting about the evils of a given API it'll be closed.

Anyways, to give one brief reason (which I posted with my closure of your lounge thread), the majority of games released for the PC are for windows and aren't intended to be ported to other PC platforms, so it doesn't really matter if they're harder to port. Also keep in mind that one of the most popular consoles out there (XBox) uses a version of DirectX.

Share this post


Link to post
Share on other sites
I use D3D for the D3DX library. It's massive, consistent, powerful, and already written and tested. What takes hours of glue coding in OpenGL is already built into D3DX. Sure there's libraries for a few things in OGL, but many of them are badly written, badly designed, or just generally strange...not to mention various licenses, leaving you to hunt down one that's actually acceptable.

Additionally, the managed libraries for DX are not merely a thin wrapper like Tao. They solve many of the core problems with D3D and overall lead to a much more structured architecture. So if I'm in a managed environment, I'll always prefer D3D.

Share this post


Link to post
Share on other sites
Check all the OpenGL/DX advantage and disadvantage/comparison charts. Then just ask yourself: "What do I want?", "What do I prefer", and use it. Just remember the obvious: if you want your game on Macs or Linux, use OpenGL.

On Windows, take your pick.

I, personally, use OpenGL. I have nothing against DX, I just use OpenGL, my preference.

EDIT: Yeah, look into wrappers too, depending on what your intentions are.

Share this post


Link to post
Share on other sites
For anyone who has touched on Java3D, does Direct3D play a similar role? Would it be considered to be at the same level or is D3D lower down. What I mean is that other than providing you with common functionality does it impose anything like a scene graph?

The reason I originally asked the question is simply to understand whether something like an OpenD3D would be worthwhile. For this to be the case Direct3D would need some sort of added value over the basic OpenGL, which it appears to do, given the replies so far. Has anyone attempted something of the sorts?

Share this post


Link to post
Share on other sites
Personally i use D3D because of its powerfulness, how its all easy to link to my appss, its advanced pre-builtin features like Pixel Shading and of course the main reason is because OpenGL is generally limited to 60fps. With that said i learnt OpenGL first and found it very easy to learn and yet still powerful, it is a great API for beginners and experienced programmers alike.

Share this post


Link to post
Share on other sites
Quote:
Original post by frupert
and of course the main reason is because OpenGL is generally limited to 60fps.


You definitely lost me there and made me go "what??". It's called vsync and not OpenGLs fault if certain vendors disable it per default for D3D but not for OpenGL in their drivers.

That said, I changed to D3D with version 8, when it stopped being a nightmarish waste of time. Enjoyed the luxury of having helper functions and libraries for almost everything, then made the fatal mistake of changing an app to version 9 when it came out. Then I decided I rather use my own or third party libraries and have an API that doesn't change half its interfaces with every version.

If you want all the extras and fast results (which I expect to be a major reason in commercial games) I'd suggest D3D, if you expect to insert the newest features during development and don't mind having to write/search a lot of libs for this and that I would use OpenGL. But in my opinion the answer to "why are most commercial games using D3D" is D3DX. So, when will we see a lib like that for OpenGL and give it a popularity boost?

Share this post


Link to post
Share on other sites
Right now I'm thinking about starting a project with friends and I'm wondering which API will be best for us so I'm giving a try at DirectX. We all know at least bits of OpenGL, I'm the only one that learned D3D, and even if we all know about one we are wondering which would be best. To help the decision between the two APIs I've decided to compare them... write a really simplified engine with a game (breakout clone), then I'll be able to see the difference. I haven't done the OpenGL version right now (I'm not finished with the DirectX one), but since I've had experience in OpenGL I can still make a quick comparison and/or give my observations.

I also like D3D because of the design which is "more" object compared to OpenGL where everything is global (many DirectX functions are global but many of the features are available in the interfaces). The interfaces found in DirectX helps me understand what I'm doing in other words, I prefer the device->SetTexture(...) way over the glBindTexture(...) way since I see on what object I'm working. This is not really something I'm goin to use in the decision because wrapper classes will do this trick quickly.

Also, DirectX seems to have the features implemented in it quickly and doesn't need some obscure extensions to load them. Over the years Microsoft really tried to get the game studios to choose their API and they implemented a lot of helper classes (like D3DX) and made a multimedia solution instead of only a graphic solution. DirectX seems better to me because of all what appears to be already there (like what is in D3DX) and that I won't have to deal with later (mostly extensions).

OpenGL is only a graphic library and DirectX is more like a multimedia library with input management (DirectInput). DirectX will also run on all PC running Windows and XBox, if you want more portability than that OpenGL seems to be the prefered way. Portability might be something good to have later, but not right now, we are aiming at PCs and want an API as complete as possible.

Also, since you have one "solution" for all that you don't have to worry about learning many obscure, baddly designed libraries or to deal with different licences. With DirectX, you deal with "one" thing (I mean that DX covers a lot more than GL) and it's available on all PC running Windows.

In the end, choosing between D3D or GL is choosing which you are more comfortable with and what will bring results faster. For me, choosing GL over DX would mean that I found a good helper library and a lib to deal with the extensions (or that want it to be portable), well designed and coded with a license compatible with what I'm doing (and free). Then I would probably make myself wrapper classes and make it the way I'd like to use it.


JFF

Share this post


Link to post
Share on other sites
This question tends to be asked quite a lot. The general idea between when to use either is simple. Some reasons you would want to use DirectX over OpenGL would be due to the fact that DirectX has many built in functions many of which handle mathematical operations. OpenGL is cross platform in that it can be used on Linux and Windows. DirectX tends to be mainly Windows and XBox orientated, there are ports to the Linux system but they are not quite well made.

OpenGL offers less mathematical functions its much more of a mathematical orientated API in my personal opinion and many will agree. You can do much more high complex things in DirectX, that require a lot more code in OpenGL but can be done in both. DirectX also utilizes COM, where OpenGL does not.

DirectX tends to be good for handling tasks in game programming where OpenGL is much more scientific.

Bottom line I see it is DirectX you can do many more complex things due it being very powerful, where in OpenGL you can do similar or the same, but it may require a lot more code that is already available in DirectX.

You can find more about them both on wikipedia:
OpenGL
DirectX

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
there is no need to change from ogl to d3d.

most people just choose one when they begin game-programming
and stick to it until the end of all days ;-)

the choice depends on what you want to do.

both are platform-independent.
d3d: windows, xbox xbox360
ogl: windows, linux (most distributions), mac

d3d has some things i like very much. especially the d3dx-functions.
allmost all drivers are prepared for d3d.
i cant say much about ogl, but i heard people complain about
the different librarys. some graphic cards may cause problems.

but many great games work with ogl quite fine, so it cant be that bad at all.


so i think both apis are good, you dont have to switch from one to another.

Share this post


Link to post
Share on other sites
Quote:
Original post by jff_f
I also like D3D because of the design which is "more" object compared to OpenGL where everything is global (many DirectX functions are global but many of the features are available in the interfaces). The interfaces found in DirectX helps me understand what I'm doing in other words, I prefer the device->SetTexture(...) way over the glBindTexture(...) way since I see on what object I'm working. This is not really something I'm goin to use in the decision because wrapper classes will do this trick quickly.

Actually, you could very eaisly argue that State-Based (a particuarly usable kind of "Global") is better than DirectX's Object-Oriented paridigm. Particularly because you can eaisly do OOP with both DirectX and OpenGL - but you can also program eaisly in other ways with OpenGL that DirectX makes much harder.

Share this post


Link to post
Share on other sites
Just a quick note, a few people here seem to think that DX is portable across PC and Xbox/Xbox360, it's not. I'm not sure about the 360, but the Xbox version of DX was different as it had specialised code.
DirectX is about as portable as a grand piano.

Share this post


Link to post
Share on other sites
Quote:
Original post by Andrew Russell
Actually, you could very eaisly argue that State-Based (a particuarly usable kind of "Global") is better than DirectX's Object-Oriented paridigm. Particularly because you can eaisly do OOP with both DirectX and OpenGL - but you can also program eaisly in other ways with OpenGL that DirectX makes much harder.


As I said it would be easy to make a wrapper so OpenGL reacts like DirectX so it's not what is making me want to use Direct3D. I'm also aware that making a wrapper to make DirectX react like OpenGL would be harder (really slower?)... (I've heard stories about game studios that wrote such wrappers because they couldn't stand DirectX's ways.)



Maybe I should explain more the reasons that make me think about using DirectX...

Having a tested helper library like D3DX that was designed with the API in mind (designed as being a part of it) by those who made the API, that I'm sure I will be having a lot of support if I ever need it is appealing.

The extensions frightens me a bit since I don't completely understand how the system works, not that I don't know how to use them but I don't really understand if an extension will always be backward compatible. I don't like the fact that I may be dealing with extensions specific to some manufacturers. I could just forget about these but it's all the new and interesting features available and will be made available in D3D soon (if not already). DirectX will always provide me the features I'm using since all the new releases are backward compatible this makes me feel more safe with this one.

Those are the main reasons I'm giving Direct3D a try and I think that the same thing happens for others. I have not lost faith in OpenGL and there is no NEED to change API but I found in Direct3D and its helper classes a more easy way to do the same using what is available in the library.

And this is only my opinion to explain what make Direct3D more tempting than OpenGL, opinions from others might differ.

JFF

Share this post


Link to post
Share on other sites
Quote:
Original post by frupert
and of course the main reason is because OpenGL is generally limited to 60fps.


This is infact the fault of the person writing the software [smile]
Its easy to get OGL to go faster than 60fps when v-sync is enabled, its just a matter of asking for it when you swap to fullscreen mode, just that most if not all tutorials never mention this perticular bit of the switch, only covering colour, width and height, and as no one appears to bother to research on their own they never work out how its done. (As you might have guessed, I did and I do know how its done, which is why it was added to the opengl window framework I wrote [grin]).

Quote:
Original post by Trienco
But in my opinion the answer to "why are most commercial games using D3D" is D3DX. So, when will we see a lib like that for OpenGL and give it a popularity boost?


*chuckles* well, give me time and I dare say I'll get to it [wink]

Share this post


Link to post
Share on other sites
Quote:
Original post by jff_f
DirectX will always provide me the features I'm using since all the new releases are backward compatible this makes me feel more safe with this one.


Backward compatible by simply including all previous versions. When I changed my app from Dx8 to Dx9 and had to change every single frigging lock function, because they changed the parameters to accomodate some new features (or maybe just to be a pita?) it didn't exactly feel all that "backward compatible". Extensions are always build on top of the existing thing. Nobody will go and say "hey, this new feature would be easier to implement if we change the way vertex buffer objects work and add 2 more parameters to glVertexPointer.

I don't know how well D3D would take it if half the app uses D3D8 and the other half uses D3D9. Not an issue if you start your project with DxX and finish it with DxX, but if you feel the sudden urge to port to DxX+1 to make use of a new feature you better have your D3D calls nicely encapsulated. And in the end it shouldn't really matter if you check for support of certain D3D features or support of certain extensions. If you try to use something the driver doesn't support they will both crash.

But then, having more or less advanced toys like progressive meshes without coding it all yourself is the kind of tempting and time (read money) saving luxury that is probably making it an easy decision in the commercial world. Or if you just want to get your program done. Though just using an existing engine might be an even plan than worrying about D3D or OpenGL.

Share this post


Link to post
Share on other sites
My $.02:
OpenGL, past the initialization and window setup part is, IMHO, easier to jump into. Not as in decently learn, no, JUMP into. The design philosophy of OGL (GLuint handles, let the driver implement in whatever way it likes, these handles could be indexes into an array, pointers, top secret codes, whatever) is better, again IMHO, than the DirectX object approach. In general, I find OpenGL to have more abstraction over the work done behind your back (GLSL uses varying modifiers to linearly interpolate vars, in short, tex coords. and NV's driver (didn't do much work on ATI) directly translates them into tex coords, and I think ATI also does that, as opposed to the shader programmer assigning them some TEXCOORD# semantic). The thing is, almost anything that can be done in one, can be done in the other, and that's a BIG almost. OpenGL has an advantage in the fact that not each draw call ahs to go into kernel mode (ring 0) and the ICD provider could manage an FIFO queue if he wants, but again, proper D3D programming, and SM3 instancing make this much less of a problem. The fact that MS also decides on the ASM instructions for shader models is too much intervention for me. It should be enough to just define the high level language, and let implementers be free. As for D3DX, it IS useful, but I'd hate to rate an API based on the helper functions the API provider issues. Yes, they're commonly used, but they aren't something to be held as a pro, or con, IMHO. In the end, think about what you'll need, what you'll learn faster, what's more suited with your coding style, and pick that. learn it good. period.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Backward compatible by simply including all previous versions. When I changed my app from Dx8 to Dx9 and had to change every single frigging lock function, because they changed the parameters to accomodate some new features (or maybe just to be a pita?) it didn't exactly feel all that "backward compatible"


and i'm sure i've heard DirectX 10 is an entirely new interface alltogether..

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by frupert
OpenGL is generally limited to 60fps.


No, it doesn't.

I use OpenGL for it's portability and wide girth of features that are lacking in D3D. I also use OpenGL because OpenGL is consistent and orthogonal design, whereas DirectX has changed so many times, it's hard to even imagine why they bother to even call it DirectX anymore. They change the API so often, and so many things break, that if you bought a book on it, most likely the code will *not work* and you will *not be able* to get the SDK for which the book's code was based on.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by Promit
I use D3D for the D3DX library. It's massive, consistent, powerful, and already written and tested.


There are plenty of libraries and Scene graphs for use with OpenGL that are just as good as D3DX in everyway, and mostly better as OpenGL is older and more mature than DirectX. Once you have your foundation set, you rarely need to worry about this anymore, and OpenGL just works consistently, whereas every iteration of DirectX breaks out of the box.

Share this post


Link to post
Share on other sites
Quote:
Original post by phantom
*chuckles* well, give me time and I dare say I'll get to it [wink]


Well, you better hurry then, because I will hold my breath and wait right here... and my fridge is way over there. You wouldn't want to be haunted by ghostly images of my starved carcass, would you?

All kidding aside, maybe something like that could be started as forum-encompassing gamedev project. It should have enough independent parts to allow for a couple small groups working on different things.

TextureManager/Loader
Geared towards gaming 3d file format
Math library
Mesh format
Loaders for typical file formats (in combination with above mesh)
Scenegraph (very specific and complex, but would top what d3dx offers)
Gui library (see above)

Might be interesting to see at which point helper libraries start turning into half an engine of their own. I know my last attempt did, when things started to become dependent on other things and seperate "use them or don't" modules weren't so seperate anymore.

I'd throw in a file format draft, even if it ended up a radically striped down 3ds format with uint chunk sizes to avoid the limitations (and 255-character file names). Data-type descriptor bytes instead of a dozen chunk types for all possible combinations, possibility to refer external files for submeshes, material libs, skeletons. Off topic.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by Trienco
Quote:
Original post by phantom
*chuckles* well, give me time and I dare say I'll get to it [wink]


All kidding aside, maybe something like that could be started as forum-encompassing gamedev project. It should have enough independent parts to allow for a couple small groups working on different things.



I have a ton of OpenGL stuff lying around I've written over the years. I learned some time ago, that modular engine development rules. The foundation of the GL layer is probably what most people would find most useful as it solves most of the problems that turn people off. But the solution, once found, will rarely need to be modified again, as newer cards get much easier to work with. I have trap tools for handling calls to unavailable extensions, material and shader rendering management, just about everything needed on a low-level. I have math libraries in C and X86 assembler, geometry loading, an obtuse but effective low-level file format that is fast to save and load and can snarf over a dozen file formats.

My scene graph is weak, but is parallel and I am working towards using PVM to distribute rendering on multiple machines over a network (or SMP) someday... ;-)

Maybe I would be willing to release this code for others to take as a foundation to build a better library from. Some of it is pretty old and ratty now but I haven't had a need to change it for years, it all works for my needs.

Share this post


Link to post
Share on other sites
Quote:
Original post by Trienco
TextureManager/Loader


Well, I'm working on a loader, although a few aux functions to make loading a bit simpler might be called for. If you've any input on the direction the library takes I'll be happy to listen.
Management for the most part falls into the domain of the program imo, however once I get a manager working I dare say I'll release the code to it,its just not that high on my list.

Quote:

Geared towards gaming 3d file format


Might be worth while, however it comes down to 'what formats would you want to support?'. A Lib which supported all of iD's model formats shouldnt be that hard todo. Its just a matter of presenting the data in a uniform way.

Quote:

Math library


Yes, this would be handy. Like the D3DX lib is going to need SSE, SSE2 and SSE3 optermised routines (Washu came up with a short cross product in SSE3 the other night in IRC and some code which could do two dot products at once). Its one of those things I'd probably get to in time, once I started needing it, however it might be worth looking into it now, once I've poked a couple of GTL based things.

Quote:

Mesh format
Loaders for typical file formats (in combination with above mesh)
Scenegraph (very specific and complex, but would top what d3dx offers)


I'm not overly sure this would be needed, however it cant hurt, I just wouldnt put it that high on my own personal priority list, thats all. Things like scenegraphs and mesh formats could be considered very domain specific. I'm not rejecting the idea, but I think having things like maths functions and image loaders probably should come higher in the chain.

Quote:

Gui library (see above)


JavaCoolDude has already donated a pretty cool GUI for free for people to use, a link to this thread exist in the OpenGL forum FAQ. I've got plans for it, but atm its not overly high on my 'todo' list either.. but I'll get there [grin]

Quote:

Might be interesting to see at which point helper libraries start turning into half an engine of their own. I know my last attempt did, when things started to become dependent on other things and seperate "use them or don't" modules weren't so seperate anymore.


See, I'd prefer to try and keep things as seperate as possible, you shouldnt need to use one part to get the benifit from another, depancies between libs could be pretty hellish if done wrong [sad]

Some time to sit down and draw up some specs/design ideas might be worth while..

Quote:

I'd throw in a file format draft, even if it ended up a radically striped down 3ds format with uint chunk sizes to avoid the limitations (and 255-character file names). Data-type descriptor bytes instead of a dozen chunk types for all possible combinations, possibility to refer external files for submeshes, material libs, skeletons. Off topic.


If you are willing todo it then I'm willing to look at it, anything to standise things would be nice.

Ofcourse, the problem with all of this is getting people to use it and not reinvent things left right and center.. *grumbles*

Share this post


Link to post
Share on other sites
I prefer DirectX, but I use both, I have a generic wrapper. I like the DirectX OO style more than the OpenGL way of doing things I find the extension system in OpenGL very messy and ugly.

Share this post


Link to post
Share on other sites
Quote:
Original post by phantom
Well, I'm working on a loader, although a few aux functions to make loading a bit simpler might be called for. If you've any input on the direction the library takes I'll be happy to listen.


Definitely going to have a look. DevIL is working fine, but feels like huge overkill. Usually my problem is deciding how much should be handled automatically to make it easy to use and how much should be flexible.

For example: Texture_handle textureFromFile(filename)
is easy to use, but lacking options to specify clamp modes, use of mipmaps, filtering etc.. so it's a candidate that always ends up with a lot of default parameters like (filename, min_filter=MIP_LINEAR, mag_filter=LINEAR, clamp=CLAMP) and too much overloading (cubemap from single file, seperate files, etc.)... and at some point I give up, accept that there are too many combinations and either ditch it or keep some functions for the common cases and do the rest manually.

But I guess "fixing" non-power-of-two textures might be useful. One of the few things where devIL is handy is resizing with different filters. What I usually do is checking if the lower power of two is within 20% of the original size instead of always increasing the size. A fix-function taking such a threshold to resize could be a bonus feature.

Quote:
Management for the most part falls into the domain of the program imo, however once I get a manager working I dare say I'll release the code to it,its just not that high on my list.


Manager in this case would be meant as a lightweight manager. Mine usually just keep a hashmap of loaded files and assigned texture ids to prevent loading the same texture over and over again. Mistake was to let it keep track of bound textures, because at that point it became mandatory to bind textures through the manager or it would get very confused. Only things I found myself needing is loading and releasing textures and getting the filename to an id (though only to save the model data).

Quote:
Might be worth while, however it comes down to 'what formats would you want to support?'. A Lib which supported all of iD's model formats shouldnt be that hard todo. Its just a matter of presenting the data in a uniform way.


Ah, grave mistake. id already has some formats geared towards games. Though actually it was the MD5 format that made me want to come up with something like that... just binary and with a tad more possibilities. Especially allowing more than one set of tex coords and any dimensions, plus I don't really like the "one set of vertex positions per assigned bone" approach. Lots of extra data, prevents interpolating transformations rather than transformed positions, extra work to do hardware skinning. Matter of taste though.

Quote:

Yes, this would be handy. Like the D3DX lib is going to need SSE, SSE2 and SSE3 optermised routines


SSE. I lost count how often I wanted to do a SSE optimized math lib and soon decided to either leave it to the compiler or someone more talented. Usually after 10 lines of code I use google, don't find anything free but blas, and decide that the compiler optimization has to be good enough (at least better than what I would write).

Quote:

Quote:

Mesh format
Loaders for typical file formats (in combination with above mesh)
Scenegraph (very specific and complex, but would top what d3dx offers)

I'm not overly sure this would be needed, however it cant hurt.


Not too interesting for serious use, as I guess most people will have their own specific requirements. But might be handy for prototyping or when you don't want something fancy and just need to get your 3ds, obj, xsi on the screen.

Quote:
Quote:

Gui library (see above)

JavaCoolDude has already donated a pretty cool GUI for free for people to use, a link to this thread exist in the OpenGL forum FAQ. I've got plans for it, but atm its not overly high on my 'todo' list either.. but I'll get there [grin]


Time to mention my list was just whatever came to mind and not sorted in any way. Basically I would sort them from low level to high level stuff (well, obviously, high level hardly works without the low level in place). I'll need to have closer look at this Gui, seeing how I just started on one for the gazillionth time. Even when I find libufo is pretty complete and offers most of what I need I still think "hah, but mine will allow to set callback functions in the xml file". In about one week it will do a lot of cool things but completely lack most basics because they are just too tedious to implement.

Quote:

ee, I'd prefer to try and keep things as seperate as possible, you shouldnt need to use one part to get the benifit from another, depancies between libs could be pretty hellish if done wrong [sad]


Definitely agree. When my font rendering lib required the texture manager to avoid texture binding confusion I noticed that my plan of a modular ogl framework was going south. The higher level helpers are a different beast, but the lower level modules should be as isolated as possible.

Quote:
If you are willing todo it then I'm willing to look at it, anything to standise things would be nice.

Ofcourse, the problem with all of this is getting people to use it and not reinvent things left right and center.. *grumbles*


Reinventing is part of the game. Always giving a better understanding of how things works and every once in a while allows to come up with a potentially better way to do it (I'm still dreaming of coming up with a way to do shadows that doesn't feel like a horrible hack and still slap myself for not pulling through with an idea to do terrain.. but then, it was much more relaxed to have someone else come up with geoclipmaps and skip the "how do I solve this"-part).

Share this post


Link to post
Share on other sites
at the moment on windows gl is 0-20% (depending on the app) faster than d3d ie
if i converted my app to d3d i would easily lose 20% performance.

keep in mind the ps3 uses gl. if the ps3 gets the marketshare its expected to (ps3 games sales greater than all pc+xbox360+xbox games sales combined)
by choosing the d3d u will be actually choosing the smaller market!

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this