opengl

Many reasons, the 2 main ones in my opinion being that OpenGL has been left behind constantly in terms of features and is constantly doing catch up to DX (this wasn't always the case) and the fact that ~97% of the PC game market runs Windows, so portability is really not an issue.

other

There are lots of reasons, but as with any choice of technology (e.g. Windows vs Linux, Java vs C#...) you're going to have to weigh up the factors important to you and decide based on that.

In addition to Kwizatz's points, the one key advantage D3D seems to have is its ease of use. The programming model (mostly true for v9, definitely true for v10/11) is incredibly clean by comparison - quite simply, its easier to write code against. Secondly, the tools, samples, documentation, support (from MS, IHV's, community..) are generally more plentiful and complete.

For me personally, and obviously I have a bias, being able to cleanly, uniformly and concisely express my graphics application is a huge win. I've done some OpenGL coding and I found it a chaotic and messy experience - I spent as much time fighting the API/technology as I did solving my problem, which is simply not good enough in this day and age.

When there isn't a clear winner on features (yes, D3D has a slight edge but you can argue via extensions), performance and X-Platform isn't a motivator then simple ease of use and speed of development will reign king.


hth
Jack

Quote:

I've done some OpenGL coding and I found it a chaotic and messy experience

My experience is quite the opposite as I found directx messy and chaotic. I'm sure that is just because I'm used to opengl. If I started using directx I'm sure I would get used to that too.

I guess it just depends on what you are comfortable in using.

I must agree, our proprietary Graphics Engine at work was built in DX9 and whenever I look at the source code it is a complete mess, however when I look at my own OpenGL code it looks much neater (probably bias).

Also, portability is a key factor, even if you don't think you need it now, you may need in the future, which is the problem we're facing at work where we may want to start shipping our software on Linux machines.

Quote:

Original post by AndyEsser Also, portability is a key factor, even if you don't think you need it now, you may need in the future, which is the problem we're facing at work where we may want to start shipping our software on Linux machines.

If portability is a big factor, then you need to support multiple rendering backends, at which point OpenGL and D3D are just a few out of many.

Quote:

Original post by swiftcoder Quote: Original post by AndyEsser Also, portability is a key factor, even if you don't think you need it now, you may need in the future, which is the problem we're facing at work where we may want to start shipping our software on Linux machines. If portability is a big factor, then you need to support multiple rendering backends, at which point OpenGL and D3D are just a few out of many.

There is no reasn for having a OGL and DirectX both inside of an engine. They both do the same exact thing. and will render the same. the only thing difference is having opengl or directx rendering it. So creating a game for portability means just use opengl, and not need to have both because that basically is just adding more bloat to the engine instead of adding more functionality and a complete waste of time. But thats just my opinion.

Quote:

Original post by xZekex There is no reasn for having a OGL and DirectX both inside of an engine. They both do the same exact thing. and will render the same. the only thing difference is having opengl or directx rendering it. So creating a game for portability means just use opengl, and not need to have both because that basically is just adding more bloat to the engine instead of adding more functionality and a complete waste of time. But thats just my opinion.

Tell that to the guys at Ogre3d [smile].

[double posted by accident, stupid entarweb]

Quote:

Original post by Kwizatz Tell that to the guys at Ogre3d [smile].

I think they already know. But isn't those just plugins? But like on professional games. who's going to really care if its has directX or Opengl based except for all the fanboys.

But iirc on OGRE, you can either support one or the other.

Another factor is how familiar/comfortable you are with COM interfaces, the win32 libraries, and all that jazz. There are subtle differences in D3D that make it seem more win32-ish. As an example, D3D uses specific functions to return state information and does so in (often large) structs. On the other hand OpenGL gives you a few general functions that returns a single state value. If you're already comfortable with Windows programming you probably won't notice the difference too much, but if you aren't it does make a difference.

Subjectively speaking, if you are starting from scratch OpenGL definately feels easier. Just create a new C file, a couple of lines of window/GL initialization code, and you're good to go. At the minimum, you'll only need to link to your windowing library (on top of the c-runtimes of course).

Quote:

Original post by xZekex Quote: Original post by Kwizatz Tell that to the guys at Ogre3d [smile]. I think they already know. But isn't those just plugins? But like on professional games. who's going to really care if its has directX or Opengl based except for all the fanboys. But iirc on OGRE, you can either support one or the other.

Especial “professional“ (we cook with the same water too) games use an API abstraction layer as they are developed with consoles in mind. So even if you plan to release on Windows and Mac OSX it is quite common to use Direct3D for Windows and OpenGL for the Mac. The reason for this is that you have no choice on the Mac but on Windows Direct3D is the superior system. This has nothing to do with ease of development as professional developers need to be able to master any API. It’s just the quality of the environment. Direct3D drivers cause less end user trouble then OpenGL drivers as one example.

You may also note that the PC and XBox are the only real DirectX platforms.
Every other platform (PC, Phones, PSP, PS3/PS2, Wii) has some variant of OpenGL for the graphics backend.

Quote:

Original post by Demirug But iirc on OGRE, you can either support one or the other.

Especial “professional“ (we cook with the same water too) games use an API abstraction layer as they are developed with consoles in mind. So even if you plan to release on Windows and Mac OSX it is quite common to use Direct3D for Windows and OpenGL for the Mac. The reason for this is that you have no choice on the Mac but on Windows Direct3D is the superior system. This has nothing to do with ease of development as professional developers need to be able to master any API. It’s just the quality of the environment. Direct3D drivers cause less end user trouble then OpenGL drivers as one example.[/quote]

That is a biased statement.

Quote:

Original post by KulSeran You may also note that the PC and XBox are the only real DirectX platforms. Every other platform (PC, Phones, PSP, PS3/PS2, Wii) has some variant of OpenGL for the graphics backend.

The XBox Direct3D is different from the PC version and I would not call the native PS3 API a OpenGL variant. The OpenGL ES for PS3 doesn’t count as it is not useable for real games.

At the end of the day every platform its own 3D API and you are back to the need of an abstraction layer again.

Quote:

Original post by xZekex That is a biased statement.

Biased from the professional game development point.

If OpenGL would work as well as D3D on the PC there would no need for companies like Blizzard to write an additional Direct3D renderer beside of the OpenGL one they do for the Mac.

Quote:

Original post by xZekex Quote: The reason for this is that you have no choice on the Mac but on Windows Direct3D is the superior system. This has nothing to do with ease of development as professional developers need to be able to master any API. It’s just the quality of the environment. Direct3D drivers cause less end user trouble then OpenGL drivers as one example. That is a biased statement.

Biased how? I don't think anyone who has wrestled with OpenGL drivers on Windows will deny that D3D drivers are rock solid by comparison. OpenGL also has this massive problem that you can't detect what level of hardware you are running on, and end up with transparent, performance-killing software fallbacks.

Preferring one API to the other is of course a matter of bias, but it is concrete fact that D3D offers better functionality in at least a few areas, and that the drivers are more reliable.

Microsoft have done their part to kill the PC game industry for all non Windows Operating systems. When making games for a PC, portability isn't much of an issue, so DirectX will do that fine for most. CAD programs on the other hand do need to be portable and often end up being written in OpenGL, also, graphics utility programs don't often need the extra functionality that DirectX offers over OpenGL. I've not used OpenGL much at all, I didn't find it better or worse than DirectX, but that being said I stopped using it very quickly and stuck with DirectX, better to learn one and learn it well, than learn half and half of two and have lower quality software for indy devs, hobbiests and people who enjoy graphics programming.

As far as ease of use goes, I'm using D3D10 now for our renderer and I don't like how messy it is. Our OpenGL renderer on the other hand is very clean and straightforward.

Just my opinion, don't kill me please: the problem is that Microsoft's idea of abstraction doesn't make things any more high level or intuitive. I just find the API very far fetched and not intuitive at all.


Why are we supporting D3D in our renderer, you may ask. For Windows, of course. Like the posters above said, Direct3D is just rock solid in Windows.

My view on things:

- DirectX10 is ahead in features
- DirectX10 is superior on windows
- OpenGL is almost on par with DX10 in features but is always 1 step behind unfortunately
- OpenGL has a very simple and straightforward API without any ridiculous, farfetched abstraction.