But take a look at a Hello World Example of both before you make a decision! ;)

A Hello World example is about the worst possible way to judge an API or language.

My experience was that OpenGL (1.X though) was waaaay easier to get up and running and rendering a few triangles, but actually working with it was a pita compared to working with Direct3D (9.0c). It was mostly small things, such as math libraries, texture loading and font rendering IIRC. It was several years ago, but I can imagine some of it being the same due to cross platform and licensing issues.

It's neither of these. It's just that these things are out of the scope of a graphics API. They have never and will never be part of OpenGL. Note that D3D11 (and partially D3D10) went the same way, essentially removing all this bloated D3DX stuff. The only really useful remains were moved to XNAMath, which became largely API independent.

Maybe someone with more (recent) OpenGL experience can clarify the following?
* Is there a math library in OpenGL for matrices/vectors/planes/etc?
* Can you load textures in png or jpeg formats without using external libraries such as DevIL?
* Is there any simple way to render a string in OpenGL? I seem to recall there being some function to draw a single char using a supplied bitmap font..?

No, no and no. The first (lack of math library) may be debatable, but everything else should never be part of a graphics API. Keep in mind that the main focus of a competitive graphics API is not beginner friendliness, but flexibility, performance, scalability, standarization and ease of driver implementation for IHVs. If you are looking for a beginner friendly framework, then both D3D and OpenGL are the wrong choices. A third party graphics or game engine is a much better solution for such scenarios.

My experience was that OpenGL (1.X though) was waaaay easier to get up and running and rendering a few triangles, but actually working with it was a pita compared to working with Direct3D (9.0c). It was mostly small things, such as math libraries, texture loading and font rendering IIRC. It was several years ago, but I can imagine some of it being the same due to cross platform and licensing issues.

Maybe someone with more (recent) OpenGL experience can clarify the following?
* Is there a math library in OpenGL for matrices/vectors/planes/etc?
* Can you load textures in png or jpeg formats without using external libraries such as DevIL?
* Is there any simple way to render a string in OpenGL? I seem to recall there being some function to draw a single char using a supplied bitmap font..?

It has nothing to do with cross platform or licensing issues, OpenGL is an interface between your application and the graphics driver, the actual OpenGL implementation you run is written and provided by the hardware manufacturers(The same goes for Direct3D) and it makes little sense to complicate their job by adding a bunch of irrelevant stuff that they have to implement.

Direct3D is exactly the same, it doesn't support text rendering, png or jpeg loading or high level math either, all that is handled by D3DX (Which is a helper library included in the DirectX package (This is written by Microsoft and doesn't make things harder for the hardware manufacturers as they can ignore its existance)).

There are plenty of D3DX equivalents for OpenGL you can choose from, you can even use D3DX along with OpenGL if you're crazy enough just like you can use DirectSound with OpenGL. (Allthough D3DX is a bit more tightly coupled with D3D which makes it far more painful to use with another graphics API)

When i first saw DirectX code and then OpenGL, i said: goodbye DirectX.
Im choosing OpenGL. And im glad that i did this. OpenGL is alot easier and cleaner. It makes many things so much easier.
And now im not even thinking about switching to DirectX.

On the other hand...

glEnableClientState (GL_VERTEX_ARRAY);
glVertexPointer (...);

glEnableClientState (GL_COLOR_ARRAY);
glColorPointer (...);

glClientActiveTexture (GL_TEXTURE0);
glEnableClientState (GL_TEXTURE_COORD_ARRAY);
glTexCoordPointer (...);

glClientActiveTexture (GL_TEXTURE1);
glEnableClientState (GL_TEXTURE_COORD_ARRAY);
glTexCoordPointer (...);

glClientActiveTexture (GL_TEXTURE1);
glEnableClientState (GL_TEXTURE_COORD_ARRAY);
glTexCoordPointer (...);

glDrawRangeElements (...);

Versus...

device->SetFVF (...);
device->SetStreamSource (...);
device->SetIndices (...);
device->DrawIndexedPrimitive (...);

It does go both ways you know. And don't even get me started on "bind to modify"...

I am using both equally. I will mention a few things that I don’t see mentioned every time there is an OpenGL vs. Direct3D discussion.

OpenGL has a way of biting you in the ass because of its state-machine structure.
Example #1: Long ago while learning about both Direct3D and OpenGL, I had an engine that was running fine on both. Then one day when I disabled lighting, all of my models in the OpenGL version turned black instead of bright as they had always done before. I had no idea when no-light rendering stopped working so I started research on their lighting model.
I discovered that glColor is used when lighting is off.
I had glColor set to black to prevent it from modifying my sprites and other things it modifies.

Changing a state can have consequences where you least expect it until you really have a lot of experience with OpenGL.


Example #2: I was a beginner with OpenGL but not graphics programming or programming in general. So I knew to put in redundancy checks to prevent redundant state changes.
So if the texture ID in that slot is the same as the one being applied to that slot, early out and time saved.
Unfortunately in OpenGL this is not so simple as it is in Direct3D.
Since you have to bind textures both to create them and to use them, one day a bug appeared when an object was loaded in the middle of gameplay. Suddenly the wrong texture was on an object.
Of course it was a simply folly that was easy to fix, but it is a newbie trap for those just beginning in OpenGL who don’t know the full impact of every single function.


Example #3: And that makes multi-threading a real pain in OpenGL. To load two textures on different threads, you have to create thread-safe blocks (critical sections or mutexes) where you can be sure no other threads can call glBindTexture until you are done with the current texture. And that can be called during a render too so be sure to lock your critical section or mutex during the entire render too.
And glGetError is needed to tell if some functions fail and to get information about why they failed.
Have to create another critical section for that to make sure another thread does not clear the error while you are loading a texture. It goes on and on.
If you are beginning OpenGL, forget about multi-threaded resource creation.



Direct3D 9 has one major issue: Resource management. You will probably not be able to resize the window or toggle full-screen mode for a while if you are beginning Direct3D 9.
Direct3D 10 and Direct3D 11 are harder to grasp for a beginner, but people have been managing and they do not have this major issue, just as OpenGL does not.



Overall DirectX is less hassle-prone and easier to understand thanks to its object-oriented structure. Functions are more descriptive and terminology is more commonplace (see post by mhagain).
DirectX is also significantly faster than OpenGL on most Windows implementations (my new engine has equal logical overhead (same redundancy checks, same tick logic, same number of shader/texture swaps, etc.) but every scene in OpenGL is only 75% the speed of the same scene in Direct3D), but I doubt you will be able to use that difference as a beginner.


L. Spiro

My own opinion of the war between the two is that up to version 1.4, when compared to the equivalent D3D level, OpenGL was clearly superior. If that's all the functionality you need, and if you're happy to stick with immediate mode, then it's a no-brainer. You'll probably find OpenGL easier.

The vertex arrays API in OpenGL (the example I gave above) is a mess. If you're using vertex arrays then - when compared to a D3D8 or 9 level (the last versions that let you draw from system memory pointers) - D3D is easier and cleaner. In this case 3 of the function calls I gave above can be collapsed into one.

OpenGL 1.5 was where things got interesting. OpenGL's original implementation of VBOs was - to put it mildly - a crock. Yes, there was some sense in piggy-backing it on top of the vertex array API, but there are a whole heap of problems that arise from that and now we have the gl*Pointer calls that behave in two quite different manners depending on whether or not a VBO is bound. The lack of clear and unambiguous VBO data access semantics is not nice. As for which function to use: glMapBuffer? glBufferData? glBufferSubData? glMapBufferRange? WTF!

Of course that's improved with subsequent extensions, but extensions are both one of OpenGL's greatest strengths and one of the factors that can make you pull your hair out screaming. Want to run on as wide a range of hardware as possible? Prepare to enter the extension tango with multiple rendering backends. OpenGL 2.0 or higher shaders? GL_ARB_shader_objects? GL_ARB_vertex_program? These are the problems you have to deal with when you move on to making programs that people other than you will use. D3D by comparison has one clear API for each version. If you want to code a D3D9 app all of the D3D9 API is available.

OpenGL drivers are a horrible mess. There are no conformance tests yet available for the newer versions, so driver vendors are more or less free to interpret the spec whatever way they want. Driver quality can be poor (hello Intel, hello AMD). You can still get unexpectedly punted back to software emulation. Vendor-specific workarounds are still occasionally needed. Check this note from the AutoDesk people: http://archicad-talk.graphisoft.com/download.php?id=13495&sid=f6cb976ac04f7441b369bf3e58819086

OpenGL's OS portability is better, yes, but it's graphics hardware portability is actually significantly worse.

Plus D3D is faster:

DirectX is also significantly faster than OpenGL on most Windows implementations

I'll second that. I've consistently found the same, and so has this guy: http://aras-p.info/blog/2007/09/23/is-opengl-really-faster-than-d3d9/