PDA

View Full Version : Detailed OpenGL vs. DirectX Comparison



emres
08-08-2002, 11:49 PM
Hi, I'd like to find a detailed technical comparison between OpenGL and DirectX. It can be based on your personal experience as a programmer, or you can direct me to some related web address.

Thanks in advance.

dabeav
08-09-2002, 03:51 AM
Well, once a month 'on the average' there is a VERY in depth discussion between OpenGL, and DirectX within the OpenGL forums. Simply do a search, and you should find most of what you want to know. But if you want some of my opinion here it is.

OpenGL Pros:
1. VERY easy to learn basics, but yet has the ability to become VERY VERY powerfull in the advanced.
2. Open platform, will run on anything with an windowed OS, (Win32, Mac, Linux, Beos, etc)
3. The syntax dosnt change, opengl is currently at verstion 1.4, with all the versions able to work withone another, and the syntax has stayed the same throughout, so old code will work with new.
4. HIGHLY adaptive. Through the use of ARB extensions, all the 'latest and greatest' 'stuff' can be supported on various cards.
5. NOT com based.
6. The list goes on.

OpenGL Cons
1. Cant think of any.

DirectX Pros
1. Xbox is driven by DirectX.
2. Number 1 was about it.

DirectX Cons
1. NOT open platform, win32 ONLY.
2. Syntax changes with EVERY update.
3. Hell MS couldnt even get it to run on NT4.0,(how sad is that).
4. COMPLICATED syntax based on com. It takes like 200 lines of code, to theorize the possible existance of a container to hold a god damned triangle.
5. Brought to you by the creaters of the buggiest software known to man.

(Oh by the way, if you are really compairing the 2 it is unfair, because OpenGL is STRICTLY Graphics, and DirectX is graphics, sound, input, etc; BUT I get around this limitation by using Opengl (graphics) devIL (image loading for OpenGL) OpenAL (sound) GLUT (Input), All of which use OpenGL syntax, so there is NO need to learn anything totaly new, and there ALL open platform) All of these combined, make DirectX look like crap.

Nakoruru
08-09-2002, 07:53 AM
If I could, I would mod you up as Insightful.

Morglum
08-09-2002, 08:14 AM
Nooooooooooo ! Not the ol' ogl-vs-d3d thread again !

Korval
08-09-2002, 09:25 AM
4. HIGHLY adaptive. Through the use of ARB extensions, all the 'latest and greatest' 'stuff' can be supported on various cards.


That isn't even true. You need to use vendor-specific extensions to get the "'latest and greatest' 'stuff'". The ARB is very slow at creating ARB extensions for functionality.


4. COMPLICATED syntax based on com. It takes like 200 lines of code, to theorize the possible existance of a container to hold a god damned triangle.
5. Brought to you by the creaters of the buggiest software known to man.

Sure. This isn't an unbiased comparison. Honest.

If you don't like COM and Microsoft (which you apparently do not), maybe you should say that, as a way to provide full disclosure, before making a comparsion between a Microsoft technology and something else.

[This message has been edited by Korval (edited 08-09-2002).]

JacekPoplawski
08-09-2002, 09:29 AM
"Hi, I'd like to find a detailed technical comparison between OpenGL and DirectX. It can be based on your personal experience as a programmer, or you can direct me to some related web address."

DirectX works only on one type of operating system, OpenGL works everywhere. Period.

okapota
08-09-2002, 10:54 AM
i must say, that opengl might be portable, but your application itself is not, so i dont see what the big deal about the portabilty. anyway, directX is very simple once you get the hang of it, and D3DX is like a dream to a demo developer. while i do like some of opengl's way to implement stuff, directx is still convinient. and, with opengl's condition today, with all the shader stuff, its much better to use dx8, sorry, but thats my opinion. until ARB_Fragment_Shader or what ever comes out.

zeckensack
08-09-2002, 10:55 AM
I picked up a point from knackered and I think he's right:

Pro Direct3D (or DX Graphics or whatever ...)

Whenever there is some kind of new feature, the interface is exactly the same for all cards. PS 1.1 is PS 1.1 is PS 1.1. Okay, PS 1.4 is another matter, but it's not as bad as ATI_fragment_shader vs NV_register_combiners* and NV_texture_shader*. The common functionality works in exactly the same way.

And I recently found a source of major gripe about OpenGL which almost made me port my whole damn project to D3D:
In some areas, the level of abstraction for basic stuff is just overdone.
You can't instruct your card to create a triple buffered rendering context. You can't reliably control swapping methods, because GL just lacks the proper definitions.
That's a pro for D3D, because it can.

I'm still doing OpenGL btw.

*Aaron*
08-09-2002, 01:00 PM
You can't instruct your card to create a triple buffered rendering context. You can't reliably control swapping methods, because GL just lacks the proper definitions.

It's been said a million times, but I'll say it again: Setting up the buffering scheme and swapping buffers is NOT part of OpenGL. You must use platform-specific code or use GLUT etc. If you cannot do tripple buffering on Windows, this is because Microsoft chooses not to support it.

Korval
08-09-2002, 06:09 PM
It's been said a million times, but I'll say it again: Setting up the buffering scheme and swapping buffers is NOT part of OpenGL.

Perhaps not currently, but it should be. You'd think a graphics library would handle something like this. If you went and wrote a software 3D graphics API, I'm certain that, as part of it, you would include such simple frambuffer controls. It makes since for OpenGL to handle this aspect of the graphics, because it controls this aspect of the graphics.

V-man
08-10-2002, 05:01 AM
Allow me to take this subject off topic. http://www.opengl.org/discussion_boards/ubb/smile.gif

What's the reason for having some things not part of GL :

swapBuffers
setting pixel format
choosing pixel format
sharelist
and all the others.

Is it a question of concept (that it doesn't belong in gl, or technic -> the driver alone can't handle these tasks.)

V-man

Nakoruru
08-10-2002, 08:57 AM
I think its a matter of concept. You should notice that all the functions you mention require a window system specific argument of some sort. The idea (and a correct idea I believe) is that these types of functions are better left to the OS people, and that designing a portable windowing system is too limiting and inhibits innovation. Just look at GLUT, its extremely basic, but if you try to go any further you end up designing a whole new GUI.

Direct3D is free to use HWNDs and HDCs and HPALETTEs all it wants because its not portable. It is free to have a set of functions for querying screen modes and changing resolutions because its focused on games and, again, its not portable. It can have concepts like 'losing' a device and 'exclusive mode' because that is the way windows works, but is that how everything else works? Its perfectly OK for direct3d designers to make these decisions because its what works in Windows, but OpenGL cannot make such design decisions for everyone because its supposed to be portable.

However, I think the proposal for the ARB to take control of WGL for GL2 is the right one and should have been the way it was from the beginning. Continue to have window system specific functions for each OS, but put control of it with the ARB. The Unix people are the only people who won't have a problem with that however. They are used to agreeing to a common standard (Posix, X, GLX, etc.) but Apple and Microsoft probably will want to continue to have control.

Window system functions should not be a part of OpenGL, but they should be in the control of the same standards body as OpenGL. I don't think a new ICD2 mechanism requires that Microsoft support it, however, it does require their support if it is to ship with Windows (big deal :/).

zeckensack
08-10-2002, 10:05 AM
Originally posted by Korval:
Perhaps not currently, but it should be. You'd think a graphics library would handle something like this. If you went and wrote a software 3D graphics API, I'm certain that, as part of it, you would include such simple frambuffer controls. It makes since for OpenGL to handle this aspect of the graphics, because it controls this aspect of the graphics.

The mechanism is there. It's called ARB_pixel_format.

The only problem is that ARB_pixel_format is incomplete as it's mostly used as a vehicle for pbuffers. And that's a shame.

[This message has been edited by zeckensack (edited 08-10-2002).]

MZ
08-10-2002, 10:20 AM
(Aaron) Setting up the buffering scheme and swapping buffers is NOT part of OpenGL
I realy hate when people say "feature A is not part of GL", when all what it really means is "I think feature A shouldn't ever become part of GL". These are 2 different meanings. You can say "is GL" or "is not GL", only to describe current state of GL, but you are trying to display it as a kind of "proof" that the state "should" or "should not" ever change. Please give arguments instead of superstitions. I think it is quite easy to prove that, for example, OpenGL should not ever handle sound or input. But process of setting up the frame buffer IS graphics task, so you may not assume that "it is NOT GL" as obvious fact.

Nakoruru,
Open GL 2.0 proposal shows it is possible to define interface allowing creation of frame-buffer-object without touching wgl/glx. Unfortunately, this only applies to offscreen frame-buffer-objects (pbuffer equivalent). Visible frame-buffer-objects (despite they don't really differ from offscreen ones) are still left to be created outside GL. IMHO this is mistake.

Buffer, or frame-buffer object is nothing but well abstracted resource, just like texture or display list today.
This abstraction could allow to create visible frame-buffer-object exactly the same way as offscreen one, again, without touching wgl/glx. Creation of "abstracted" frame-buffer-object is just request for set of properties (like bit counts), none of which is window system dependent, you don't need to supply any HWNDs or HDCs here.

The only true window system dependent part should be binding frame-buffer-object to a window.
Wgl could query requested frame-buffer's properties, and do internally SetPixelFormat without exposing any pixel format details.

Summing it up, I think wgl/glx should be reduced to:
1. creation of GL contexts, without requiring any window
2. standard context managment (like MakeCurrent, ShareLists)
3. binding frame-buffer-object to a window

JD
08-13-2002, 01:51 PM
On setting up 3D, dx7 d3dx lib was easiest followed by dx8.1 then opengl. I've done all three plus dx5, dx6 com setups.

If you want to dev on linux then opengl is what you want. If you don't care about multi-platform then your app will dictate which way to go. There are things in d3d that I wished opengl had and vice versa. I'm working with dx8.1 because it has features I need. There is almost zero com in d3d 8.1. One function i.e. Release() that decrements reference count of the object being manipulated. In my 3D editor/engine I deal with lot more then gfx code such as code organization and oop. Demo coders however might prefer opengl because they can use card's special functions right away w/o waiting on dx to catch up. Then again, dx has entire mesh library functions helpful for making characters. Your apps specs will dictate which one to use. Lot of gl extensions are making their way into gl 1.4 core so gl is also moving forward.

pleopard
08-13-2002, 07:18 PM
edit ... not constructive ...


[This message has been edited by pleopard (edited 08-13-2002).]

Hull
08-14-2002, 12:19 AM
Simply:

The API that gives the users the best portability choices, will win. The market will soon be flooded by Linux controlled environments and Linux controlled hardware, so get use to it.

Choosing OS is the highest priority because noone really wants MS crap. Anything that is forced upon us, for profit, will be crushed.

Everything that isnt for free is crap, unless it is really good and called for.

This ends all discussions on MS vs The World topics.

So, bye bye MS, it was nice but now its Linux and the next generation of Anti-MS systems to take control.

--=== THE END ===--

*end music*
*credits*



[This message has been edited by Hull (edited 08-16-2002).]

DelNeto
08-14-2002, 07:49 AM
I'm programming with DirectX since it's come out ( not so long, about four, me be five year ago ). I was used DirectX in a lot of my programans some times for improve interface effects ( DirectDraw or Directx 8 with textures ) and some times for smart data visualisations. All from my DirectX world are so good and enoth to me, than the things come to change and the Linux come out and more and more time becomes to be used for my customers. What about me now, how to provide in Linux what i have been providing to my customers ? Tha answer come from www.opengl.org. (http://www.opengl.org.) With OpenGL i can do all things that i did with DirectX and got a plus, that was important at dinossauru's era and become to be very but really very important today and in the future, ( me be i never had seen it before, i was blinde, and Windows was the light to me, i was wrong ) it's calling portability.

Ok let's stop philosofy and go to the point.

DirectX:

If you do all the things in programming for Windows and are used to Win32 api and MFC. DirectX is the market choice ( think about your customers, they paid you ).

OpenGL:

If you need portability ( Linux in mind ) OpenGL is for you. But remenber OpenGL is just a graphical library, you must be portable in all directions ( libs ).

All you can do in DirectX you can do in OpenGL. The choice is a more strategical than technical at the moment.

Now i'm porting all my application from DirectX to OpenGL. I really whant not to do this but the market forces me. I need to sell my programs, becouse they pay my bills. Of couse if i had a crystal ball to see the future i never was did my programs with DirectX. Well is time to change. At now i'm very reppy with OpenGL, it's small and fast.

no more,

DelNeto

*Aaron*
08-14-2002, 08:14 AM
I would like to respond to the argument that DX frequently incorporates new features directly into the API whereas GL uses extensions and the core spec is updated less frequently. If I'm not mistaken, you must still query your driver's capabilities, for example, if you are using vertex or pixel shaders. So how is this that much different from using a GL ARB or EXT extension? And just because a new version of DX comes out, that doesn't mean that all video card manufacturers will immediately have drivers for it.

In response to MZ: By saying that setting up the frame buffer IS not part of opengl, I meant that the lack of tripple buffering is not a shortcoming of GL, it is a shortcoming of WGL (and an intentional one at that). But the GL spec was written by the world's leading graphics experts, so if it IS not part of the spec, then it probably shouldn't be.


P.S. DelNeto, I'm glad you're "reppy" with OpenGL. (Sorry, I couldn't help myself.)

[This message has been edited by *Aaron* (edited 08-14-2002).]

Korval
08-14-2002, 09:06 AM
I would like to respond to the argument that DX frequently incorporates new features directly into the API whereas GL uses extensions and the core spec is updated less frequently. If I'm not mistaken, you must still query your driver's capabilities, for example, if you are using vertex or pixel shaders. So how is this that much different from using a GL ARB or EXT extension?

Therein lies the problem. It takes much longer for the ARB to come up with an extension that can be agreed upon and everyone can use than it does for Microsoft to create an appropriate interface for something.

Take vertex programs, for example. There are two (soon to be 3) competing vertex program extensions. They both offer the exact same functionality, just in different ways. So, why do we have 2? Why did it take the ARB a good year to come up with ARB_vertex_program when D3D has had them for a year?

The fundamental problem is that a standard-by-commitee can never be as fast as a standard-by-fiat. Microsoft can impose changes in D3D fast enough to keep up with hardware changes (and, in some cases, actually dictate hardware changes). The ARB is always a year behind.

knackered
08-14-2002, 09:11 AM
So how is this that much different from using a GL ARB or EXT extension?

ARB and EXT aren't so bad.
But all other vendor specific extensions are a problem. REASON: They all have different interfaces and data requirements. D3d has single common interfaces to all stages of the pipeline.
If you only used ARB and EXT extensions then you wouldn't be doing any per-pixel effects in OpenGL, even though the cards have the ability - even now a new version of OpenGL has been released (1.4) there still is no common interface to per-pixel programability.
It's a big minus for OpenGL.
Then there's the lack of a Vertex Buffer equivalent in OpenGL. NV VAR and ATI VOB are radically different.

*Aaron*
08-14-2002, 11:23 AM
These are good points. But in the case of vertex and pixel shaders, what good is a common interface, when the programs themselves are vendor-specific? It appears Microsoft has yet to address this issue. At least the ARB has a working proposal for a common shading language (3dLabs' HLSL).

And how many cards currently have full support for DX 8.1?

Jurjen Katsman
08-14-2002, 11:45 AM
Programs aren't vendor specific in DX. There are more advanced programs which require more advanced hardware, but if hardware supports pixelshader 1.4 it supports ps1.0 until 1.3 as well. Same goes for vertexshaders.

If you want to write code that works on all hardware you use the version that works on all hardware, makes perfect sense. If you want more advanced features for a particular card you use the more advanced version, and it will work on all future more advanced hardware just the same.

The OpenGL2.0 language doesn't address any of this at all. It just states a language and you can assume that whatever you do will always work. To what extend this will turn out to be true remains to be seen.

And as someone else already pointed out, 'vertexbuffer'-ish systems in GL are still a mess. VAR on NVidia, VAO on ATI, etc.

pcbill
09-11-2002, 10:32 PM
If you created a report from your search about the OpenGL vs. DirectX comparison would you send me at stud1002@di.uoa.gr ?

Thanks

Ozzy
09-11-2002, 11:19 PM
This good damn old thread! :))

okay..

from the (employed) coder point of view.........>
When i was working for the gaming industry i was forced (mainly) for commercial reasons to use Dx. :( In fact, at that time (and i don't think that things have change) most of the PC game devs were done with and for the Windows platform with Dx and all the big stuff. Right, distributors also prefer products which are Dx based even if the top hits like Q3 and sequels have been done from the begining with OpenGL.
The result of this was a complete lost of time with f**cking headaches while rewritting & rewritting & rewritting the rasterlib with the latest Dx beta(1,2),Final versions of the worst 3D API ever written by a human being. (oopss ;)


from the (unemployed) coder point of view...>
It's always possible to escape from the MS purgatory. Just give a try to OpenGL. :) and it will for sure lead you to success in the world of 3D. OpenGL has been tremendously well designed by SGI engineers a few years ag! This amount of time just make the GL API a mature API which is robust and is definitely the best state machine ever coded.
Moreover, OpenGL constraints are well thought, frame buffer, texture management and dynamic copies, limited lights are just there to help you to focus on what will be the most efficient solution. OpenGL is *not* lying in term of functionalities! it is a big mistake to think that everything is possible whitout a cost or repercuted penalties. (eg old DDraw mixed D3D).

Enough of my poor bulls.h.i.t.s!
i hope that you get it! i still don't know exactly what the future GL2.0 will look like.
But if you're working on your own or if your company has nothing against OpenGL just give it a try. It is definitely straight to learn!
Also don't think that Dx is the *only* valuable solution for Win32 development of 3D,soundy,padded-joysticked-moused,networked-computerised,fishy prgs! ;) There are tons (well i'm a bit optimistic here) of free,non-free,non googled referenced libraries that can do the job for that and which can also support multiple platforms!

Finally, (and i'm not a JCarmack evangelist) JC has said in the past that 'there were no good technical reasons to use D3D'. The context has changed for sure but D3D is D3D, Microsoft is still @redmond and JC knows is job for sure.

(stupid joke)
find the mistake-> http://www.microsoft.com/billgates/default.asp
(end of stupid joke)

the worst is about to come no?.
(is it a joke?)


[This message has been edited by Ozzy (edited 09-12-2002).]

tfpsly
09-11-2002, 11:49 PM
D3D vs GL again...
Well JC himself said that if he was starting to use a 3D api today, he was not sure what choice he would make.
The 2 apis are so equivalent today.

what good is a common interface, when the programs themselves are vendor-specific?
Well you can have program that are not that vendor specific. (Ok there're VAR vs VAO. On the other hand GL2/GL1.4 vertex programs are comming out).

GL pro: works on many os. GL+SDL for exemple ~ DX, but working under win, lnx, mac and so on (even ps2, but this "gl implementation" can only be used for very fastly done maquet, not for final project).

If you don't care about this, well make your choice on your personnal preference, try one or the other and stop trolling.

John Jenkins
09-12-2002, 04:41 AM
I do business applications. It a bit more difficult to put text on the screen than DirectX. I like the simplicity of assigning vertices with OpenGL. Every one of my errors with directX had to do with that stupid buffer that I loaded. Also, OGL is alot less bitchy compared to D3D. What I mean is that the syntax is so simple that most of my programs run the first time. If I have any bugs in the program it is from my logic and not from OGL.
The main difference is the discussion forums. I tried to participate in the MS newsgroup for directX. I found that the MS experts that replied to questions were arrogant assh*les. The only advice I was ever given was to go look at the SDK examples. I am a beginner. The 200 page dolphin program is a bit too much for me.

henryj
09-12-2002, 08:54 PM
Hey Hull

what planet do you live on? I'm a MAC guy and I hate Microsoft with the best of them but even I don't believe the crap you spouted. Do you really think that or are you just flame bating?