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.
Related
e.g. If I learn the low-level Graphics Pipeline, take a trip on learning the ARB assembly language and understand the logic for certain gpu device driver calls can it help me enhance my knowledge in GPU API programming or is there no correlation whatsover and will I be only wasting my time?
EDIT: Do professionals need to understand this to a degree?
Its definitely a good idea to have a solid understanding of what makes a GPU tick. If you know your card at a deep level, than you can easily identify bottlenecks and get maximum performance. The trouble is, finding up to date information is pretty difficult, unless you go straight to the manufacturers, and they obviously won't tell you everything about how their card works.
That link you posted is a really helpful primer, I've read it myself, but take note of the date. It was posted in 2011, which means it is almost 3 years out of date now. In the GPU world, 3 years might as well be a lifetime.
Here's a few links to nvidia and AMD's developer sites, you would probably find good information there.
http://developer.amd.com/
https://developer.nvidia.com/
ARB assembly language?
No.
You do not need to know that, though many professionals already do as a consequence of being in the industry before GLSL or Cg existed. To be honest, I cannot say that I feel any better off having experience with the ARB assembly language, all of the same concepts are taught in GLSL. And many of the hardware restrictions that applied to ARB FP/VP are no longer valid.
You would probably be doing yourself a disservice by learning it, like learning immediate mode or the fixed-function pipeline, it simply is not relevant to modern hardware/software.
That said, the blog you linked to is a very good thing to read. Do not concern yourself with hardware instruction sets (even the ARB languages are actually a virtual instruction set, translated by the driver later into the hardware's native ISA). Instead, you should understand the pipeline itself.
A high-level overview of the pipeline will do you better in the long-run. Underlying hardware optimization techniques change with each generation, but the fundamental stages of the pipeline remain relatively static (of course new programmable stages are periodically introduced). If you understand the pipeline from a high-level, then you will be prepared to learn about and apply new hardware features as they are introduced.
Not if you 're going to dive in to some obscure chip, but it most certainly helps to understand the basics of the hardware you're trying to control. I've done some console renderer programming in the past that was pretty much on the metal and that has positively influenced higher-level API usage.
I have a good grasp of Direct3D 9, and now I want to learn some OpenGL. I have the OpenGL Redbook, sixth edition, and it has a lot of good information, but it also has a lot I already know from my D3D work. I'd like a rundown of all the differences and equivalences in OpenGL and Direct3D. Does anyone know where I might find such a thing?
They are both one and the same, if you're looking for feature differences then check wikipedia.
First the big one:
DirectX has a wider scope than OpenGL in that DirectX is composed of DirectSound, DirectPlay and Direct3D etc. Whereas Open Graphics Library is just about graphics.
From my perspective of working with them, DirectX is much better designed and uniform across platforms, whereas OpenGL is just a spec and is interpreted differently across different implementations WIDELY (ATI and Nvidia just bitch at each other constantly throughout development). this makes OpenGL a bit harder to handle, there are no nice and easy features since 3.1
What OpenGL gives is an ability to hack and exploit to your hearts content, it transcends directX with supreme flexibility. You feel alot closer to the hardware in OpenGL and you get a better idea of what's going on. I always found directx to be a bit of a handicap, if you wanted to make a professional game then go with directX, but OpenGL is more free-wheeling/fun than DX; you will definitely learn more and the lack of perfect additional layers around makes you work that bit harder.
To get started read the blue/orange and yellow book. also try GXBase instead of Glut..
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).
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 looking for some answers for a project I'm thinking of. I've searched and from what I understand (correct me if I'm wrong) the only way the program I want to make will work is through 3D application. Let me explain.
I plan to make a studio production program but it's unique in the fact that I want to be able to make it fluid. Let me explain. Imagine Microsoft's Surface program where you're able to touch and drag pictures across the screen. Instead of pictures I want them to be sound samples (wavs,mp3,etc). Of course instead the input will be with the mouse but if I ever do finish the project I would totally add touch screen input compatibility! Anyway, I'm guessing there's "physics" to do with it which is why I'm thinking that even though it'll be a 2D application I'll need to code it in a 3D environment.
Assuming that I'm correct in how I want to approach my project, where can I start learning about 3D programming? I actually come from PHP programming which will make C++ easier for me to learn. But I don't even know where to start. If I'm not wrong OpenGL is the most up to date API as far as I know.
Anyway, please give me your insights guys. I could really use some guidance here since I could totally be wrong in everything that I wrote :)
I would like to add that I'm most likely looking for tutorials, Linux 3D programming sites, source/demos (google failed me for the most part).
Note: I also understand this is not a project I'll finish in weeks, months and might take years. That's fine, I want to get C++ under my belt however long it takes. I'm just looking for opinions, sources, tutorials and things that might help me (as stated above).
I don't know much about the MS Surface, but I'm a musician and multimedia artist working mostly with code, so... My advice is very much different - it doesn't matter if it's Irrlight, Orge, pure OpenGL or anything else. If you don't know much about 3D prgramming you'd better start with something different. There are several environments for artists to work with graphics, multimedia and code. Try one of them and watch the projects made in each of them on the project's websitees and on Vimeo. I think most of what you want to do is already done, but still can be very inspiring. The environments that come to my mind are:
Processing - great prototyping environment by Ben Fry and Casey Reas. I use it always before coding anything serious as it provides me with all the multimedia and communication libraries i need, it's simple like hell and it's Java so you can easli deploy your apps after all! (As far as I remember there is touch surface library for Processing)
openFramewoks - same as above but C++, but it's less clean and still under development. It's very easy to prototype in Processing and code finally in openFrameworks as the latter was very much influenced by the former. (The touch surface library is implemented for oF for sure)
NodeBox - great and very powerful environment in Python. Has a very strange but great and intuitive (after all) GUI with some very unique methodolody of work!!
SuperCollider is a wonderful sound processing and algorythimc composition programming language with a very easy to code GUI library and graphics API. It gives you everything you ever imagined about sound programming functionality.
Pure Data - graphical approach toward programming. Made by Miller Puckett (the co-author of Max/MSP) with OpenGL (GEM extension) functionality provided by the guys from IEM in Austria.
Final good advice: Books!!! Programming Interaction (O'Reilly), a few books on Processing website, classic work - Computer graphics for Java programmers (great one, really!!). Read as well all the chapters about domain languages and domain knowladge in "97 things every programmer should know". It can really help!!
BTW: if you don't concider heavy real-time procedures thing about Java (Java2D, Java3D, JOGL) - it's millions times easier then C++ and Processing is actually Java, so you have a very good prototyping environment that can produce ready to use Java classes and applets. I used Processing in real-time theatre productions where stage movement was controlling the sound (syths and hardware samplers) all made in Processing, so this "heavy real-tme" means HEAVY real-time!!
If any further questions about this particular domain programming - don't hesitate to email me.
Coming from PHP won't make C++ any easier to you as riding a bicycle won't make driving a car easier.
Now, I think for Linux, your only choice is OpenGL as an API, and use any of the many wrappers, 3D programming frameworks, and what not available.
Maybe you can go into an easier language, like Python, and if there are OpenGL bindings (which I am pretty sure there is) you can use that, that would make the learning curve more easy and fast.
Update:
Today I wouldn't recommand Ogre3D for a lot of reasons (including very poor long-term interface, which defeat the purpose of a dependency for long term usage - although it does have nice performance sinc v2.1).
There is currently a lot of other alternatives which work well on Linux.
Ogre, using OpenGL on Linux-based OSes, will save your life and time, compared to using OpenGL that is your sole alternative.
That said, to use Ogre, you'll have to know a fair amount of knowledge and practice in C++.
And you will have to know about "graphic pipeline".
You can use C with OpenGL, that seem simpler, but it make you loos time by not providing higher abstraction of the graphic pipeline as Ogre does.
And almost all graphic engines are written in C++ anyway.
Now, if you try to learn C++, take a good book like "Accelerated C++", take a deep and long breath and please forget all you learnt about php before. Be humble in your search for knowledge and you'll get it faster.
You'll be interested in:
OpenGL (obviously)
Box2D (a 2D physics engine)
SDL (a portable media library)
You can find basic tutorials for them on the web. However, think if you really want to code in C++. The language is very powerful, but not easy to learn, and really hard to master. Wouldn't it be better to use a rapid development language like Python with PyGame?
Don't get me wrong -- I love C++ and it's my language of choice, but unless you're working on top-notch performance, operating systems or compilers, it may be overkill to learn C++'s up and downsides the hard way.
You need neither 3D graphics or a physics engine for this. The UI could even be done in a browser using some funky javascript.
However, the audio engine for something like this is going to be a pretty complex, performance-oriented beast, and is probably best done in C++ (or maybe OpenCL).
Finally, are you sure you're not reinventing Pure Data?
I prefer Irrlicht as a lighter, easier-to-learn, but less feature-complete API than OGRE.
It's literally possible to write a prototype in a few minutes in Irrlicht, and the code itself is easier to understand.
The best thing about it is that it would interface seamlessly with Irrklang, a sound library that may help you with your project.
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.