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.
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:
- VERY easy to learn basics, but yet has the ability to become VERY VERY powerfull in the advanced.
- Open platform, will run on anything with an windowed OS, (Win32, Mac, Linux, Beos, etc)
- 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.
- HIGHLY adaptive. Through the use of ARB extensions, all the ‘latest and greatest’ ‘stuff’ can be supported on various cards.
- NOT com based.
- The list goes on.
OpenGL Cons
- Cant think of any.
DirectX Pros
- Xbox is driven by DirectX.
- Number 1 was about it.
DirectX Cons
- NOT open platform, win32 ONLY.
- Syntax changes with EVERY update.
- Hell MS couldnt even get it to run on NT4.0,(how sad is that).
- 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.
- 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.
If I could, I would mod you up as Insightful.
Nooooooooooo ! Not the ol’ ogl-vs-d3d thread again !
- 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.
- 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.
- 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).]
“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.
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.
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.
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.
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.
Allow me to take this subject off topic. 
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
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 :/).
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).]
(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:
- creation of GL contexts, without requiring any window
- standard context managment (like MakeCurrent, ShareLists)
- binding frame-buffer-object to a window
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.
edit … not constructive …
[This message has been edited by pleopard (edited 08-13-2002).]
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).]
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. 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
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).]
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.