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.

[Chalnoth]

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 (http://www.upstartx.com/abuse/abuse.cfm)

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! :D

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

[Goragoth]

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. :shock:

I use:Dev-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.

[nAo]

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

[Philibob]

I just came here to ask the same question that K.I.L.E.R asked :shock:

I think I'm going to try to learn both languages, but for DirectX9 I need a directX 9 card so it looks like I'll have to buy one.

[epicstruggle]

I think youll enjoy learning both at the same time. This way youll see how they compare. I personally think OpenGl is the way to go. but try them both.

later,

[MDolenc]

I think I'm going to try to learn both languages, but for DirectX9 I need a directX 9 card so it looks like I'll have to buy one.
You don't need DX9 card to do DX9... You'll need it if you want to do pixel shaders 2.0+ fast. Vertex shaders 2.0+ have good software fallback.

[Philibob]

When learning DX9 or OpenGL, how good do you have to be with C++ ?

[Humus]

Basic knowledge should get you far. OpenGL would be easier since it's not object oriented.

[Snyder]

Basic knowledge should get you far. OpenGL would be easier since it's not object oriented.

Hmm. To be honest, my graphics programming experience is limited to a crappy gouraud/phong object renderer in Java done in my CG courses, so I don't know if D3D or OpenGL is better.
But: Once one has grasped the concept of object oriented programming - isn't it much easier to program with, especcially when the programs grow larger?
Ever since it had made click in my head and I really understood OO programming (ok... this claim could be a bit exaggerated :wink: ), procedural programming was getting more and more tedious for me.

[pcchen]

Actually, I think both D3D and OpenGL are not object oriented. You don't want to do inheritance with D3D objects, generally. So the COM interfaces are just like handles, although I think D3D is more "modular" than OpenGL. Of course, for a low leve API it is not necessary to be object oriented.

[darkblu]

Actually, I think both D3D and OpenGL are not object oriented. You don't want to do inheritance with D3D objects, generally. So the COM interfaces are just like handles, although I think D3D is more "modular" than OpenGL. Of course, for a low leve API it is not necessary to be object oriented.

actually a low level 3D API is nice _not_ to be oo. but d3d's authors realized that only about dx6. i shudder at the recollection of light "objects", material "objects" viewport "objects", and various other "objects" which populated d3d prior to that time. i recall when porting our game engine from dx6 to dx7 the codebase almost halved in size and readability jumped reciprocally just from dropping those "objects" :idea:

[pcchen]

Actually, I decided to not touch D3D6 (and previous D3Ds) just for the same reason :)

[fresh]

Go with GL. I have to use both for work, but for my own personal programs I always, always, always use OpenGL. It's so much cleaner and you can get a program up and running much quicker. You also don't have to worry about all sorts of interfaces changing on you when you go from one version to the next. D3D has come a long way (anyone remember execute buffers?! *cough*), but it still lags behind in user friendliness IMHO.

[DeanoC]

This is just my IMHO

If you new to this stuff and on Windows go with D3D.

The D3DX support library is very good (you can load just about any image format in 1 line). There is a wizard to create a complete framework, the debug DLL will catch alot of mistakes. You have effect files with HLSL which helps get a feel for what states, etc do.
Another bad thing for newcomers to OpenGL is the confusion IHV extensions can get you into.

If you more experienced, it doesn't really matter - both have good and bad points. At the actual hardware level they are largely the same, OpenGL has the advantage of IHV extension which is nice for real cutting edge research.

[Captain Chickenpants]

As a point on the C/ C++ debate. Bear in mind that most drivers are written in C for performance reasons, as C++ often has a lot of overhead associated with it.
For learning the ins and outs it really only matters which you find easier to understand.

CC

[DeanoC]

As a point on the C/ C++ debate. Bear in mind that most drivers are written in C for performance reasons, as C++ often has a lot of overhead associated with it.
For learning the ins and outs it really only matters which you find easier to understand.

CC

How many times does this have to be said! :roll:

There is no performance overhead for C++, there are certain overheads for particular features of C++. C++ will often produce BETTER code than C (mainly due to stricter typing and clever use of templates). There is a cost for vtables, exceptions etc but if you don't use them you don't pay for them.

Even on PS2 which really hurts when using C++ features, you can use C++ alot of the time. Drivers use C (and ASM) for compatibility issues (drivers have often been around a long time and run on multiple OS's etc), expertise issues (driver writers are often not comfortable with C++) and the main reason is simply that it would gain them nothing. If you don't need OO why force it in? (there are lots of code, that doesn't need OO)

[Captain Chickenpants]

Sorry perhaps I should have said that their are overheads for some of the feaures in C++ that make things easier.
The problem is that unless you know what features do have a cost, and which ones don't then you can can inadvertantly use them.
A lot of the impression of slow C++ comes from when it was just a preprocessor ontop of a C compiler.

:)

[Luke Philpot]

I personally recommend OpenGL for starting out since it is much easier to get into and there are HEAPS of tutorials on the web. Also, alot of coders you bump into are OpenGL coders (not that I'm saying that there isn't alot of DirectX coders ;)).

Plus, once you understand OpenGL, there's alot of ARB extensions you can play around with (however, I advise staying away from vendor-specific extensions unless you are writing multiple code paths).

[Hyp-X]

Actually there comes a point in every programmers life, where it's getting too complicated to go on without OOP.
Simple projects are easy to manage without it, but as complexity grows you will need it or you will drawn in the code.

That means that typically hobby programmers do NOT need OOP, as those programs are rarely that large and using OOP for them are just too cumbersome.

That's also why it's hard to teach what OOP is good for - unless you give a larger than half a year long project as an example. ;)

Note, that I talked about OOP, not C++.
C++ is just one of the most popular choice of OOP programming, because once you learnt C it's the easiest to transition to.

It is possible to write OO code in plain C (X Window System) but it's somewhat painful and theres less type safety