OpenGL or DirectX 9 coding?

[K.I.L.E.R]

I wonder what is best to start off with?
I have had a fair bit of C++ experience and never had any trouble learning it either.

I want to start fiddling around with real 3D coding (IE: not using Darkbasic or any newbie based language).

Utter's AA Analyzer program inspired me, in a way that 3D coding doesn't have to be about games all the time, that there are uses other than games that benefit from 3D API's.

Enough beating around the bush, my point:
OpenGL or Direct3D?
Which is quicker to code in?
Keep in mind I want to be able to use shaders as well. Does OpenGL 1.4 have the same shader support as DX9?

Best place to start?
Prior learning/experience would be best before I start?

Thank You all for your help.

 

[Rodéric]

learn both pick up the one you prefer (or both).

I prefer OpenGL, but I recon that extensions are a bit annoying at long, and that DirectX9 has a few interesting integrated things.
On the other hand, DX change many things at each release, and don't even follow their own doc ^^

best do what I said in the first sentence.

 

[nutball]

Well, I've gone with OpenGL, but as I only code under Linux I didn't really have a choice Of course if you care about any platform other than Windows, then OpenGL is the way to go.

OpenGL has the advantage that hardware vendors can add their own extensions to expose all of the functionality of their hardware, whereas DX9 is controlled by Microsoft and this isn't possible. NVIDIA, for example, have said that the full feature-set of GeForceFX will only be exposed under OpenGL.

OpenGL has the dis-advantage that hardware vendors can add their own extensions to expose all of the functionality of their hardware, and they seem to quite enjoy doing this. They particularly enjoy doing so in a manner which is incompatible with their closest rival. Hence you end up with GL_ATI_blah_extension and GL_NV_blah_extension, doing the same(-ish) thing in different(-ish) ways. Fortunately over time the OpenGL ARB (Architecture Review Board) bang heads together and sort things out.

I can't answer whether OpenGL 1.4 has the same shader support as DX9, as I don't know DX9. It supports vertex programs and pixel programs (shaders in DX parlance), if that's what you're asking.

OpenGL 2.0 is bubbling along nicely, and looks like it might be quite good. It will implement a high-level shading language like Cg or the Microsoft one.

 

[KimB]

Well, Kiler, you're probably not going to be doing anything extremely advanced right off the bat, so the drawbacks of OpenGL shouldn't mean much. Personally, I'd recommend it. It's easier to get started in, and the documentation is much more complete.

Anyway, run over to www.opengl.org to get started. I'd personally suggest also looking at nehe's OpenGL tutorial website: http://nehe.gamedev.net/

Nehe's tutorials have also been ported to many other platforms, if you're interested in Linux or some other platform.

 

[Hyp-X]

Enough beating around the bush, my point:
OpenGL or Direct3D?

Do you want it to work it under any other OS than Windows? Than you have no choice.

If you wan't Windows only I'd reccomend D3D.
And don't worry if you're goals change later on it will be much easier to learn the other API once you learned one of them.

Which is quicker to code in?

I don't have too much experience but I'd say D3D. (Not everyone will agree with me though...).
Starters usually find it easier to code in OpenGL, but once you want more advanced stuff (like in your next question), you will get on much better with D3D.

Keep in mind I want to be able to use shaders as well. Does OpenGL 1.4 have the same shader support as DX9?

OpenGL 1.4 has no shader support.
But it has extenstions.
They are for the most part vendor specific so you'll likely end up doing your shaders multiple times for nVidia, ATI, Matrox, SiS cards.
There will be no way to test if it works on an ATI card if you only got an nVidia card or the other way around.

Best place to start?

For D3D get the SDK.
There's some D3D tutorial around, I've found a good link on a Rage3D forum, but it seems to be down right now.

 

[Arun]

For D3D get the SDK.
There's some D3D tutorial around, I've found a good link on a Rage3D forum, but it seems to be down right now.

Yeah, the basic DX9 tutorials in the SDK is what you should begin with.
In fact, AA Analyzer is so basic it's pretty much a modifed version of Tutorial 2. The code itself was very fast to write, the big difficulty was in finding triangles which are really badly aliased even at 4x AA.

But *please* don't look at the Donuts 4: Revenge of the Space Torus code in the DX9 SDK. I've never seen something so stupid!
If Windows is programmed in the same way, damn, I understand where the security holes are coming from!

There are bugs and things which any serious programmer wouldn't do to keep acceptable level of performances.
For example: the sky is rendered before anything else! The GUI is rendered after everything! And they're using the Z Buffer, so they've got no way to justify that.
Another thing: when you pause the game then unpause, the GUI remains dark just like when you you're paused. And loads of other similar things.
I really don't understand how MS even dared to release that thing without fixing so obvious things first... *sigh* I guess it didn't have much profit potential.


Uttar

 

[Hyp-X]

Here's a D3D tutorial: http://www.andypike.com/tutorials/directx8/

It's DX8 but the difference in DX8 and DX9 is not that big (especially at this level.)

 

[Runitai]

I'm going to go with an emphatic OpenGL. I've done work in both, and Direct3D never performed the way I want it to. With OpenGL, making things fast is usually a matter of putting them into a display list, which sums up to (pseudocode):

GLint myList = glGenList();
glNewList(myList, GL_COMPILE);

//insert drawing code here

glEndList();

Then whenever you want to draw that display list, you just call:

glCallList(myList);

For direct3d you have to do crazy things with indexed triangle strips, the syntax is just not intuitive at all, and you have to have a handle to your d3d device in order to do anything. Granted, this only works for static geometry. Also, with OpenGL, once the gl window is up, you can call GL commands arbitrarily. It's much easier to use OpenGL for simple rendering tasks, and it's easy to write classes that draw themselves. With Direct3D, you usually end up writing a wrapper that makes it so you never have to look at d3d, because d3d calls look just like any other Microsoft API call: ugly. If you don't write a wrapper you'll find yourself adding LPD3DDEVICE* pD3D to every constructor for every class that you could ever want to draw. After writing a wrapper, you'll have functions like drawHappyHippo(HappyHippo* woo) in your wrapper class.

In short, D3D is a lot more work to start with, it's a lot more work after you get going, it's slower 9 times out of 10, and while it is easier for shader stuff at first, when DirectX 10 comes out, you'll have to learn it all over again.

 

[Hyp-X]

I'm going to go with an emphatic OpenGL. I've done work in both, and Direct3D never performed the way I want it to.

The question is: who's fault is it?

For direct3d you have to do crazy things with indexed triangle strips,

I let you on a secret: you can use intexed triangle lists with mostly equal performance - much easier to use.

Of course if the concept of indexing is too complex to you - than I can understand why you have trouble writing fast code.

the syntax is just not intuitive at all,

For example:

D3D:

dev->SetTexture(stage, pTexture);

OpenGL:

glActiveTextureARB(GL_TEXTURE0_ARB + stage);
glBindTexture(GL_TEXTURE_2D, TexureID);
glEnable(GL_TEXTURE_2D);

Actually it's only that simple if you use 2D textures only...

and you have to have a handle to your d3d device in order to do anything.

So what?

Granted, this only works for static geometry.

So you don't use vertex-arrays in OpenGL? Or vertex-array-objects?

Also, with OpenGL, once the gl window is up, you can call GL commands arbitrarily.

I don't quite get your problem.
Are you worrider about BeginScene()/EndScene()?
It's just two lines more.
Actually almost every driver ignores them...

It's much easier to use OpenGL for simple rendering tasks,

Like drawing using post-transformed vertices?
(You know XYZRHW...)

and it's easy to write classes that draw themselves.

I've managed to write classes that draw themselves on D3D.
What's the difference.

With Direct3D, you usually end up writing a wrapper that makes it so you never have to look at d3d, because d3d calls look just like any other Microsoft API call: ugly.

Well, I'm not very fond of Microsoft API's in general.
But I don't think the difference between OpenGL and D3D is so dramatic.

If you don't write a wrapper you'll find yourself adding LPD3DDEVICE* pD3D to every constructor for every class that you could ever want to draw.

Why?
If you're so fond of OGL's global device context model, why not make your device pointer global?

After writing a wrapper, you'll have functions like drawHappyHippo(HappyHippo* woo) in your wrapper class.

I'm kindof confused about what you wanted to write here...

In short, D3D is a lot more work to start with,

Depends on where you start...

it's a lot more work after you get going,

Definately not true.
Hint: vendor-specific-extensions...

it's slower 9 times out of 10,

So far this wasn't my experience...
Maybe when ARB_vertex_buffer_object is ready and supported...

and while it is easier for shader stuff at first, when DirectX 10 comes out, you'll have to learn it all over again.

Hmm it took me half a day to completely port our game engine from DX8 to DX9 (and yes we use shaders too).
And that included learning.

 

[Humus]

In defense of OpenGL. The GL_ARB_vertex_program and GL_ARB_fragment_program provides a much better interface with fewer limitations and are much easier to code than the shaders in Direct3D.

 

[Rodéric]

Please don't turn this thread into yet another war between the two APIs, thanks.

 

[Simon F]

Just to add to what's been said ...

I don't quite get your problem.
Are you worrider about BeginScene()/EndScene()?
It's just two lines more.
Actually almost every driver ignores them...

But don't ignore them in your code. And only use them once per scene! If you disobey these rules you will be sworn at in the following manner : Example from the Abuse-a-tron

Unfortunately, there are a few poorly coded apps out there that don't obey these rules.

As Joe D' pointed out in another thread, sometimes** people see bugs and and blame them on "poor drivers" when in fact the drivers are simply trying to cope with rubbish from the application.

Update: Added Joe's actual quote to make him feel even better...:

On a side note...I'd just like to point this out as an example of how code "works" on architecture A, "break" in another architecture B, and then is subsequently blamed on "bad drivers on architecture B."

(** Not always, of course)

 

[Hyp-X]

(About Begin/End).

But don't ignore them in your code.

We don't.

I know they are very important on Deferred renderers.
It was kept in mind when making decisions about the engine.

The engine was coded on IMR cards, yet it worked flawlessly on KyroII cards once we tried it. (Unlike ...)

 

[Joe DeFuria]

** Sniffle **

I've been "sort-of-quoted" by Simon F....I feel all warm and tingly!

Edit: WOW! Now a direct quote. I've gone from warm and tingly to "hot and bothered...." 8)

 

[Goragoth]

Some thing else...

If you are interested purely in programming graphics I think the only real thing to consider is which style of API you prefer. Look at some simple example source of each and decide on the API that you think looks nicer or feels better for you after doing a few simple tutorials. If you are looking at coding a more complete program (read game) then you should certainly consider the fact that DX provides everything for you (Sound/Input/Networking/etc).

My personal opinion is that OGL is nicer if you just want mess around with 3D graphics programming and if you only want it to run on your pc the custom extensions are no problem, just learn the ones for your card, however for developing a full game I would go with DX because everything is standardized (no extensions) and you have a complete game API suite not just graphics. Also its worthy to note that (IMHO) Microsofts examples/tutorials tend to suck bad and that OGL has many nice tutorials on the web (e.g. NeHe's tutorials!!!) that should make it easier to pick up.

 

[Crusher]

There are bugs and things which any serious programmer wouldn't do to keep acceptable level of performances.
For example: the sky is rendered before anything else! The GUI is rendered after everything! And they're using the Z Buffer, so they've got no way to justify that.

I'm not going to defend the quality of Microsoft's examples, since I'm not terribly impressed with them myself (I think they're more for showing off than for being good examples of how to implement things). However, this specific issue you take with them is unfounded. Rendering sky-world-GUI in that order is a perfectly logical way to draw the scene. In fact, it's what I'm doing currently, and it works fine. Beginners need to worry more about getting things drawn than they do about making sure everything is sorted front-to-back, and other advanced forms of optimization. Since the sky is behind everything else, and the GUI is in front of everything else, it makes sense to render them as such from a learning perspective. Also, in situations where the sky is almost completely visible, and your HUD has transparency (neither of which are the case with that Donut demo unfortunately), it doesn't really matter what order they're drawn in.

Anyway, I think optimizations are where 90% of a programmer's salary is earned. I see no reason Microsoft should do all the work for everyone else and give it away. Beyond that, I agree with the rest of your comments about the quality of their examples.

 

[epicstruggle]

im throwing in my 2cents, . My graphics prof. always told us that you should learn graphics programming and not concentrate on a graphics api. if you know the principle of what you want to do, then the api most sutable for the application will be clearer. Given that, he would tend to use opengl as he liked to not be platform depedent.


later,

 

[K.I.L.E.R]

Now I am more confused than what I was when I started.

I useev-C++ 5 Beta 7
http://www.bloodshed.net/index.html

I had some trouble satrting off but I will keep trying.

Okay, I have looked through some direct 3d code and it is long (what did I expect?), I am hoping that OpenGL could cut down time.

I am only intrested in supporting my currnet video card which is a Radeon 9700 Pro.

 

[Simon F]

Okay, I have looked through some direct 3d code and it is long (what did I expect?), I am hoping that OpenGL could cut down time.

There are some useful example programs (some with OGL/D3D source) on the PowerVR Dev site ( http://www.pvrdev.com ). They're probably worth a try. I've no idea how they build with your compiler though.

 

[Hyp-X]

im throwing in my 2cents, . My graphics prof. always told us that you should learn graphics programming and not concentrate on a graphics api. if you know the principle of what you want to do, then the api most sutable for the application will be clearer. Given that, he would tend to use opengl as he liked to not be platform depedent.


later,

The best way to learn 3D graphics is to write a software renderer

I'm glad I started programming 3D back when there was no other choice.