Better books for Programming OpenGL and SDL...

Hey, so i recently Finished reading C++ in 1 hour a day (Sam's) and have gotten to chapter 4 in the OpenGL superbible 5, as after some research I found OpenGL + SDL was highly recomended for game programming 2d and maybe 3d.

Well i've come to quite a few rather frustrating impasses in attempting to manage and use matrices to render multiple 3d shapes without F*&king em up and getting a blank window.....

I don't really like how the book organizes the tutorials/ when it teaches what, so i'm thinking i should try out the RedBook even if it's rather outdated....
Any other Suggestions for recent books to help me learn OpenGL slower and more in-depth?

Thanks in advance!! :)

Have you seen this -> NeHe Productions: Main Page

Yes, i have but the tutorials do not seem to even mention Shaders and matricies which it what my book says OpenGL is all about.... So i guess i'm a little confused?
My book is newish (2010) so i would imagine it would be most relevant

You don't need to use shaders to simply render multiple shapes. A shader gives you precise control over how the vertices of an object are rendered, and how each pixel in the framebuffer will be drawn. They're generally used to do special lighting effects, maybe reflections or bloom or bump-mapping. If you just want to display a few objects you can let OpenGL figure out how to do it.

When drawing multiple objects, remember to push and pop matrices whenever you're switching objects or whenever you deem it necessary. glLoadIdentity() will reset everything, which may be useful. Also remember that the matrices will be applied in the opposite order that you think they will be! Say for example you want a rotated cube at position 3, 4, 5. Logically you would glRotate() first and then glTranslate() -- otherwise you'd be rotating an object far from the origin and it wouldn't end up at 3, 4, 5. But because of the order in which OpenGL multiplies matrices you'd actually write glTranslate() first and then glRotate(). If this sounds unfamiliar to you, definitely read up on OpenGL's transformations.

The NeHe tutorials are quite good, I suggest you at least take a look at them. For example: NeHe Productions: OpenGL Lesson #10

Quote:

---

Originally Posted by GRIFFnDOOR

I don't really like how the book organizes the tutorials/ when it teaches what, so i'm thinking i should try out the RedBook even if it's rather outdated....

---

outdated: In what sense? The 7th edition is < 2 years old, and apparently the 8th edition is now ready for order but not yet released. I know that many people will throw information at you, but WRT programming: you do need to do at least a little bit of your own research before you blindly accept and regurgitate those opinions. I'm not saying this to be mean, or to argue, but because it is you that will suffer the consequences of thoughtlessly absorbing casual, and factually inaccurate, statements made by whoever on some old blog or forum post. And "whoever" does that kind of thing here, there, and everywhere all the time. So their "outdated" opinions remain current, lol.

The red book is called the "The Official Guide to Learning OpenGL" because it is written by members of the OGL ARB which works with Nvidia and ATI to maintain a reasonable common standard. There is no sense in which it could be considered "outdated".

There is also the "orange book" which covers the GL shading language in more detail and I think the "green book" which covers openES, used on mobile devices...

It is certainly true that the current GL "standard" the ARB are responsible for depreciates most of the "immediate mode" methodology you will find at NeHe and elsewhere, in favor of methods that would make GL shaders a mandatory element. However, this depreciation does not mean those (non-shader) methods will not work, as in fact Nvidia (at least) has refused to depreciate them. GLSL is a complete headache as it is not conventionally debuggable and has very restricted IO to exploit for such purposes. You may think you need to get into it like some people may think they need a carbon fiber bike frame because they can now ride without training wheels, but honestly, as dwks (pay attention to dwks WRT OGL) says, you do not need to jump into it right away. Get a grasp with immediate mode -- as in, complete some serious projects -- and at that point you will have familiarized yourself enough with the traditional fundamentals to be able to decide for yourself where to go. DO NOT get caught up in buzz words and bleeding edge suchness you do not understand. There is nothing more annoying than people who can barely code "hello world" but still want to drive a real formula 1 -- get it?

If you cannot reach the shelf, consider what is under your nose. In years to come, you may be grateful for the experience that even younger people did not have ;)

Quote:

---

Originally Posted by dwks

Also remember that the matrices will be applied in the opposite order that you think they will be! Say for example you want a rotated cube at position 3, 4, 5. Logically you would glRotate() first and then glTranslate() -- otherwise you'd be rotating an object far from the origin and it wouldn't end up at 3, 4, 5. But because of the order in which OpenGL multiplies matrices you'd actually write glTranslate() first and then glRotate().

---

It makes more sense the way it is, because there is a hierarchy of coordinate systems, and this works with the hierarchy instead of against it. The most "specific" transforms are at the top of the stack. This idea is supposed to make things simpler, not harder to understand. You're handed some random stack of transforms which represents the current view, you tweak it in a minor way for a particular object, then put it back. If it were the other way around you'd have to rebuild the rest of the transform on top of your specific transform, which means you need to KNOW that transform, which makes the code suck.