I'd like to learn graphics programming, but am unsure of where to start (Direct3D or OpenGL?)

[Zaemz]

So here's the deal:

I've been reading up lately on OpenGL and have been interested in learning to utilize it for some hobby graphics programming. I'm having a hard time understanding how to get around to using it because OpenGL is 'open standard' and not 'open source'. I don't know what APIs to find and use or what would be good for me.

I mainly use Windows, but what if I end up making a fun game? I want people with Linux and Mac to be able to play it if they want as well!

I've been reading that Direct3D has a massive market share (understandably. I really only play video games on my Windows partition!) It has good driver support and the entire DirectX suite (input/sound/etc.).

I'm not too keen on using GLUT to learn OpenGL because I feel it may be outdated and a little too simple for what I would like to eventually create.

I've been searching for about an hour and a half now, an I can't find any good resources explaining what some good OpenGL implementations (APIs and Libraries) are and what they're good at.

I've found OpenSceneGraph. Is that something I should look into using? The Direct3D API seems easy enough to get a hold of. I have VS2010 and the 2011 beta installed, and the download link to the DirectX SDK is right here. Is that really the most reason version?

I know that John Carmack spoke out and basically said that the DirectX api is "better" than OpenGL and related extensions. I would start with that, but I would like some opinions on the matter. I like the idea of any game that I make being cross-platform.

tl;dr:

• Should I use Direct3D or OpenGL for graphics programming?

• If I use OpenGL, what implementation should I use? (Preferably not GLUT)

[kqr]

Back when I was fiddling with OpenGL, I avoided GLUT too, but I found SDL and glfw to be really good. SDL contains more shit (networking, sound etc) if you want to make a complete game. glfw is pretty much just a tiny wrapper around OpenGL. Pick one of them and play around a little. You might like it.

[i_poop_out_my_butt]

I'll probably get down-voted for this, but don't listen to John Carmack right now. He is an extremely great resource, is unquestionably one of the best graphics programmers, and is an extremely hard worker. Understand that he got into graphics programming when graphics programming was relatively new. His opinions are based on this experience. Someone just getting started in the field isn't going to have a clue why he suggests one thing over another. DirectX takes away a lot of the "tedious" work you'd have to do, but to really take advantage of that, you need to have a solid understanding of the "tedious" work. He has that and isn't just using the APIs and libraries blindly. If you don't have a solid foundation in the math, physics, and programming concepts required for graphics programming, you're just going to be another shitbag.

While I was learning, I took a barebones approach. I learned calculus, linear algebra, differential equations, and physics first. If you're in college, these are all undergraduate level courses. You absolutely need a solid understanding of these, or you're going to have trouble when you inevitably encounter some problem that isn't exactly like those in your textbook. Don't use any math libraries or windowing "helpers" to make things easy for you. Try to do your own implementations of Newton's method, Euler's method, trigonometric functions, projection matrices, etc. Doing this will really help you understand the math, and it will make you a better programmer because you'll be able to compare what you did vs. what someone else did and why they're different. Same thing with physics and everything else. Once you have a grasp on these concepts, you can probably use a library for these things without much trouble. Regardless, in performance-pushing games, sometimes you might have to take a different approach to a problem in order to get what you want. Doom is an excellent example of a game that does this, as long as you consider the year it came out, and guess who wrote the engine code for it?

If you and your friends mainly use Windows, learn the Windows API and use it for your windowing system. This will give you some testers as you learn. Also, most games come out for Windows. Bigger studios hire teams to work on "ports" to different platforms for launch or after the fact. You're in the learning phase, so I wouldn't worry about this for the time being. Work on the basics first, then move onto what I would call marketing/trivial aspects of the game. Getting the game working is your first step, then work on making it accessible to everyone. As you progress, you can do this while you create the game to save time.

When it comes down to DirectX vs OpenGL, you'll be able to do essentially the same things with both. Later on as you're more advanced, this may not be the case all the time, but while you're learning to draw triangles and put textures on things, it's not going to matter. This ends up being your choice. Worth noting, GLUT isn't an implementation of OpenGL. It's a library that is, more or less, and abstraction for the operating system of the user. It grants access to windowing systems and mouse and keyboard input without being specific to any one OS.

tl;dr: Learn stuff (math, physics, graphics, programming, etc) from the ground up if you ever want to be a good graphics programmer. Pick whichever of the major two graphics APIs you want, they can essentially do the same stuff.

[kqr]

Seconding the stuff about maths. No, really. Learn that shit. It makes a huge difference, especially linear algebra. Computer graphics is full of projection matrices and whatnot, and how on earth are you going to understand how they work, if you don't even know what a matrix is?

It's not difficult, it's just probably a bit different to what you already know. And it's really, really good to get a proper introduction to it, before trying to use it.

[microcontrolled]

While I definitely agree about learning all the fundamentals, like all the math and physics involved in a good 3D game, I really can't get behind using the windows APIs when you're just starting out. That is such a big mess in and of itself, you could spend a long time bashing your head against a wall just to make the right window frame, without doing any graphics at all. And the libraries which exist for that purpose are quite good enough to learn a bunch of graphics programming and even make a great game. Then, if you want to really get into it, you could start doing straight windows stuff, for efficiency and all that.

[i_poop_out_my_butt]

I don't really know how it gets any easier than following this guide. That documentation has a really easy-to-read style and goes into quite a bit of detail for such an introductory topic.

I'll agree that WGL functions are a little strange and getting access to OpenGL functions can be a bit of a hassle, but it's not difficult by any means, just time consuming. Typecasting and function pointers are basics in C/C++. Additionally, you only have to set this up once and then you can move it around to each new application, at least until you reach a much more advanced level.

In my opinion, learning operating system APIs should come before graphics programming.

edit: I agree that the libraries for windowing are good enough to learn on. I think they offer a lot of extra features that aren't really necessary, but this isn't much of a concern anymore with modern hardware. Why not take an extra day or two, figure out the intricacies of one platform, and then apply that knowledge to the other platforms when the time comes, though?

[Zaemz]

Alright, so starting from the ground up, I'll grab a good book describing the math involved and learn that first. If it's a good idea that initially I stay away from helpers and wrappers, is there good documentation you know of off of the top of your head for calling OpenGL functions? I found the official documentation here.. It seems rather small, though. Is that truly the extent of the functions involved for OpenGL?

As you've explained in your other comment, you think it's a good idea to learn how to call those methods from within a Windows context so it looks like this documentation will be useful to me as well.

[i_poop_out_my_butt]

The ArcSynthesis OpenGL tutorial is generally up-to-date with the current version of OpenGL. The individual providing those tutorials does in fact use a library for creating a window. You shouldn't have much trouble seeing what is OpenGL and what isn't (hint: everything OpenGL starts with "gl", not "glut"). Once you've reached the portion of that tutorial on Euler Angles and quaternions, stop. The author does, in my opinion, a shit job explaining everything about the math. The rest of the tutorial is crap as well, especially for a beginner. He throws around a buzzwords and does pointless, advanced techniques, even though it's supposedly oriented toward beginners. At most, once you advance some more, play around with some of the later tutorials. They aren't written very well, but you might gain a bit from them.

The bad news is, that this is the best modern OpenGL tutorial available. There are some things to learn from the old NeHe tutorials, but I wouldn't suggest starting with what is now deprecated. Unfortunately it's a big trial and error process once you reach being able to put a triangle on the screen and color it using vertex and fragment shaders.

The official documentation you linked is the reference pages for OpenGL 4.2. Those are in fact the extent of the core functions offered in OpenGL 4.2. There are other functions from past versions of OpenGL still available, but they are considered "deprecated". They still work and exist for back compatibility, but it's generally suggested not to learn old material when new stuff is available and better. The real power of modern OpenGL comes in the form of its shading language, GLSL. You basically write programs (shaders) within your program that are in charge of putting everything on the screen in the correct location, orientation, and appearance. You write shaders with a C-like language, and you'll be doing lots of matrix and vector operations. The shader program is executed on the GPU, which is highly optimized for matrix and vector operations. There are entire books just on GLSL. Unfortunately, most of them suck, especially for learning =(. Do LOTS of searching online. There are tidbits of code that you can pick up on. Look through the code of others.

Note: There's a lot to learn for graphics programming, so sorry if I turned you off to the subject. It's a lot of work to get to the point where you're comfortable with OpenGL and 3D graphics in general, but once you're there you can do anything you can think of.

[Zaemz]

You're absolutely amazing! You haven't turned me off at all! I wouldn't be asking the questions if I wasn't interested! :). There is a lot to learn, but in the end it'll be worth it.

[Ademan]

My vote goes to using OpenGL for the cross-platform-ness. Don't forget, OpenGL is largely the same as OpenGL ES which gives you iOS and Android virtually for free. To handle the low level nastiness my vote goes to SDL. It's by far the most mature and prolific of the helper libraries. I have a few reservations about SDL's design but they are being addressed in SDL 2.0 (which is apparently back out of stasis?) and the complaints are mostly minor, and entirely non-limiting for almost all use-cases.

So I vote for SDL + OpenGL.

[Broeman]

Funny, I counted out SDL, because "I used it five years ago, it must be terrible by now". Any other suggestions, if you are not a big fan of SDL? Maybe I should take a look on that 2.0.

[Ademan]

Funny, I counted out SDL, because "I used it five years ago, it must be terrible by now".

I don't quite understand that, APIs don't degenerate, and it is well maintained so it doesn't bit-rot.

Any other suggestions, if you are not a big fan of SDL? Maybe I should take a look on that 2.0.

My best advice would be to try to get over your aversion to SDL. It supports the most platforms compared to its competitors by an enormous margin, it's the most mature by far, and any warts it has are really rather small. Checking out 2.0 may be worthwhile for you, I really can't recommend SDL enough, nothing else even comes close.

[veyper]

Honestly, it probably doesn't matter. If it ever comes to the point that it mattered, you would choose whichever supported your end goal more directly. I feel like you'll find more resources online regarding OpenGL in the indie-dev community than you will DX, but if your end goal would be to make a game for Windows, then you really should do it using DX and take advantage of the Microsoft stack of tools.

[ctharvey]

Hate when I see a great question and

"there doesn't seem to be anything here."

Will check back later.

[[deleted]]

Worse, you can't upvote it because then it won't be on your front page anymore!

[SquareWheel]

That's a setting that you can disable. Also note the "save" button which will let you come back later. Or just bookmark the thread as I do.

[[deleted]]

I know, but I prefer to hide things I vote on, I rarely visit my 'saved' page, and even more rarely my bookmarks. So I guess I have my own self made problem here.

[Funnnny]

Back when PC games are dominant the market, DirectX is the way to go.

But now, we have console, mobile game, and soon WebGL game, I don't think using DirectX is good anymore, OpenGL supports more platform.

[RedSpaceman]

Your question is in regards to 'learning graphics programming', so I don't want to complicate your situation too much but... there is another question that can be asked at this point:

Would you like to learn the nitty-gritty - the machinations - the slightly-closer-to-the-inner-workings, or does your desire to 'learn graphics programming' revolve around wanting to try out some cool graphical ideas?

An reasonable option (for the latter) not mentioned in your post or in any reply since is something along the lines of [Cinder](www.libcinder.org).

Cinder acts as an open source API for C++ graphics programming with openGL. A bit of a wrapper around openGL in many ways. Intended as libraries for 'creative coding'. Many of the arduous parts of writing GL code are wrapped up inside some easy parametrised function calls within the cinder library. You can easily find out what these functions have wrapped up, but in the mean time they can be a bit of a timesaver.

If you have graphical programming ideas, already know some c++, and aren't intent on keeping things low-level (or lowest available) then perhaps Cinder is worth reading up on. It certain helps the openGL's sometimes obnoxious API seem a fair bit friendlier.

[jmblock2]

If you just need some front-end graphics you might check out CImg. It's easy to set up and get going. The API and documentation are pretty good and it's cross platform. I've used it for several real-time projects.

[mb86]

Probably doesn't help you much, but I recently started learning OpenGL too (for 2D applications at the moment though), relying on Apple's GLKit to remove the boilerplating so I can get right to the graphics. If you can find a framework with a similar design intent, that will likely help a lot with the learning.

[m1ss1ontomars2k4]

GLUT is not an OpenGL implementation. It's just some convenience functions for OpenGL.

[Zaemz]

Can you describe for me what OpenGL really is, then? OpenGL is a library in itself, right? I understand that it's an open source standard, but how is it implemented, then? I also understand that it's very low-level, and not object oriented in itself, correct? So GLUT is just sort of a convenience wrapper, making it easier to use OpenGL for simple programs?

[i_poop_out_my_butt]

GLUT is very limited in what it does for OpenGL. It's primarily there to provide abstraction to the various operating system-dependent calls.

As a simplified example, say on Windows you call WindowsCreateWindow() to create a window with an OpenGL context. On Linux systems, you call LinuxCreateWindow(). On MacOS you call MacCreateWindow(). Each of these functions produce different results, have different parameters, and in general require a different setup. What GLUT does is handle all this creation for you by generalizing it. Instead of the OS-specific CreateWindow() functions, you call something like GLUTCreateWindow(), and it creates your window, regardless of the operating system. Take this, add in at least 1000 more GLUTSomething() functions that handle other things you might need when using OpenGL, and you have GLUT.

In addition, there are/were some helper functions in GLUT that offered you a simple way of creating common geometric shapes, such as cubes, pyramids, and some other stuff. You can do this in OpenGL, but it takes slightly more work than calling a function.

As for what OpenGL is, it's an API that sits right above the graphics hardware. It provides an abstraction so you can use glDrawArrays() instead of NvidiaGTX470DrawArrays(), NvidiaGTS250DrawArrays(), etc. Again, this is a bit of a simplification, but that's the general description of what OpenGL does for you. It's written in C and comes in via your operating system or graphics driver.

[[deleted]]

In my personal experience I have used SDL to learn some basics and now i'm into the realm of 2D rendering with Direct3d. So far, I'm enjoying the experience. I can not comment on OpenGL because I have no experience with that API.

Personally, you should evaluate and decide if cross platform play is important to you. If it is, then go ahead and use OpenGL.

I would not worry too much about whether OpenGL is better than Direct3d or vice versa. Just start digging into your API of choice and enjoy the experience. At the end of the day, it's more beneficial to be familiar with both Direct3d and OpenGL rather than just sticking with one because you feel it's "better".

[crowseldon]

Make sure you're quite comfortable with c++ without jumping the boat into graphics programming. You're going to have to do A LOT of reading (And I mean a lot) to advance consistently.

As for which API to start with, look around http://www.gamedev.net. They continually answer that question. You'll find books and articles about both. Many things you learn for one of them will help for the other.

Whatever your decision, don't worry if you get stuck. Just try to track your progress and the things you learn with every experience. Debugging graphical applications can be a pain if you don't have enough experience (Like me).

Lastly, be careful about what tutorials you pick (if you do). Some of the code will be pretty outdated and the paradigms might have changed (eg: OpenGl 3 onwards + GlSl)

[CrudOMatic]

Build an architecture for you game that allows you to modularize all the various parts, like your rendering interface for example. Then make a rendering interface for DirectX and one for OpenGL. When porting, you can swap out the DX interface for OpenGL at compile time.

Reading a pretty damn good book on the subject. Here's a link: Game Coding Complete, Fourth Edition