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 want you to help me for a decision problem.
I am a newbie video game programmer. I can develop Flash, Unity, Android games, and I know a little CryEngine. Also, I want to develop 3D video games in the future.
So, I decided to learn a video game library that I can work with C/C++. But should I learn Allegro or OpenGL or a different library? Or should I directly start to learn DirectX programming? Learning Allegro programming is useful (a good basis) or just a waste of time?
But should I learn Allegro or OpenGL or a different library?
First and foremost: OpenGL is not a library! The 'L' of it once meant library, but it's better to backronym it as "layer", because that's what OpenGL really is these days: A layer between your program and the graphics hardware.
OpenGL is not a game engine, it's not a game graphics library. OpenGL is a low level drawing API. You can use it to draw points, lines and triangles in fancy ways. But there's no scene, no objects and such in OpenGL. All this must be implemented by the game engine. Writing a game engine is very hard work. If you really want to go for this, I suggest you look at the source code of Doom3, which has been released a year ago.
Allegro has almost nothing to do with OpenGL.
Allegro is a basic framework for simple game development providing rudimentary 2D graphic primitives, user input, text, sound, timers, etc... You can use OpenGL under Allegro, but there is no tight and specialized integration.
OpenGL is a low level API, specialized for graphics.
If you already know Unity and CryEngine, stick to them. It would be a tremendous difficulty to implement even a fraction of their features using OpenGL on your own. That doesn't mean you shouldn't learn some OpenGL, even for the sake of curiosity and understanding how stuff works on the low level.
DirectX is platform limited, and while it is true the majority of gaming platforms do support DX, ARM mobile platforms are on the rise, and DirectX doesn't run on them. OpenGL can match pretty much everything D3D has to offer, and it is more portable, so it is the API that is more worth investing in, unless you are centered on Windows games exclusively. Then it would make sense to learn D3D, which is a little easier to use.
Many game engines, including Unity, will abstract away from the graphics API and use the best what the target platform provides.
Also, keep in mind that OpenGL is not available on Windows 8 in "metro" mode, so you will either have to use D3D if you want advanced graphics under metro mode, or use ANGLE and stick to more basic subset of OpenGL that is emulated with ANGLE on top of D3D.
Related
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 just purchased the fifth edition of the OpenGL SuperBible. I'm very pleased that they've avoided using deprecated functionality but their examples make use of GLTools. GLTools provides a slew of useful functions for rendering simple 3D objects and managing the view frustrum, camera, and transformation matrices.
This is all great but the abstraction provided hides low-level details and I'm having difficulty moving to code where I can't use GLTools -- for example, pyopengl. The vast majority of tutorials I've seen online make use of immediate mode, which I'm trying to avoid. Those that use glDrawArrays make use of glEnableClientState, which I'm also trying to avoid.
What I'm looking for is introductory tutorials that are fully OpenGL 3.x compliant. If that's too tall of an order, perhaps a laundry list good "starting point" functions would be in order.
Stay away from NeHe, the tutorials are hopelessly outdated and contain a lot of "problematic" stuff, too.
For starting with 3.x, try those, they're both up-to-date:
Aurian (Joe Groff)
Arcsynthesis (Jason L. McKesson)
Update:
Re-reading my own post almost 2 years later, I guess that one might find that it sounds a bit harsh.
This is of course not the intent. The core message (which remains valid) that I wanted to give was that NeHe still deals with OpenGL 1.x/2.x and uses some unsupported "antique" libraries.
Generally, as such, this does not mean the tutorials are necessarily bad, but starting from there will mean starting two generations behind the current state-of-the-art, and one generation behind the minimum one should learn. Learning legacy OpenGL will, at a later time, require you to forget almost everything you know and re-learn from scratch.
That said, the NeHe front page now links to a tutorial focussed on OpenGL 3.3 by Damien Mabin, which looks quite nice at first sight (though I will not have time to thoroughly read through it before new year).
https://bitbucket.org/rndblnch/opengl-programmable
a short step by step tutorial to OpenGL programmable pipeline (OpenGL / OpenGL|ES 2.x) for people already familiar with the fixed pipeline. dependencies: python 2.5+, PyOpenGL 3.0.1+
Successive versions of a small but rather complete glut/opengl program that starts from direct mode and is transformed step by step to run exclusively on the programmable pipeline.
Look at the diffs between successive version to have an highlight of the changes needed (e.g., https://bitbucket.org/rndblnch/opengl-programmable/changeset/b21131e37ed7).
Here is a serie of OpenGL 3.3 tutorials for Windows, that doesn't use any of deprecated functionality, only new stuff:
Megabyte Softworks OpenGL 3.3 Tutorials
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.
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 10 years ago.
Is there a good book that focuses on the programmable aspect of OpenGL 3.0
I want something like the OpenGL Super Bible, but focusing solely on the "new testament" part -- the programmable rather than the fixed pipeline.
The Orange Book: http://books.google.it/books?id=kDXOXv_GeswC&dq=opengl+shading+language&printsec=frontcover&source=bn&hl=it&ei=KChiS7-_Ityi_QarxsyMDA&sa=X&oi=book_result&ct=result&resnum=4&ved=0CB4Q6AEwAw#v=onepage&q=&f=false
The latest 5th edition of the OpenGL SuperBible does focus only on the core profile. Unfortunately it includes it's own gltools library so most of the start of the book is really more teaching that toolkit rather than the core profile itself, of course it covers the basic overall layout of a modern opengl program and does seem to fill in the harder stuff later. As you progress though it seems you reimplement the crutch library.
The OpenGL Programming Guide (The Red Book) 7th edition, unfortunately seems to be rather dated. They have marked everything that is in the compatibility profile rather than the core, but thats about it.
There is an 8th edition being released in December 2012 that is apparently a rewrite teaching modern approaches.
Realistically it would be best to learn the specific areas on the compatibility profile/OpenGL 2.1 then combine them all together into something that is core profile. Doing it all at once is just too much at once.
First learn Vertex Buffer Objects (and ditch glBegin/glEnd and anything that goes in between).
Learn manual Matrix operations and stack, or an appropriate library (ditch glPushMatrix/glTranslate/glRotate/glOrthagonal/gluLookAt/glFrustum, you may need to use some compatibility stuff to bind your manually processed marices at this stage but you can ditch them with the shader next step)
Learn Vertex & Fragment shaders
Learn how to set the OpenGL context to 3.1+ (Dependant on your windowing system).
The book OpenGL Programming Guide: The Official Guide to Learning OpenGL, Versions 3.0 and 3.1 (7th Edition) was updated and explains the new features of OpenGL 3.0.
If you want a shorter, simpler OpenGL book that covers just the programmable pipeline, I'm going out on limb and recommending OpenGL ES 2.0 Programming Guide. OpenGL ES 2 is a subset of OpenGL, to make it simpler for embedded systems. For most situations where there is more than one way of doing something in OpenGL, the OpenGL ES standard includes only one way. Version 2 of OpenGL ES is for programmable hardware, and therefore includes just the programmable pipeline stuff. Since OpenGL ES is a subset of OpenGL, everything in OpenGL ES will work on an OpenGL implementation. Whereas the "OpenGL Programming Guide" is 936 pages long, the "OpenGL ES 2.0 Programming Guide" is merely 480 pages long.
"The Red Book" was the openGl book when i was studying it, but that was long ago, you'd have to find out if they've continued to update it as far as v3.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I am reletively new to c++ programming can anyone please tell me how does Direct-X SDK is helpful and how does it works and how can we use it in game programming.I Downloaded it and I found lots of header files and documentation also tells something about game programming.
DirectX is a library (a large collection of classes, really) that allows you to "talk" to the video adapter, sound card, keyboard, mouse, joystick, etc. It allows you to do it much more efficiently then other "standard" Windows functions. This is important because games need all the performance gain you can get - and DirectX has plenty to offer in this regard. Especially when it comes to graphics programming, because it has functions that enable you to use the 3D acceleration features of your graphics card. Windows doesn't have such functions by default.
The DirectX SDK contains:
Documentation for all the features of DirectX;
Tutorials in the C++ language to get you started if you don't know anything;
Sample applications;
The necessary .h and .lib files to add DirectX support to your program;
The debug version of DirectX (I think, I'm not so sure about this one)
The DirectX redist that you can include with your own programs.
If you're not up to speed with C++ then starting with DirectX development will be quite difficult, as either of these things has a pretty big learning curve.
Btw - you did download the latest version from Microsoft webpage, not a 5 years old copy from some web guy, right?
Your question is way to broad. DirectX can help you create games in more ways that you can (considering youre new) imagine.
Rendering (putting stuff on the screen), input (responding to what happens on the users mouse/keyboard), network (for multiplayer), reading files, fonts, 3D-models, sound. To name a few.
I urge you not to try to write something yourself directly utilizing DirectX. Getting something good out of it is an extremely complex task. Dont reinvent the wheel unless you plan to learn more about wheels. (The wheel here being DirectX.)
If you just want to get up and running and make World of Warcraft 2, I suggest you use premade DirectX implementations (usually called game engines) such as Ogre, Irrlicht or HGE (simpler, but only for 2D games).
Good luck, dont give up and welcome back later with your first real question. :)
I'd like to add that "game programming" does not necessitate graphics programming. DirectX, like OpenGL, provides a basis to create a graphics application; but, as mentioned, it's very low level.
As a professional game developer, I would not suggest just jumping into DirectX after learning C++. It's a difficult endeavor that will move slowly and provide you little motivation to continue. It's definitely something to keep in mind for your future; but, for the moment, it would be more beneficial to play with something complete, possibly start with gameplay programming.
Note: In addition to C++ skills, you will also need some mathematical talents. Linear algebra and trigonometry are the primary concerns.
Check out a lightweight engine like Angel. It's a fairly intuitive starting point and small enough that you can fully understand what's happening within it.
As always, try to make small edits and projects for yourself in the beginning and then move on to bigger and badder tasks!
Good luck!
I'm not entirely sure what you're asking, but Frank Luna's book on DirectX is a very good intro.
But if you're a relative newcomer to C++, DirectX may be too low-level for what you're looking for. I mean, are you looking to create a colorful rotating cube, or do you want to make a semi-complete game? Assuming the latter, you probably want a framework that abstracts away the low-level details of either DirectX or OpenGL. For that, I can heartily recommend Ogre 3D. The tutorials alone will get you up and running before you know it.
Read: The Art of 3D Game Programming with Direct X 2002.
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 10 years ago.
I am new to OpenGL.
Wondering if there is any good Scenegraph API/framework for OpenGL.
At the moment I am using glut with a custom node based solution: I am setting children and siblings for each node the calling a traverse function.
I'd like a more flexible solution when it comes to managing dynamic elements in the scene.
SDL is a bit more up to date than glut, but you are on the right track with rolling your own graph structure to manage scenery. There are plenty of frameworks available. OpenSceneGraph, for example, has been around for quite awhile now. OGRE has a large following as well. However, it is not a strictly OpenGL library as DirectX and software renderers are also available.
You may want to look into related topics like binary space partitioning, quadtrees/octrees and kd-trees.
I agree that openscenegraph is a great scenegraph. It is written i C++ and has bindings to some other languages, but not for .NET as far as I know. We were in the situation to use something more than plain old opengl and were looking at managed directx, xna, wpf and opengl. We chose to write our own scenegraph based on Tao.OpenGL as opengl.
You can accomplish dynamic objects by having an update phases before the culling and rendering stages. If you do multi-threaded you need to be careful with the update stage.
There are plenty of libraries treating this topic. Here some of my favorites:
VTK - extremely suitable and open source
Coin3D - very good commercial scene graph
OpenSG - just for completeness :-)
I second (third?) the use of OpenSceneGraph. It is robust and cross platform, and integrates well with Qt (our application runs on MacOS, Windows, and Linux using OpenSceneGraph and Qt together). The documentation may not be as polished as a commercial option, but there's a book you can buy (and a free Quick Start Guide) that really helps.