Direct3D- why is it better at...

What makes OpenGL better than Direct3D, or is D3D better? I’ve heard its buggy and unnecessarily confusing. Has anyone here used D3D? What is it like?

Smell like ****!! terrible headache with D3D, try it if ya want to lose your time.

Thank you for your ambiguous remarks.

I started on Direct3D, but it was a very painfull experience. I spent a month trying to get all the features of my hardware card to work, and when I did get it to work, it would not on other machines.

I then started to use OpenGL, and right from the start I was able to get coding. It only took one month for me to code a complete 3D engine. By choice I like to develop in linux, and OpenGL is the ONLY option.

Most people that support Direct3D say that it is faster than OpenGL, what they fail to realize is that it is not the API that is faster but the driver. Many hardware developers in the past have really pushed Direct3D as their primary interface to their hardware. They would do OpenGL second best, and so the drivers would be buggy and slow. Hardware is hardware, and it should run the same speed no matter what API you use. It is up to the hardware developer to make solid Direct3D and OpenGL drivers.

The future is OpenGL because it allows the hardware developers to create their own features and add it to a solid API through extensions. Direct3D’s feature set is controlled by Microsoft and the API can change from version to version.

If that doesn’t convince you then here is a suggestion: allocate the same ammount of time and develop in Direct3D then OpenGL. See what you think…

/skw|d

Hey skw|d by the way what is the definition of a 3D engine?

n/m I saw your other reply

[blockquote]The future is OpenGL because it allows the hardware developers to create their own features and add it to a solid API through extensions. [/blockquote]

Umm… you ever heard of QueryInterface()?

Direct3D is annoying because of all those
parameter structs with confusing field names
and continuously varying recommendations for
which combinations of feature flags should
be passed in. You pretty much have to wrap
the D3D API in something easier to use which
reflects the needs of only your application.

Once you have gone through that pain, I hear
that Direct3D is faster and had more hardware
support than OpenGL, because that’s where the
hardware manufacturers optimize first. Also,
the development of OpenGL has slowed down a
lot compared to D3D; there are features
in D3D 7.x and up which are not commonly
supported in OpenGL. The reason? the OpenGL
extensions are typically vendor specific.

If vendors could quickly fold good extensions
into ARB with little squabbling, and keep the
OpenGL architecture moving forward, perhaps
OpenGL would indeed be able to dislodge D3D.
But don’t count on it.

You did not quote both of my sentences, my point was that Microsoft controls the feature set, where as in OpenGL the vendor does. This gives the vendor freedom to innovate instead of having to wait for Mircosoft to implement it. QueryInterface() tells you what features of the Direct3D API it supports with hardware acceleration, it does not allow you to add features.

Direct3D is a new player compared to OpenGL. GL has been around for a long time with SGI workstations. Direct3D can be confusing, but I will say that in the future it might mature into a nice easy to use API like OpenGL.

Like I said before, it is not the API that makes the difference in speed, but the drivers that access the hardware. What does matter is development time, how long does it take to write an OpenGL application compared to a Direct3D application. The time you save by coding in an easy to use API such as OpenGL, the more time you have to research and implement optimizations and features into your graphics pipeline, where the real speed comes from.

…there are features in D3D 7.x and up which are not commonly supported in OpenGL. The reason? the OpenGL extensions are typically vendor specific.

So Direct3D features are not vendor specific? If you use multipass in Direct3D and your hardware card does not support it, then you will be using Direct3D.dll to do your multipass rendering instead of the Direct3D library on the hardware card. You will have pretty bad performance. Features have always been vendor specific regardless of the API.

Rushing extensions into an API will only make the API more complicated then it needs to be. As far as I am concerned, OpenGL does not need new features integrated into the API until nearly all vendors support that feature.

/skw|d

Thats cool, i guess i probly won’t concern myself with learning D3D instead of OpenGL.

Hi,

I’m new to GL and D3D and I’m confused with your remarks. Any programmer don’t want to learn a language that won’t be use on the market 2 year later, so I wonder :

Which of the 2 have more future ???

I heard also that Microsoft labs are merging GL and D3D in one to get more specific rendering options…

So guys please help, what is my future by learning one or the other ???

Dave

Both of them will have a future. Here you ignore that the same opengl functions can be used on Linux which means that if Linux market develops the OpenGl market develops. And now Loki, 3dfx … try to make OpenML that is something like DirectX. Look at Unreal Tournament… and you will see the future of OpenGl. I supose that at least 4 years since now OpenGL will survive.

NewROmancer

“So Direct3D features are not vendor specific? If you use multipass in Direct3D and your hardware card does not support it, then you will be using Direct3D.dll to do your multipass rendering instead of the Direct3D library on the hardware card. You will have pretty bad performance. Features have always been vendor specific regardless of the API.”

im no expert with d3d but ive always thought that if a card couldnt do multipass then it then with d3d it just ignored it and drew white squares , nothing?
ive asked this question before but never got a reply to it

Any card can do multipass rendering, I think you are thinking of single-pass multitexuring. If you try to do single-pass multitexturing on a card that does not support it in D3D, at best you will get an error code returned to you when you draw, at worst you will get random crap drawn for your texturing and even possibly freeze the system (I’ve had that happen on hardware when trying to exceed the card’s capabilities accidentally).