OpenGL or Direct3D?

[Raizor]

Hi guys. I'm considering throwing myself into either OpenGL or Direct3D for some demo coding.  I'm just looking for some advice on which of these would make more sense to learn. My understanding is that the high level shader languages differ slightly (amongst other differences). I'm just curious if both of these will allow me the same flexibility and features.

I'm edging towards OpenGL at the moment, as it is more flexible in terms of porting code to other languages and hardware systems. I'll be doing most of my dev in either C# (and XNA) or C++ on windows.

Any advice would be great. Thank you

[hellfire]

Feature-wise both APIs are almost identical.
Consider OpenGL more "C" and D3D more "C++".
OpenGL is somewhat easier to start off, D3D has better in-depth documentation.
But once you've understood the principles it just doesn't matter which API you use.
Actually it's good to know both.

[Xetick]

I have fought with the question for a long time and here is my current opinion.

For starters there are some points that make it easy to choose.
If you want to be portable you need to go with OpenGL.
If you want to use XNA you need to go with DirectX.

There however the easy choices ends.
- Finding documentation on OpenGL is hard.
- Keeping track of the current state OpenGL can be tricky since its just a big state machine and what you set stays active until you change it. The problem is that if you for example activated a texture and forget it sometime way later in you program you could start to render something strange on the screen. You dont know what and its very difficult to find out. It can also be that you dont notice this problem until you render on another type of hardware.
- Finding out how to do thing and in what order is even harder. For example setting up your render buffers must be done in the correct order. If you dont do it correct it will probably not work on some card. Usually ATI cards. The OpenGL wiki common problems have however helped a lot
- Driver wise OpenGL have issues. Nvidia has very good driver. ATI has quite ok drivers. Intels are a disaster. The problem is that when you install for example Windows 7 all graphics cards must deliver functional Direct3d drivers for the Aero UI. But they can completely ignore OpenGL. This means that even if the graphics card vendors have good drivers the users need to go to their site and download them themselves. Sometime they come as an optimal windows update. Sometimes not. But it's a manual step never the less.

This is actually the reason why Firefox and Chrome has had to change so that WebGL doesnt use OpenGL. Instead they convert all shader code to DirectX shader code (Using the angel project) and run that since users just didn't have the drivers. I think specially Intel was the problem.

When it comes to tool chain DirectX has a major lead if your on a Nvidia cards with the performance tools that act as overlays. OpenGL has the now free gDEBugger that helps but nvidias tools are much better. Not sure if ATI has any good directx/opengl debugger tools.

You can however do everything in both. But for example if you want geometry shaders you will be required to need Windows 7 when using DirectX. If you go OpenGL you can run it on XP using extensions.

The differences in shader language isn't much. It's quite easy to convert OpenGL to DirectX and vice versa. 

Having said all this my own program uses OpenGL and the reason for that is what hellfire said. OpenGL is easy to start with. The problem is that when you dive into more advanced things you have to struggle more and more.

If you go with OpenGL and you only want to do demos and dont care about low spec machines I would say to go with OpenGL 3.x and only target that API since they have removed a LOT in 3.1 (i think it was) to clean up the api.

If you target 2.x like I do you will find out the following "aha so that is how i add vertices to draw a triangle using glVertex" 1 day later when that works "no thats the wrong way I should use vertex lists" a few days later "nope they have been marked depricated in 3.1 so now you should use vertex buffers".. and so on..
 
.. and if you wonder, I wish I went with DirectX for my project but it's also not a demo

[Rbz]

What hellfire said!

[Raizor]

Many thanks hellfire and Xetick for the very useful info. Thanks also rbz for the reiteration It sounds like I would be best delving into both ogl and d3d to get an idea of the differences (and comparative pain). As well as the demo plans I'm also starting work on a cross platform game (PC and iPhone) so direct3d via XNA for PC and ogl on iPhone would probably make most sense. Will be sure to post back once I've got stuck in. Thanks again.

[staticgerbil]

Keep in mind that the iPhone uses GLES, not regular GL.  They are fairly similar though.  I have done a little iPhone game dev so feel free to fire any questions if you get stuck.

Another note is that I think you can only use XNA from C#?  So it would be pretty difficult to re-use code between iPhone and PC if you were planning to do that.

Finding out how to do thing and in what order is even harder. For example setting up your render buffers must be done in the correct order. If you dont do it correct it will probably not work on some card. Usually ATI cards.

I have had this issue in the past with GL using the same hardware but different versions of drivers

[Raizor]

Thanks Staticgerbil.  XNA in C# is great for me anyway, it's the language I'm most comfortable with these days. I would love to be able to code iOS software in C# without Mono or anything, but that's never going to happen.  My plan is to write a level designer in C#/XNA, which will effectively be a complete game engine too, so it makes sense to make a full windows release imo.  The game is only going to be 2D in essence, so will only be using GL for particles and suchlike. 

For the iPhone version of the game, I'll probably end up using Cocos2d and the Chipmunk physics library as I've used these before. Afaik, there's no complete C# port of the Chipmunk library, which is a bit of pain.  I'll have to come up with another solution for that, maybe Box2D or something...

I'm pretty much resigned to the fact that there isn't really going to be any scope for code portability, but that's probably not the end of the world.

Thanks again for the response and I'm sure I'll hit you up for advice in future

[Jim]

Actually, it's fairly certain there will be a usable port of Mono to Android, so it may be possible to re-use some of your C# code.

For me, the OpenGL API is cleaner than Direct3D and I like the shaders, but then I'm a little behind on DX10 and 11 and haven't looking into them properly.
OpenGL has recently dropped the easy begin/vertex/end immediate mode, it will be available on PC drivers for a long time to come, but OpenGL ES has never had it and is different enough from OpenGL to be a pain in the ass.

Jim

Jim

[swapperz]

OpenGL or Direct3D...learn them both, there is no downside to knowledge

[LittleWhite]

I would like to diverge a bit from Xetick said, mainly about documentation.

Ok, it's hard to have nice documentation / tutorial for OpenGL (More again since all the old tutorials (like wonderful NeHe's tutorials) has been deprecated). But the advantages on DirectX is that you have full access to the specification of the API, on how it is working, why it has be done this way, how should react the driver. So, in fact, you have everything, but true, a bit pain in the ass to read it.

With DirectX, that's call, you have exemple ... plenty of tutorials ... but when you need something really precise ... no way to get it. I mean, last time I have tried to do differed shading ... the documentation (MSDN) looks oddly made to me, not enough precise information in it and ... I really didn't want to use the Dx10 effect files ... but all the tutorials are based on these strange files ...

So ... of course it's like you want, but from the documentation I have to said, I prefer a bit the painful OpenGL Specification explaining everything that the MSDN thing trying to hide me everything.

Now, a bit more about the APIs. OpenGL has the kind of advantages to implement extensions. Extensions are optionnal ... so you can have it or not. But at least, with extension, you can have something implemented even with no major version (not like waiting Dx12 to have something). Moreover, at some point extensions will be implemented in the core (if they are really useful ).

About pipelines. True they have really remove easy functions from OpenGL 1 (which allow us to get something drawing on screen quickly). But often ... it's still supported by the driver (I don't know until when, and I don't know if it will be forever ...). But in fact, they have done "the same" in DirectX10 where the fixed pipeline is also removed.
What does "fixed pipeline" removed?
Simply that the API will give you nothing to draw shapes on screen. So you will have to program the Graphic Card to get it properly on the screen. It brings us dynamic application and GC configuration ... but it also means that you have to do some more mathematics and work to get your first triangle on screen.

What else ?

Hum, I like OpenGL ES a lot. Actually, we are similar to -> OpenGL ES 1 -> OpenGL 1.4 / OpenGL ES 2 -> OpenGL 3 (I think)). OpenGL ES 2 has shaders (which is really cool feature trust me )
OpenGL ES is a light version of OpenGL ... it means that some part has been removed but at least, it's cleaner.

OpenGL compare to DirectX doesn't give anything to load the textures / shaders ... which can bother some ... because you have to implement your own loaders.

OpenGL is compatible with multiple languages ... actually I am working with D ... but Java ; Python ; C# are the other possibilities. (I think that the C# thing is not the best for OpenGL ...)

OpenGL ES is used nearly everywhere now (apart PC and XBox games). Even the PS3 has a OpenGL ES implementation (but not a classical one, they have a lot of specific extensions to extend OpenGL). OpenGL ES is also on Android phones / iPhone iPad.

Finally I will conclude on support on PC.
This is a big point. OpenGL Drivers are often buggy (ATI more than NVidia ... Intel is so lame ). This is because the OpenGL consortium does not have a proper tests set and are not enough strict when according the OpenGL compliance. Microsoft is really stricter. So they have better drivers ...

And I think that's all Thanks for listening

[Raizor]

Thanks very much for the in-depth reply LittleWhite. Lots more useful info in there. I think I'll wet my feet in OpenGL first and take a look at direct3d once I'm comfortable. Rolling my own texture loaders doesn't sound too bad so we'll see how that goes.

How are you finding D? I keep hearing about it but haven't had a chance to look at it yet.

[LittleWhite]

To not goes outside the subject I will talk about D somewhere else

I am trying to do an OpenGL program in D, actually.

About textures ... you can always use additional libraries

[ferris]

For loading textures: http://nothings.org/stb_image.c

That will give you really nice routines that will load most formats (with minor restrictions) into a standard component buffer, perfect for passing to OpenGL.