Related
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
OpenGL or DirectX?
Not want to trigger war, but really want to know pros and cons of those two mainstream graphic library?
To be honest the hard part is not the API, it's the higher level 3d stuff. Below that both APIs have vertex buffers, index bufers, textures, shaders, and so on and although they express that in different ways it's the concepts that are the hard part not the API. If you understand d3d11 then you'll pick up opengl in no time and vice-versa.
Practical considerations are that opengl is available on more platforms, but that d3d tends to be better supported and work better on windows platforms. d3d has a more object oriented interface whereas opengl has a strictly "c" style interface (Although it deals internally with objects through "names" and handles). This likely makes opengl easier to start learning than d3d11 which needs quite a bit of setup - but in "real" applications there won't be much in it.
d3d11 is designed to work better on multi core cpus and mult threaded software. This adds some complexity to using it, but allows you to perhaps take more advantage of the hardware then opengl might at this point in time. (However if you are still at the stage of asking which to use then it's very unlikely to matter to you!)
it tends to be much easier to find documentation for d3d9 than opengl (I mean for "modern" stuff, not examples using obsolete ways of doing things, (which is a problem with opengl, a lot of the tutorials and code out there is frankly obsolete and doesn't really use opengl properly now). Whereas it's quite hard to find good d3d11 examples and tutorials still.
If you've not used either I would very much recommend learning the basics of BOTH and the slightly different approaches to the same underlying functionallity. Don't get caught up in saying one is better than the other, learn both and see which seems a better fit. This is what most people do, unfortunatly most of the "advice" you'll get on the internet seems be to from someone who has decided that pushing one or the other API is important to them!
I found it a useful excercise when learning to abstract out the differences with a small c++ framework that creates textures, vertex buffers, index buffers, renderstate collections etc, and implements those concepts in terms of BOTH apis/.
OpenGL is a cross-platform API for 3D graphics. DirectX is a restricted-platform API for graphics, audio, music, device input, networking, and more.
Fist of all, DirectX is a lot more than 3D accelerated rendering. I assume you are talking about Direct3D.
Anyway, here's my completely biased opinion:
Direct3D runs on Windows, Xbox, and sometimes Wine (depending on the particular application/game). Choosing Direct3D ties your product heavily to Microsoft platforms.
Coding in Direct3D (at least the last time I tried it, which was some years ago) makes rolling around naked in honey, walking up to a hornet's nest, and beating the tar out of it sound like a pleasant afternoon.
OpenGL runs on almost every platform imaginable and supports most of the same stuff that Direct3D does in immediate mode.
The OpenGL API is mostly clean and a joy to code against.
I'm a relatively new developer, and I'm looking to learn C++. I've had experience coding in java, javascript, actionscript, and python, but I want something fast enough to do some high performance 2D and 3D games.
When I eventually learn the basics (control structures, classes, etc) I'd like to develop a 2D game. I've explored various libraries for 2D graphics (cairo, sdl, openframeworks, clutter) but clutter seemed to be the most optimised for accelerated graphics and vector drawing.
Would clutter be a good fit for a 2D game? I realise that it maintains its own scenegraph unlike other libraries, but I've developed a flash game in the past, so I should be used to that.
Are there any performance issues I should be aware of? Has anyone else had experience doing heavy graphics with clutter?
I've done a lot of embedded systems work using Clutter, and am now doing a desktop project with it. It would probably be great for a desktop-based 2D game, with certain caveats:
Mainline development on the toolkit is very heavily Linux-oriented. I'm not sure how well the Windows, Mac, or iOS ("fruity") ports are maintained.
Documentation is sparse, and afaik there are no books. (I'm thinking of writing one.)
It's written in C, and natively exposes C-language bindings. While there are Clutter bindings for many languages including C++, you'll still need to understand the C-language bindings.
It doesn't natively use C++ objects. Instead it uses the C-based GObject system for single-inheritance objects, and even if you're writing to it with the C++ bindings, you'll need to understand about GObject some, too.
If you want to use it with threads, you have to use its threading system - not POSIX threads, or Boost threads, or anything else.
It can really beat the tar out of a GPU, so if you're doing something fancy, frame rates can be mediocre on some of the low-end Intel chips used in cheap laptops and netbooks.
That said, you can do amazing things with it. I really enjoy working with it, and once you understand how to do it, mixing-and-matching with C++ is a lot of fun.
Also, there's a really rockin' open-source conference called GUADEC where the Clutter folks hang. If you were to show up there in July 2011 in Berlin with a really fun Clutter-based game, people would buy you lots of drinks.
I must admit I've never heard of Clutter before, probably because it's not a Windows library and the majority of games developers work on Windows platforms. Similarly, most game developers (even indie/hobbyist ones) are not considering Cairo, or Openframeworks either. More common by far would be the use of SDL, although that is not fully hardware accelerated and thus not a good choice for modern games. SFML is an alternative that is growing in popularity, but most game developers these days are probably rolling their own OpenGL rendering on top of something like SDL.
By the looks of it, Clutter might be a good choice, and it certainly seems fully-featured. But sometimes the problem with the larger frameworks is that they become a bit of a walled garden and it's hard to integrate extra bits that you might need - for example, I don't know how well the input might work.
The other problem with using a less well-known engine is that if you go to https://gamedev.stackexchange.com/ or http://www.gamedev.net and ask questions, the community won't be able to help as much since they are not familiar with the technology you're using. You have to balance the cost of that against the potential gains that come from using an unpopular but actually very competent library. (As well as the possibility that these other guys know something you don't...)
Clutter is relatively new and there are not many applications that use it right now. Especially games. So you will have a hard time finding somebody who has experience with it for gaming purposes.
That said, clutter indeed has some interesting features that make it look compelling for the purpose, and I would even claim that for many types of gameplay the internal scene graph can even be an advantage to the game developer.
I would like to propose you another interesting option for 2D game graphics: Qt from Nokia.
While it is primarily a general-purpose GUI toolkit, it has nice proportions not every game developer would be aware of in first place. In fact, it has a fully-fledged OpenGL drawing backend which can be used to draw any widget, and to use any of Qt's canvas drawing operations.
Things go crazy as soon as you start to explicitely using a QGLWidget, which not only enforces GL drawing mode (which is not the default), but also allows you to mix your own GL drawings with Qt's drawing operations in the same context. You gain the possibility to not only use simple-to-use, high level drawing operations paired with a powerful event queue and efficient input handling; furthermore you keep the freedom to build-in more advanced, low level graphics in the future.
See this example. Note that you can mix native GL drawing freely with Qt's Painter functionality (if you take care of the GL matrix stack).
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I know there are some question about learning OpenGL.
Here is what I know:
math for 3D
3D theory
Here is what I want to know:
- OpenGL 4.0 Core profile (or latter)
- Shader Language 400 (or latter)
- every part of above (if it do not work across vendors then it still do not bother me)
Here is what I DO NOT want to know
- fixed function pipeline (will not use it ever!)
- older OpenGL's
- Compatibility profile
I prefer bigger portion of info like tutorials, series of articles, books.
PS If you know resources on opengl 3.x core profile, post them too
I cordially dislike negative answers, but I'm afraid I have to give one to this question.
You are ultimately asking for beginner material that uses features unique to OpenGL version 4.0 and above. Well, let's look at some of the unique features of 4.x.
Perhaps the biggest feature is tessellation. What does that mean? It means tessellating primitives to generate more primitives. Before one can even begin to understand what that means, one must first understand how primitives get rendered at all. That uses pre-4.x level features.
But even with a firm understanding of how rendering works, there is still a problem. In order to have any meaningful discussion of tessellation shaders, one must first have a strong understanding of tessellation algorithms. And that is not a simple subject. For a tutorial to teach a user to use tessellation shaders, the tutorial will first have to introduce spline curves and patches or subdivision surfaces. Both of these are lengthy topics that have numerous white papers devoted to them. Only after detailing the algorithms would a user be ready to see how those algorithms are implemented in the tessellation shader.
Or, to put it another way, tessellation shaders are not beginner material. I wouldn't even qualify them as intermediate-level material.
Another big feature of 4.x level hardware is shader image load store (and its companion, atomic counters), core in 4.2. It allows for some very nifty things, including order-independent transparency. However, in order for a user to even begin to understand all of the quirks around it, the user needs to be intimately familiar with the deep workings of modern shader hardware. So any tutorial would first have to explain how modern VLIW/SIMD-based hardware works, as well as how shaders are used with such hardware. Again, this is not trivial material.
Another big feature of 4.x hardware is indirect rendering. That is, putting the parameters to a glDraw call in the buffer object itself. The problem is that there is really only one reason to use this functionality: because the GPU generated data directly into one or more buffers for later rendering. And doing that usually involves some form of GPGPU operation, which is very much not a beginner-level topic.
All of these features are useful and have a real purpose. But none of them should be used by beginners; in some cases, not even intermediate-level programmers should touch them.
Now to be completely fair, there are some 4.2 features that are both non-hardware-based (so they are often implemented on 3.3 and lower versions) and quite useful. Separate program objects, for example. These features hit while I was writing my 3.3-based tutorials, and I considered going back over them and incorporating this functionality. The only reason I didn't is because implementations (drivers) are still not entirely stable with regard to this functionality. But it would be useful to do.
The main point I'm getting across is this: if you are at the stage in your graphics knowledge where you are ready to take advantage of the unique features of GL 4.x hardware, then you also have enough graphics experience that you don't need an explicit step-by-step instructional material to implement features of graphics hardware. You would be the kind of person who could read the GL_ARB_tessellation_shader extension specification and understand how to make them do what you need to.
That being said, if you are interested in material that teaches OpenGL core 3.0 or better, the OpenGL Wiki has a nice collection of such links. In the interest of full disclosure, I did write one of them.
The 5th edition of OpenGL SuperBible has been recently released. This edition reflects OpenGL 3.3 which was released at the same time as OpenGL 4.0, the book only covers the core profile and assumes no prior OpenGL knowledge.
That's what I got from the book's description anyway. I have the 4th edition and it's an excellent resource for OpenGL 2.0, so I assume the new edition along with the latest OpenGL Shading Language book would be just what you're looking for.
Durian Software has an ongoing series of tutorials covering modern OpenGL. They are aimed at OpenGL 2.0 but avoid using any deprecated functionality in later versions.
There is really very little difference between OpenGL 3.0 and 4.1. If you stick to 3.0 or later core profile, you can't use the fixed function pipeline. What you're really asking for is an OpenGL tutorial that does not use the fixed function pipeline.
Jason L. McKesson's excellent tutorial "Learning Modern 3D Graphics Programming" starts out using shaders for the very earliest basics, and never touches the fixed function pipeline.
http://www.arcsynthesis.org/gltut/index.html
I highly recommend it.
I recently stumbled on this online book:
OpenGLBook.com
I haven't read it yet, but description says that it is a free OpenGL 4.0 programming resource in online book format.
Excellent question, really. As a matter of fact, documentation is sparse.
There is a good introduction here : http://sites.google.com/site/opengltutorialsbyaks/
You may also like groovounet's ogl4 samples pack : http://www.g-truc.net/post-0310.html
but I'm afraid that's pretty much it. Lurk on the opengl discussion boards for more info ...
EDIT : found a few seconds ago. Straight from SIGGRAPH http://nvidia.fullviewmedia.com/siggraph2010/02-dev-barthold-lichtenbelt-mark-kilgard.html
http://www.opengl.org/sdk/docs/man4/
There's the man pages for OpenGL 4.1, they prove to be useful when developing.
I think one of the best hopes you have is Joe's Blog. It has a few good introductory articles on modern OpenGL, with more (supposedly) on the way.
Swiftless is updating tutorials to include new context. A good starting tutorial that has been more straight-forward regarding a quick and simple VAO, VBO and render is located at swiftless.com
Have not read it, but OpenGL 4.0 Shading Language Cookbook
The major point of OpenGL 4 is tesselation so i would like to recommend to start from a standalone tutorial on OpenGL 4 tesselation, i.e: http://prideout.net/blog/?p=48
After manuals and tutorials a good follow-up is to take a look at the open-source engines out there that are based on top of "new" OpenGL 3/4. As one of the developers, I would point at Linderdaum Engine.
free resource:
http://www.arcsynthesis.org/gltut/index.html
I am currently learning GLSL. It would seem that once you learn one of the shader languages, learning one of the others would not be too difficult. Is it something analogous to learning a widget toolset like wxWidgets and then switching to Qt? Once you get the idea of what is happening within one widget toolset, another toolset will do something similar since they are ultimately doing almost the same thing at some point? What are your experiences with going from one shader language to another?
Cg and HLSL are almost the same (same builtin function names). GLSL looks and feels a bit different (i.e. mix instead of lerp, use of a main-like function), but the overall transition is still easy. The only differences are in the details and in the respective APIs (i.e. stuff like matrix storage order).
Switching between shading languages is way easier than switching between GUI toolkits…
HLSL has some differences from GLSL. Nothing too different from what I've read. There are some translation tools out there. There is a SourceForge project HLSL To GLSL tool. Also, I believe that the NVidia Cg toolkit can generate HLSL or GLSL.
In my slightly limited experience, I'd agree with everyone here that they are very, very similar and it's not a problem to switch between them. However, do beware that, as seems to be the case with most OpenGL/DirectX clashes, I find HLSl to have a few more nice convenience functions that make it a little more fun to use. I'm talking small things, like saturate, here. However, beyond minor structural differences, like passing around inputs, the basic concepts are one hundred percent the same.
Enjoy! Shaders are a lot of fun.
You are right - GLSL/HLSL/Cg shading languages are subset of C programming language, so they are very similar.
the origin of directx 3d lies in opengl. microsoft reprogrammed the opengl api to a certain point, because of this the languages should be similiar.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I'm a C++ programmer with very extensive server programming experience. I'm however fairly bored at the moment and I decided to tackle a new area: 3D game programming, for learning purposes. Additionally I think this learning project may turn out to be good resume material in the future should I decide to work in this area.
Instead of creating a 3D engine from scratch I decided to emulate as exactly as I'm able an existing one: World of Warcraft's. If you are curious as to why (feel free to skip this):
It's a real world successful game
All the map textures, models and what not are already done (I'm not interested in learning how to actually draw a texture with photoshop or whatever)
Their file formats have been more or less completely reverse engineered
There is already an identical open source project (wowmapview) that I can look at if I'm in trouble.
ok, that was a long preface.. Now, my main question is the following: Should I use DirectX, OpenGL, wrapper libraries such as sdl, or what?
What's the most used one in the real world?
And, something else that perplexes me: World of Warcraft appears to be using both! In fact, normally it uses DirectX, but you can use opengl by starting it with the "-opengl" switch via command line.
Is this something common in games? Why did they do it? I imagine it's a lot of work and from my understanding nobody uses OpenGL anyway (very very few people know about the secret switch at all).
If it's something usually done, do programmers usually create their own 3d engine "wrapper", something like SDL made in house, and based on switches / #defines / whatnot decide which API function to ultimately call (DirectX or OpenGL)? Or is this functionality already built in in sdl (you can switch between DirectX and OpenGL at will)?
And, finally, do you have any books to suggest?
Thanks!
I realize you already accepted an answer, but I think this deserves some more comments. Sorry to quote you out of order, I'm answering by what I think is important.
Instead of creating a 3D engine from scratch I decided to emulate as exactly as I'm able an existing one: World of Warcraft's.
However I wanted to focus on the actual 3d and rendering engine, not the interface, so I don't think I will be using it [lua] for this project.
From these two snippets, I can tell you that you are not trying to emulate the game engine. Just the 3D rendering backend. It's not the same thing, and the rendering backend part is very small part compared to the full game engine.
This, by the way, can help answer one of your questions:
World of Warcraft appears to be using both! In fact, normally it uses DirectX, but you can use opengl by starting it with the "-opengl" switch via command line.
Yep, they implemented both. The amount of work to do that is non-negligeable, but the rendering back-end, in my experience, is at most 10% of the total code, usually less. So it's not that outraging to implement multiple ones.
More to the point, the programming part of a game engine today is not the biggest chunk. It's the asset production that is the bulk (and that includes most game programming. Most lua scripts are considered on that side of things, e.g.)
For WoW, OSX support meant OpenGL. So they did it. They wanted to support older hardware too... So they support DX8-level hardware. That's already 3 backends. I'm not privy to how many they actually implement, but it all boils down to what customer base they wanted to reach.
Multiple back-ends in a game engine is something that is more or less required to scale to all graphics cards/OSs/platforms. I have not seen a single real game engine that did not support multiple backends (even first party titles tend to support an alternate back-end for debugging purposes).
ok, that was a long preface.. Now, my main question is the following: Should I use DirectX, OpenGL, wrapper libraries such as sdl, or what?
Well, this depends strongly on what you want to get out of it. I might add that your option list is not quite complete:
DirectX9
DirectX10
DirectX11
OpenGL < 3.1 (before deprecated API is removed)
OpenGL >= 3.1
OpenGL ES 1.1 (only if you need to. It's not programmable)
OpenGL ES 2.0
Yep, those APIs are different enough that you need to decide which ones you want to handle.
If you want to learn the very basics of 3D rendering, any of those can work. OpenGL < 3.1 tends to hide a lot of things that ultimately has to happen in user code for the other ones (e.g. Matrix manipulation, see this plug).
The DX SDKs do come with a lot of samples that help understand the basic concepts, but they also tend to use the latest and greatest features of DX when it's not necessarily required when starting (e.g. using Geometry shader to render sprites...)
On the other hand, most GL tutorials tend to use features that are essentially non-performant on modern hardware (e.g. glBegin/glEnd, selection/picking, ... see the list of things that got removed from GL 3.1 or this other plug) and tend to seed the wrong concepts for a lot of things.
What's the most used one in the real world?
For games, DirectX9 is the standard today in PC world. By a far margin.
However, I'm expecting DirectX11 to grab more market share as it allows for some more multithreaded work. It's unfortunately significantly more complicated than DX9.
nobody uses OpenGL anyway (very very few people know about the secret switch at all).
Ask the Mac owners what they think.
Side question, do you really think hardware vendors would spend any energy in OpenGL drivers if this was really the case (I realize I generalize your comment, sorry)? there are real world usages of it. Not much in games though. And Apple makes OpenGL more relevant through the iphone (well OpenGL ES, really).
If it's something usually done, do programmers usually create their own 3d engine "wrapper",
It's usually a full part of the engine design. Mind you, it's not abstracting the API at the same level, it's usually more at a "draw this with all its bells and whistles over there". Which rendering algorithm to apply on that draw tends to be back-end specific.
This, however, is very game engine dependent. If you want to understand better, you could look at UE3, it just got released free (beer) for non-commercial use (I have not looked at it yet, so I don't know if they exposed the backends, but it's worth a look).
To get back to my comment that game engine does not just mean 3D, look at this.
I think the primary benefit of using OpenGL over DirectX is the portability. DirectX only runs on windows. However, this is often not a problem (many games only run on Windows).
DirectX also provides other libraries which are useful for games which are unrelated to graphics such as sound and input. I believe there are equivalents which are often used with OpenGL but I don't think they're actually part of OpenGL itself.
If you're going to be locking into windows with DirectX and you are willing to/interested in learning C# and managed code, I have found XNA to be and extremely easy platform to learn. It allows you to learn most of the concepts without dealing with a lot of the really tricky details of DirectX (or OpenGL). You can still use shader code and have the full power of DirectX but in a much friendlier environment. It would be my recomendation but again, you'd have to switch to C# (mind you, you can also put that on you're resume).
You might want to look at some projects that encapsulate the low level 3d api in a higher level interface that is api independent such as Ogre3D. As you are doing this to learn I assume you probably will be more interesting in implementing the low level detail yourself, but you could probably learn a lot from such a project.
if you are really only interested in the rendering part, i can suggest ogre3d. it is clean, c++, tested and cross-platform. i used it in two projects and compared to other experiences (torque3d for example), i liked the good support (tutorials/wiki/forum) and the not so steep learning curve. i think someone can also learn a lot by looking at the sourcecode and the concepts they have used in the design. there is a accompanying book as well, which is a bit outdated, but it is good for the start
the problem with this is, you will be thinking inside this engine and soon you will need gameplay-like (timers, events) elements for simulating and testing your effects or whatever you want to do. so you will end up working around ogre3ds shortcomings (it is not a game engine) and implement in on your own or use another middleware.
so if you really want to touch 3d rendering first, i would take some computer graphics books (gpu gems, shaderx) and see some tutorials and demos on the web and start building my own basic framework. this is for the experience and i think you will learn the most from this approach. at least i did ...
I'm doing some OpenGL work right now (on both Windows and Mac).
Compared to my midnight game programming using the Unity3D engine, usingOpenGL is a bit like having to chop down your own trees to make a house versus buying the materials.
Unity3D runs on everything (Mac, PC and iPhone, Web player, etc) and lets you concentrate on the what makes a game, a game. To top it off, it's faster than anything I could write. You code for it in C#, Java (EDIT: make that JavaScript) or Boo. (EDIT: Boo support has been dropped)
I just used Unity to mock up a demo for a client who wants something made in OpenGL so it has it's real world uses also.
-Chris
PS: The Unity Indie version recently became free.