DirectX 9 or SDL and OpenGL
Author
I've been programming with C++ and using Maya for awhile but haven't had much experience combining the 3D graphics and programming halves together.
What my question is which is better to try and achieve this goal with and pretty much which has the better/most free tutorials on the subject.
-Thanks
Both have a lot of tutorials behind them, and there's a lot of shared concepts between them too. I would say that your choice should come down to that of programming style and project scope.
The most obvious difference is that DirectX is Object oriented (via COM, although the COM layer is pretty much hidden away) while OpenGL is very functional in nature. Therefore if you find it more natural to develop with an OO mindset, go DirectX otherwise look at OpenGL.
Another consideration to make is if you are planning on doing platforms other than windows, in which case you should consider OpenGL as well (since it's really the only option outside of the Microsoft Platforms). If you are just starting out with 3d, though, I would highly recommend setting cross-platform desires aside until you're feeling more secure in some of the concepts.
Finally it should be noted that while DirectX has been moving pretty fast lately (in a good way) OpenGL's API has stagnated, with all new functionality coming in through a somewhat clunky extension mechanisim. As a result, OpenGL has a lot of outdated cruft still lingering that can make it a tad more confusing for newbies who are looking to learn how "modern" graphics programming works.
Good luck, whichever path you choose!
The most obvious difference is that DirectX is Object oriented (via COM, although the COM layer is pretty much hidden away) while OpenGL is very functional in nature. Therefore if you find it more natural to develop with an OO mindset, go DirectX otherwise look at OpenGL.
Another consideration to make is if you are planning on doing platforms other than windows, in which case you should consider OpenGL as well (since it's really the only option outside of the Microsoft Platforms). If you are just starting out with 3d, though, I would highly recommend setting cross-platform desires aside until you're feeling more secure in some of the concepts.
Finally it should be noted that while DirectX has been moving pretty fast lately (in a good way) OpenGL's API has stagnated, with all new functionality coming in through a somewhat clunky extension mechanisim. As a result, OpenGL has a lot of outdated cruft still lingering that can make it a tad more confusing for newbies who are looking to learn how "modern" graphics programming works.
Good luck, whichever path you choose!
At the OP: It's like asking if you should choose regular or decaf. Or deciding between Dr Pepper and Mr Pibb, or between Coke or Pepsi. Briefly look at them both. Decide which one you like better. Use it. The end.
At the risk of derailing the thread...
The reverse of this is actually true.
The OpenGL api has always been designed to be very flexible that way. One of the big complaints about D3D is its inflexibility.
In OpenGL there has always been a core bit of functionality that must be supported. That core is extremely minimal compared to the actual graphics support available.
Everything in OpenGL is implemented with queries to the driver. If you want to use a feature, you query to see if it is available. If the feature is present, you get it's function pointer and use it.
With OpenGL you are never limited to the currently published functions. You are not prevented from using old features. You can use any functions available in your drivers, even if they aren't part of the final standard yet, or even if they have been deprecated from it.
Example: You have a game engine already written that is based on OpenGL 1.2 graphics. You just bought a new computer with Vista and new graphics card. You decide you want to try these new geometry shaders because they look cool. To use it, you simply query the graphics drivers to see if it exists, get the function pointer, and use it as documented. If for some reason it doesn't exist you can continue to operate as normal.
Direct3D on the other hand offers no such flexibility. If you write your code for a particular revision of Direct3D you get that feature set.
In a way this is good because you can ignore all the other features. But you have lost a lot of functionality because cannot access features from any other version.
There is no way to get features that are in the future of your version of DirectX. Similarly, you are locked in to that minimum version. If you picked DX 8.1 for your game engine a few years back, you cannot use anything that was removed from DX7, nor can you access features added with DX9 or later.
Reconsider the example.
Example 1: You wrote a game on your old PC based on Direct3D 8.1. Just like above, you just bought a new computer with Vista and a new graphics card. You decide you want to try these new geometry shaders because they look cool. To use it, you must rewrite your entire graphics engine to use D3D10 objects and structures, D3D10 function calls, link against different libraries, and make countless other changes. Only then are you able to use the feature.
In some ways you are right that there is a bit of 'cruft' -- that is, there are some old features that you don't need anymore. With OpenGL you are still free to use them, at the mental cost that you must know about their existence. With Direct3D you are prohibited from them, although you are freed from the mental cost of knowing of their existance.
Quote:Original post by Toji
Finally it should be noted that while DirectX has been moving pretty fast lately (in a good way) OpenGL's API has stagnated, with all new functionality coming in through a somewhat clunky extension mechanisim. As a result, OpenGL has a lot of outdated cruft still lingering that can make it a tad more confusing for newbies who are looking to learn how "modern" graphics programming works.
At the risk of derailing the thread...
The reverse of this is actually true.
The OpenGL api has always been designed to be very flexible that way. One of the big complaints about D3D is its inflexibility.
In OpenGL there has always been a core bit of functionality that must be supported. That core is extremely minimal compared to the actual graphics support available.
Everything in OpenGL is implemented with queries to the driver. If you want to use a feature, you query to see if it is available. If the feature is present, you get it's function pointer and use it.
With OpenGL you are never limited to the currently published functions. You are not prevented from using old features. You can use any functions available in your drivers, even if they aren't part of the final standard yet, or even if they have been deprecated from it.
Example: You have a game engine already written that is based on OpenGL 1.2 graphics. You just bought a new computer with Vista and new graphics card. You decide you want to try these new geometry shaders because they look cool. To use it, you simply query the graphics drivers to see if it exists, get the function pointer, and use it as documented. If for some reason it doesn't exist you can continue to operate as normal.
Direct3D on the other hand offers no such flexibility. If you write your code for a particular revision of Direct3D you get that feature set.
In a way this is good because you can ignore all the other features. But you have lost a lot of functionality because cannot access features from any other version.
There is no way to get features that are in the future of your version of DirectX. Similarly, you are locked in to that minimum version. If you picked DX 8.1 for your game engine a few years back, you cannot use anything that was removed from DX7, nor can you access features added with DX9 or later.
Reconsider the example.
Example 1: You wrote a game on your old PC based on Direct3D 8.1. Just like above, you just bought a new computer with Vista and a new graphics card. You decide you want to try these new geometry shaders because they look cool. To use it, you must rewrite your entire graphics engine to use D3D10 objects and structures, D3D10 function calls, link against different libraries, and make countless other changes. Only then are you able to use the feature.
In some ways you are right that there is a bit of 'cruft' -- that is, there are some old features that you don't need anymore. With OpenGL you are still free to use them, at the mental cost that you must know about their existence. With Direct3D you are prohibited from them, although you are freed from the mental cost of knowing of their existance.
Quote:Original post by frob
At the risk of derailing the thread... The reverse of this is actually true.
I suppose this is in the eye of the beholder (and maybe I'm just still feeling burned from the OpenGL 3 fiasco), but you did a good job of highlighting the pros and cons of the different philosophies there.
The point I was trying to bring across (not to well, now that I look at it) is that in modern graphics there are several well established "right" ways to do things. Sure, you can structure your animation framework a billion different ways, but you should always be submitting your vertices via a VBO,, you really ought to be using shaders if you want to keep up with the hardware, that sort of thing. DirectX actively (if somewhat strictly) encourages these "good" behaviors.
In OpenGL, however, it is actually most natural (ie: no extensions required) to do things in what is possibly the slowest and most limited way! Not to mention many of the OpenGL resources available will happily teach you immediate mode till the cows come home, and oftentimes buffers and shaders are some small footnote at the end of the series. You really do have to actively search for information on how to use the most optimal path, which is going to be difficult for a newcomer to the graphics scene.
And now I'M derailing the thread. Sorry :)
Still, it really is about preference in the end, as both are very capable APIs. Don't pay too much attention to us nitpicking the details!
Whichever coding style looks most appealing to you, really. However, if you plan to try other platforms in the future, it is good to know both, so that you know how to work in multiple APIs. Quite frankly, when you port your 3D app/game to different platforms, you want to use the APIs optimized for that platform. Like if you ever did PS3 development, you'd use libGCM. If it were the 360, you would have to learn its flavor of DirectX. If it were a mobile handset, it would be OpenGL ES.
Bottom line, you're going to have to learn multiple APIs anyway. However, for just starting out, pick the one that you think works best for the platform you intend to target. If you're windows only, start looking at D3D. If you want to go mobile, starting looking at OpenGL.
Not sure if that helps, but there it is. :p
Bottom line, you're going to have to learn multiple APIs anyway. However, for just starting out, pick the one that you think works best for the platform you intend to target. If you're windows only, start looking at D3D. If you want to go mobile, starting looking at OpenGL.
Not sure if that helps, but there it is. :p
It's easy to learn the other when you've learnt to use one of them. I like both APIs, but am currently mostly using OpenGL because I often need platform independency.
I like OpenGL because it is an API standard which can be used with a variety of bindings. For example, in C++ you can use OpenGL with GLUT, QT, or SDL for handling events and the windowing side, and keep your OpenGL code consistent between the windowing APIs.
Or, you can take your OpenGL code, and then change over to QTRuby and use bindings for OpenGL with that. Or, you can port it (relatively easily) to JOGL, the Java bindings for OpenGL and still keep most of the same skills (writing shaders, using vertex buffers, depth shadow maps).
Also, your code is relatively portable between Linux, Windows, and Mac. A project I was working on recently for a class was using JOGL, using skills I learned with C++/QT/OpenGL, being developed on my Linux machine and my group partners Windows machine.
Or, you can take your OpenGL code, and then change over to QTRuby and use bindings for OpenGL with that. Or, you can port it (relatively easily) to JOGL, the Java bindings for OpenGL and still keep most of the same skills (writing shaders, using vertex buffers, depth shadow maps).
Also, your code is relatively portable between Linux, Windows, and Mac. A project I was working on recently for a class was using JOGL, using skills I learned with C++/QT/OpenGL, being developed on my Linux machine and my group partners Windows machine.
Author
I've decided from what I've been hearing to go with openGL for now. Partially because a number of friends are Mac users.
Second question I must ask (since most of you making posts seemed pretty knowledgeable about OGL) any links to good OGL tutorials other than the NeHe site?
I know of Gametutorials.com but I don't have the seventy dollars to shell out for a copy of theirs.
-Thanks.
Second question I must ask (since most of you making posts seemed pretty knowledgeable about OGL) any links to good OGL tutorials other than the NeHe site?
I know of Gametutorials.com but I don't have the seventy dollars to shell out for a copy of theirs.
-Thanks.
Check out http://www.ogre3d.org/ graphics engine.
It is cross-platform, Windows, Linux, Mac, also people have used it on consoles I heard.
Using it lets you pretty much completely ignore the DirectX and OpenGL APIs. I consider this a very good thing.
It is cross-platform, Windows, Linux, Mac, also people have used it on consoles I heard.
Using it lets you pretty much completely ignore the DirectX and OpenGL APIs. I consider this a very good thing.
As a note: NeHe has most of the tutorials listed in multiple languages and environments at the end of the tutorials.
Personally, I like books (a little old school). Doing examples from the OpenGL SuperBible is what is helping me learn, and QT tutorials online. Also, there's a lot of good open source code you can look into (I've been looking at the GL screensavers for xscreensaver in Linux).
Be careful though: Don't just focus on learning function calls, but try to see the big picture in what you're doing (e.g. matrix stacks and how and why you use them, the theory behind how things work), because these can be applied if you switch to DirectX or another library later on.
Personally, I like books (a little old school). Doing examples from the OpenGL SuperBible is what is helping me learn, and QT tutorials online. Also, there's a lot of good open source code you can look into (I've been looking at the GL screensavers for xscreensaver in Linux).
Be careful though: Don't just focus on learning function calls, but try to see the big picture in what you're doing (e.g. matrix stacks and how and why you use them, the theory behind how things work), because these can be applied if you switch to DirectX or another library later on.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement