10

I need some specific and some general advice. I'm a fairly proficient Java programmer and a very experienced web programmer, but I would like to get into software development and I've been tackling C++. I have a great idea for a game I'd like to do, and I realize it will be a huge undertaking--but I'm looking at it more for an opportunity to learn C++, wrapping, really whatever I run into in the dev process...

But I can't get my foot in the door conceptually! I can handle the C++ aspect fine, it's just setting up the graphics, the RIGHT way, that's confusing me. I've run through a bunch of tutorials for OpenGL with C++ that all say the different things, none of which I can really get to work...

Some say to use GLUT and GLEW. Some say GLUT is dead and that FreeGLUT is the thing now. Some ignore those entirely and use a bunch of files like "glaux.h" that I can't seem to find--and other tutorials devoted to AVOIDING "glaux.h"... Most tutorials I've found come with the caveat in the comments that their version of OpenGL is dated and I should be using newer libraries-- and still others with 3rd party libraries like Ogre and Aurora.

I've been looking through a bunch of books and tutorials that ALL have an almost completely different setup for using OpenGL with C++. I realized there is probably not one right way of doing it, per se, but I'm looking for the way that is the most current, most popular, and will maximize the usefulness of the project as far as my learning... Any links to tutorials or advice in general is much appreciated.

BTW, I'm using Visual Studio Express 2010 (good idea?). My game won't be too graphically intense (isometric 2d) but will require a TON of logic and a TON of data, which is why I want to speed things up by using C++. Any other insights on better ways of doing it than using c++ for login AND graphics (from an industry perspective) are also very valuable to me! Thanks in advance!

user446882
  • 357
  • 5
  • 16
  • Also -- if anyone has reasons I shouldn't be using OpenGL at all-- fire away. Really, the main concern is my own learning and what is going to help me out in the long run – user446882 Apr 11 '11 at 22:05
  • 1
    Everyone is recommending the NeHe tutorials, but be aware that they are very out of date and use an entire model of execution (not just a set of API commands) that has been deprecated since OpenGL 3. That doesn't mean you can't learn from them, though. – dfan Apr 11 '11 at 22:43

5 Answers5

5

Assuming you're learning OpenGL as a learning experience, I would recommend you this:

Use GLEW, no argument. Just do it, everyone does Code only to the core profile. By default, OpenGL accepts old command (eg fixed function pipeline) that will later disappear, and you don't want to waste your time on that. Specifically: learn about VBO's, texture's, and, most of all, learn about shaders.

Forget about glaux and glut. Freeglut is a good and very standard option. A less obvious choice would be qt, but it's QGLWidget allows you to easily make gl calls, and not worry about context creation and all that. And it's dead easy to add gui options, which is always very nice to have when programming graphics.

To actually learn OpenGL, I would recommend http://duriansoftware.com/joe/An-intro-to-modern-OpenGL.-Table-of-Contents.html. Nehe has that problem where more than half of the stuff is useless to learn, and there's a lot of fluff (window creation et al) around it.

But, I wouldn't really recommend OpenGL as a way to learn real-time graphics programming. Your alternatives are not limited to DirectX. I learned a ton of graphics coding from working with Ogre3D. You still have all the concepts at your disposal that you need to know (working low level with Vertex and Index buffers, Textures, shaders), and implements tons of stuff to make your life easier. You might not learn the ins and outs of a specific API, but you will learn all you need to know conceptually. When I became a graphics programmer, I hadn't written a line of DirectX code, but I got to grips with our engine really swiftly. I learned the actually calls very easy after that. Know the hardware, and the concepts. The actual implementation changes over time anyway.

Oh, and just in case I haven't repeated it enough. LEARN SHADERS

El Marcel
  • 1,767
  • 1
  • 10
  • 11
3

The best tutorial around is (arguably, as anything "best") Nehe opengl tutorial. At least, this tutorial has been suggested for many years.

Also since you come from a Java background you might prefer C# bindings for opengl from frameworks such as Tao, but the actual setup might be harder than say, downloading samples and running them.

Eric
  • 19,525
  • 19
  • 84
  • 147
3

It's easy to see where the variety of choices available for OpenGL with C++ would be a bit bewildering. For the most part, Java gives two a pretty clear-cut choice between two possibilities (do you want a scene graph or not?)

The situation with C++ is certainly more complex.

  1. Glut: This is basically an OpenGL-oriented application framework. It was apparently written primarily to allow examples to be short, but still work. The original implementation has some pretty well-known bugs, and hasn't been updated in over a decade. I would only use it in roughly the originally-intended context: short samples/examples/demos.
  2. glaux: The story here is sort of similar to GLUT. It has some memory leaks that have been known but unfixed for over a decade now. It was never portable in any case. I'd avoid this one completely.
  3. GLEW/GLEE: These allow relatively easy use of the functions added in newer versions of OpenGL from OpenGL implementations (e.g., Microsoft's) that haven't been updated to include headers/libraries to provide access to them directly. I prefer Glee by a small margin because it initializes itself automatically, but both work fine.
  4. FreeGLUT: This has been updated more recently, and some of the bugs expunged. It still hasn't done much to improve the basic design of GLUT though. Probably a better choice for short demos/samples, but still not (IMO) suitable for much serious use.
  5. Ogre3D: This is much bigger than any of the preceding libraries. It's a full-blown scene graph library, with texture loading, defined file format, etc. A solid library, but be aware that if you use it, you won't normally use OpenGL directly at all (e.g., on Windows, it can render via either OpenGL or Direct3D without changing the source code at all).
  6. OpengSceneGraph: More often used for scientifically-oriented applications, but most closely comparable to Ogre3D.
  7. FLTK: a small, lightweight GUI library that runs on top of OpenGL.
  8. GLFW: In the same general spirit as GLUT, but it's been updated much more recently, doesn't have nearly as many bugs, and is (IMO) a nicer design -- minimal but still suitable for "real" use.
Jerry Coffin
  • 476,176
  • 80
  • 629
  • 1,111
2

You should be using OpenGL if you want to write portable 3D applications. Windows, Linux and Mac OS X supports it.

You might want to take a look at NeHe tutorials. It's one of the best OpenGL tutorials available on the web.

karlphillip
  • 92,053
  • 36
  • 243
  • 426
0

My understanding is that if you want simple support for a recent version of OpenGL you'll have to leave Windows-land, so try take it in stride when getting started is ... complicated.

I think OpenGL is probably the right choice. You might also want to consider DirectX (which is better supported on Windows), but I'm personally not a big fan of it. You could also learn C# and use XNA, but if you want to learn C++ it just defeats the purpose. (I also can't help mentioning there's a good chance you could make it fast enough without C++)

I have to agree with the others that NeHe's tutorials are pretty much classic. You might also want to consider the OpenGL Red Book, but that costs money.

Regarding the 3rd paragraph, GLUT is old (and for that matter so is GLU), but if you see a good tutorial that uses them, I don't see anything wrong with them. Once you have your feet wet you might want to consider ditching GLUT and using SDL which I believe is a lot more 'alive'.

As far as GLEW goes, I've used it with success and it's nice if you want to do something fancy like shaders on Windows. However, I would say don't worry about it at first, because it will increase your setup time and keep you from getting to the fun stuff :)

Brandon Bohrer
  • 207
  • 1
  • 4
  • 1
    "My understanding is that if you want simple support for a recent version of OpenGL you'll have to leave Windows-land, so try take it in stride when getting started is ... complicated."-----------Since when does windows lack support for opengl? – Thomas Dignan Apr 11 '11 at 22:40
  • I've used C#'s XNA before, but I want to avoid it for this project-- and I'm sure (just look at MineCraft) that Java is probably capable of handling what I want to do-- and indeed I might end up using Java (or C#) for the graphics/interface, and C++ for the logic. Does the SDL work in Java as well as C++? – user446882 Apr 11 '11 at 22:43
  • @Tom - Key words being "simple" and "recent". I know Windows supports OpenGL, but I don't know of a way to get fancy features like shaders without going through some extra hoops (like GLEW). – Brandon Bohrer Apr 11 '11 at 22:53
  • There's a Java wrapper for SDL: http://sdljava.sourceforge.net/. I don't know how well it works, though, or how easy it is to make Java and C++ play nice with each other. – Brandon Bohrer Apr 11 '11 at 22:56
  • 1
    @Brandon, @Tom: Using the fancy parts of OpenGL without some wrapper is a mess on every plattform. Yes, one can directly link to OpenGL-3 functions on *nixes, but at the cost, that the program will abort with a cryptic "unresolved symbol to libGL.so" message, if a recent enough library is not installed. Also having the functions linked doesn't mean what they provide is actually supported by the system. – datenwolf Apr 12 '11 at 06:05
  • @datenwolf True, I suppose I was just thinking from the standpoint of someone who's getting started. On *nix it seems like you could get started more easily doing it the quick and dirty way, even if something that's ready for release will take more effort. – Brandon Bohrer Apr 13 '11 at 02:00