OpenGL SuperBible 5th ed. 98
asgard4 writes "OpenGL SuperBible in its fifth edition is almost a complete rewrite. The authors threw out the discussion of old-style, fixed-function programming and replaced it with an introduction to OpenGL that is exclusively focused on using shaders from the very beginning. All the things that got deprecated with the advent of OpenGL 3 got removed, making it a more relevant and up-to-date book than the previous editions. The OpenGL SuperBible still strives to be the 'world's best introduction to OpenGL' according to the authors. Let's see if it can keep that promise." Read on for the rest of Martin's review.
With the removal of the fixed-function pipeline, the OpenGL SuperBible is no longer quite the heavy-weight it used to be. It shrunk from more than 1200 to about 970 pages, which is not necessarily a bad thing. The book starts out with a basic introduction to 3D graphics, coordinate systems, and some basic math concepts, followed by short rundown of the history of OpenGL and a first little example program that renders a triangle. The authors even provide instructions on how to setup the C/C++ projects to build the example on Windows and MacOS. The writing is to the point but still verbose enough to easily follow the text. The authors analyze the example program in detail making it easy for a beginner to follow and understand the code. Overall, I really like the writing style and the flow of the book.| OpenGL SuperBible (Fifth Edition) | |
| author | Richard S. Wright, Jr., Nicholas Haemel, Graham Sellers, Benjamin Lipchak |
| pages | 969 |
| publisher | Addison-Wesley Publishing http://www.awl.com |
| rating | 9/10 |
| reviewer | Martin Ecker |
| ISBN | 0-32-171261-7 |
| summary | : Quite possibly the best introduction to OpenGL 3.3 programming that focuses exclusively on graphics programming using shaders |
The next few chapters gradually introduce more and more OpenGL API functionality intermixed with new 3D graphics concepts, such as rendering points, lines, and polygons in various ways, alpha blending, how to use geometric transformations and projections, and how to move objects and the camera. Eventually, basic texture mapping is introduced with most of the basic things you need to know about the topic. In particular, specifying textures coordinates, sampling textures in the fragment shader, the various filtering modes (even anisotropic filtering), and texture compression are discussed. In a later chapter the authors do another deep dive into the topic of textures, in particular rectangle textures, cube maps, multitexturing, point sprites, and using texture arrays
Until this point the authors used haven't really talked much about shader programming yet. Most of the examples use simple pre-made shaders that don't really do much. This changes with chapter six titled "Nonstock Shaders" where we get a first glimpse of how to write our own shaders in GLSL, the OpenGL Shading Language. In particular, a fragment shader that uses a simple lighting model to light objects is developed.
After these introductory chapters presenting the basics of OpenGL programming, the next part of the book focuses on more advanced topics, beginning with buffer objects and how to use them to make your OpenGL programs run much more efficiently on modern hardware. Some of the examples presented in this part of the book include using render-to-texture to do reflections, tone mapping, and bloom. This part of the book closes with two fairly long chapters on advanced usage of the shader pipeline, in particular the transform feedback and the geometry shader stages. There is also some discussion on more advanced effects achievable with fragment shaders, in particular applying filters to images, such as a Gaussian blur or a Sobel filter. Finally, rendering geometry efficiently with vertex buffer objects and rendering many objects via geometry instancing is presented.
The final part of the book consists of 4 chapters explaining how to integrate OpenGL with the underlying operating system, in particular with Windows, Mac OS X, and Linux plus various other Unix flavors. The last chapter of this part of the book is about OpenGL ES, which is a version of OpenGL designed to be used especially on embedded system devices, in particular mobile phones and PDAs, to render real-time, interactive 3D graphics.
The book has a lot of images and diagrams throughout, though unfortunately not all of them are in color. There are however 24 color plates of the most interesting images in the middle of the book. The complete source code of the book, and even precompiled binaries for Windows and Mac OS X, can be downloaded from the book's webpage.
If you are new to both 3D graphics programming and OpenGL with a bit of C/C++ programming experience and you are eager to learn how to develop interactive programs with OpenGL, then this book is exactly right for you. The book is written in an easy to understand style without skimming the details (or even more advanced topics). It is the most comprehensive introduction to OpenGL that doesn't require a lot of previous knowledge I have seen to date. The decision to completely drop any discussion of the fixed-function pipeline turned out to be an excellent choice. Finally there is a book that no longer wastes the reader's time with the parts of OpenGL that nobody who does serious graphics development uses and instead presents up-to-date information on how to do 3D graphics on modern graphics hardware.
All in all, the OpenGL SuperBible in its fifth edition succeeds very well in keeping its promise to be the best introduction to OpenGL and 3D graphics programming. Even after you're done working your way through the main parts of the book you will always come back to the handy OpenGL API reference in the appendix of the book.
The review author has been involved in real-time graphics programming for more than 10 years and works as a professional game developer for High Moon Studios in sunny California.
You can purchase OpenGL SuperBible (Fifth Edition) from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Re: (Score:1)
Re: (Score:1)
Do Muslims have to wait for the SuperKoran version?
Imagine (Score:3, Funny)
Just try to imagine, for a moment, my disappointment when I realized this was not an open source 3d rendering of a comic-book version of Jesus SuperChrist.
Re: (Score:1)
I thought I was changing my screensaver today!!!
Proof (Score:2)
Re: (Score:2)
Yes, but you have to apply the proper 3rd party patches (or write them yourself) to religion prior to compilation or you get all kinds of errors.
Re: (Score:1)
Open Source Bible (Score:2)
Funny, when I scanned the article title I though that someone was coming out with a Christian bible produced by open sources. Then I thought about the sheer volume of revisions, flame wars and arbitrary editing meted out over the centuries by transcribing monks, and realized that the Bible is probably the original Wiki (minus the OR, of course).
Re: (Score:1)
Re:OpenGL - do they still have that? (Score:4, Informative)
OP may or may not be intentionally trolling, but the question is pretty easy to answer:
Yes.
Just about every program that does 3D graphics on anything besides MS Windows or XBox uses OpenGL, today.
Re: (Score:2)
Re:OpenGL - do they still have that? (Score:4, Informative)
Are we talking console(OpenGL ES)? Pretty much all of them.
Are we talking PC (OpenGL "proper")? Isn't Valve's Source Engine OpenGL capable now?
Re: (Score:2)
The only "consoles" where people are using OpenGL ES are the smartphones. Nobody is using it on the other real consoles even though some form of it is usually available. Developers generally prefer the proprietary APIs console manufacturers provide, because they are usually lower level than OpenGL so they can get more performance out of them.
Re: (Score:2)
> Are we talking console(OpenGL ES)? Pretty much all of them.
Try again.
XBox 360 - no.
Wii - no. (I wrote an in-house OpenGL implementation using the native GX calls and shipped 2 games that used it.)
DS - no.
PS2 - no. (I fixed a few bugs in the existing in-house OpenGL implementation.)
Re: (Score:3, Interesting)
For graphics quality and capability, there really isn't that much difference between OpenGL and DirectX. They have the same feature set and the same rendering ability. The only difference is that DirectX uses this ridiculous counterintuitive left and rule for polygons. OpenGL uses right hand rule which is the way Engineering and God intended.
Other than that, OpenGL is the only real open standard for graphics. DirectX is only on Windows. OpenGL is on Windows and most other platforms.
Also OpenGL is the
Re: (Score:2)
Re: (Score:2)
Except there is no such thing as a left hand coordinate system. It's just plain WRONG.
Also, according to here [microsoft.com], it says "Direct3D uses a left-handed coordinate system. If you are porting an application that is based on a right-handed coordinate system, you must make two changes to the data passed to Direct3D."
Re: (Score:3, Insightful)
Re:OpenGL - do they still have that? (Score:4, Informative)
Why is this so hard to understand?
There is NO left hand coordinate system in the REAL world. All of physics, engineering, robotics and most graphics use a right hand coordinate system. Obviously you can define a coordinate system to be anything you like, and DirectX has defined theirs to be left handed which is contrary to every other standard out there.
The link does not say it can be either. It says DirectX uses a left hand coordinate system. They then tell you how to use right hand coordinate DATA but fundamentally the internals are still left handed.
Does that explain it for you?
Re: (Score:2)
Re: (Score:2)
That's not what it says. It says if your data is right handed, here is how to read it in. Calculations are still left handed, and the scene is still left handed. So if I take a cross product of x and y vectors, a left handed system has the z going in one direction and a right hand system has it going the other. If I expect to move in my scene based on these calculations, and I'm taking calculations from the scientific world with right hand calculations, the directions can be backwards in the left hand wor
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Maybe I'm not familiar enought with DirectX. I know you can convert right handded to left handed, but how would I set up my DirectX environment such that my world coordinate system has +x to the right of the screen, +y to the top of the screen and +Z towards the camera (right hand)? In DirectX isn't +z always towards the screen regardless of what your data is set up to be?
Re: (Score:1)
Referral Link (Score:1, Insightful)
How about non-Windows and non-Mac? (Score:2)
Does the book cover OpenGL on the iPhone, iPod touch and iPad? How about OpenGL on the Wii or the Nintendo DSi? Or the PS3 or PSP?
I've heard that some of these devices use a subset/smaller specifications of OpenGL, but I guess most of the book should still apply.
Re:How about non-Windows and non-Mac? (Score:4, Informative)
You're thinking of OpenGL ES. Theres a good book for that already.
Re:How about non-Windows and non-Mac? (Score:4, Insightful)
Also, ES like 3.0+ does all everything with vertex arrays and not immediate mode. (Immediate mode is still available in 3.0+, though deprecated, however it was completely removed from ES.) The biggest difference between ES and mainstream OGL is the central role of 16:16 fixed point, which to be honest is not very much different from FP, you just need to pay more attention to expression precision.
Re: (Score:2, Informative)
Fixed point has its limits with precision. It's not a brilliant scheme to be working with when it comes to 3d graphics. Most vendors have realised this, and any mobile GPU from since a few years before the iphone was introduced will have full floating point support, shaders and modern concepts available.
Fixed point is an option in OpenGL ES 1.1 (common-lite version). There is also a better version of OpenGL ES 1.1 which is fully floating point. Then there is OpenGL ES 2.0, which offer full shader support an
Re: (Score:2, Insightful)
Fixed point has its limits with precision. It's not a brilliant scheme to be working with when it comes to 3d graphics. Most vendors have realised this, and any mobile GPU from since a few years before the iphone was introduced will have full floating point support, shaders and modern concepts available.
Actually, floating point has limits to its precision too. A 32-bit floating point number has a 23-digit significand, whereas 16:16 fixed point has a 32-digit significand, so fixed point is 128 times as precise as floating point. The main benefit of fixed point, however, is reliability; unlike floating point, your numbers don't become less accurate as you move away from the origin. The drawback of fixed point is range; unlike floating point, fixed point cannot sacrifice accuracy to allow for larger numbers,
Re: (Score:2)
floating point would been fine near the middle, but have been accurate to only 0.8 meters near the edge
So don't do it that way. Use integer coordinates to reference terrain cells, then floating point to draw within the cell. Avoid subtracting from points that are far away, whether using floating point or integer.
Re: (Score:1)
So don't do it that way. Use integer coordinates to reference terrain cells, then floating point to draw within the cell. Avoid subtracting from points that are far away, whether using floating point or integer.
That will work, and is often precisely what is done in practice. But now by constraining the floating point part to a certain range and adding an integer part what you have effectively accomplished is reinventing fixed point. After spending extra time coding and using twice as much space.
Re: (Score:2)
But now by constraining the floating point part to a certain range and adding an integer part what you have effectively accomplished is reinventing fixed point.
Not at all, you have just been responsible and managed your accuracy properly.
After spending extra time coding and using twice as much space.
You will spend a lot of time getting it right either way. Fixed point does have a perceptible advantage in compactness but not a factor of two, just compare the representations. On the whole, I prefer taking the extra time and working with integers to get the performance advantages, however when it does not matter or when I'm in a hurry I tend to just do the easiest thing which is usually floating point.
Re: (Score:2)
Re: (Score:2, Informative)
Smartphones use OpenGL ES. This is basically a subset of OpenGL. The OpenGL bibles don't usually include specific information on these. They're aimed more at desktop applications.
Re:How about non-Windows and non-Mac? (Score:5, Informative)
I hope all you DirectX programmers take note. Those who wrote for DirectX might have been able to make money on the PC+XBox but the software doesn't move to the PS3, iPhone/iPad, Android, Linux (while still running on Windows too) like OpenGL does. You all fell for Microsoft's deliberate plan to keep you on that platform (where is the Slashdot "it's a trap" tag when you need it, lol). You never know exactly what the future will bring but you do know that devices and operating systems will change. This makes OpenGL the best strategic (long-term) choice for 3D development and the OpenGL SuperBible is a great book to get you there (along with the other OpenGL classics: the 'Red Book', 'Blue Book' and 'Orange Book' - google for these or go to the OpenGL site: http://www.opengl.org./ [www.opengl.org]
Case studies:
The author of X-Plane talks about OpenGL made him $3.5 million in a month since he could port his product to iPhone very easily. He'll make even more money from iPad sales too (my nephew just bought X-Plane for the iPad):
http://techhaze.com/2010/03/interview-with-x-plane-creator-austin-meyer/ [techhaze.com]
Il-2 Sturmovik had both a DirectX and (faster) OpenGL implementation. Coupled with the fact that it is largely written in Java and it was able to be ported to the PS3 as the product Wings-of-Prey greatly increasing sales.
If you must learn a 3D library, then learn OpenGL.It has the features of DirectX 11 (geometry shaders etc) but will run on Windows XP.
Re: (Score:1)
Re: (Score:1)
I hope all you DirectX programmers take note. Those who wrote for DirectX might have been able to make money on the PC+XBox but the software doesn't move to the PS3, iPhone/iPad, Android, Linux (while still running on Windows too) like OpenGL does. You all fell for Microsoft's deliberate plan to keep you on that platform (where is the Slashdot "it's a trap" tag when you need it, lol). You never know exactly what the future will bring but you do know that devices and operating systems will change. This makes
Save some of that for the sequel (Score:2)
In the gaming world, you only care about the game working for its sale period, which is maybe two years at best.
What is the sale period of a game combined with the sale period of its sequels on the same platform?
Re:How about non-Windows and non-Mac? (Score:4, Interesting)
I'm just fed arguing with the "3D means DirectX games on Windows only" crowd. with Apple's ascent it is time for them to eat crow since their point-of-view was as sensible as the web-development "target IE6 only and forget about W3C compat" crowd (which was a battle we had to fight in the enterprise space as many "ohh, shiny" operations people have short-term horizons). This snideness is vindication and not intended to insult the sensitive, so please don't take it personally.
> 2) It's really not that hard to port a DirectX game to PS3 (I won't say OpenGL, since most PS3 games don't use OpenGL.) Dozens of games have already done that, including DirectX-supporting companies like Valve.
Huh? The official graphics API for the PS3 at the lowest level is OpenGL. Of course ports can be done. It simply takes more time (eg. money) if you start with DirectX instead of OpenGL
> 3) In the gaming world, you only care about the game working for its sale period, which is maybe two years at best. Trying to sell game developers on long-term technology are a waste of time.
Nope, you need to look at the whole equation. The tools and experience of the developers really counts. A single game sales might be two years tops but the tech a studio chooses (investing time and developer experience in) has to last a lot longer than that somce they don't like to change their technology often. Changing tech costs significant money and time. This is why the DirectX-only shops will have a period of inefficiency while they retooling for iPad etc). Fortunately many shops use professional frameworks which hide most of the underlying DirectX-ness or OpenGL-ness from the developer, which allows them to target multiple platforms.
All I'm saying is OpenGL is a good tech to investigate that has *lots* of strategic benefits compared to its closest competitor (for those still mezmerized by the now-waning DirectX hype).
Re: (Score:1, Interesting)
I'm just fed arguing with the "3D means DirectX games on Windows only" crowd. with Apple's ascent it is time for them to eat crow since their point-of-view was as sensible as the web-development "target IE6 only and forget about W3C compat" crowd (which was a battle we had to fight in the enterprise space as many "ohh, shiny" operations people have short-term horizons). This snideness is vindication and not intended to insult the sensitive, so please don't take it personally.
I didn't realize that there was
Re: (Score:3, Interesting)
Game Development with OpenGL consumes significantly more time than equivalent development in DirectX
Can you elaborate? I'm curious as to why you would say that. In my experience OpenGL is far easier to understand and write than DirectX.
Re: (Score:2)
OpenGL can be fast for getting something together pretty quick, but then figuring out why it doesn't work the same way on other systems can be very troublesome.
In my experience, I have also seen people who use OpenGL redoing things that DirectX has done fo
Re: (Score:3, Insightful)
This is mostly due to the extra debugging and analysis support that they have in the DirectX SDK.
Not available if you want cross platform. There are a lot of OpenGL debug tools as well.
OpenGL can be fast for getting something together pretty quick, but then figuring out why it doesn't work the same way on other systems can be very troublesome.
Well DirectX has solved this one by not having any other systems. It's Windows or nothing.
In my experience, I have also seen people who use OpenGL redoing things that DirectX has done for you in the past, such as reference counting.
Why should a graphics system handle a programmers reference counting? This gets into your coding strategy. Handle it the same way you handle access to any other shared resource like a memory or device handle.
Re: (Score:2)
In relation to this, systems running the same OS can behave quite differently due to the graphics drivers. Doesn't matter if it's Windows/Linux/OSX.
Re: (Score:2)
OpenGL certified drivers have to pass quality tests. If they do then the image should look the same regardless of what platform you run it on. Not all driver manufacturers do this correctly however. In my experience, ATI has notoriously crappy OpenGL drivers.
Re: (Score:2)
You haven't surveyed most game developers to be able to make such a claim.
Re: (Score:1)
Well, part of the problem goes back to the "standard always a few years out-of-date" aspect, meaning that if you want to use the newest card features, you usually need to have three different code paths:
* The "fallback" to use the older, standard, way for Intel or older cards
* The ATI plug-in version
* The NVidia plug-in version
This is stuff that DirectX will just plain do for you.
Re: (Score:2)
Well, part of the problem goes back to the "standard always a few years out-of-date" aspect, meaning that if you want to use the newest card features, you usually need to have three different code paths
Completely untrue. OpenGL has been updated almost three times since the last DirectX update.
This is stuff that DirectX will just plain do for you.
Not true. The base OpenGL standard has the same features as DirectX. There is no need for extensions to do any advanced features. OpenGL 4 came out in July this year and is fully supported and has everything DirectX can do. (actually the same can be said for OpenGL 3)
The problem with DirectX in the past is every few years they completely change the API without supporting older versions. The requires everyone to d
Re: (Score:2)
It did. This went away years ago. It's the GP that's out of date..
Re: (Score:2)
I do agree with the idea that OpenGL is a much more cleanly designed API, and much nicer to write code for. I think partially though the problem with OpenGL is that sometimes you have to cater to the likes of ATI and nVidia separately for certain extensions that are standard in DirectX whatever the vendor.
There is a bigger reason though in terms of game development in general as to why DirectX lets you get things done quicker- it's much easier writing something that uses most parts of the DirectX range of A
Re: (Score:2)
Thanks for the post. I would say however that since OpenGL 3 released in 2008, the extensions have gone away and have been incorporated into the main OpenGL API. There is no need to use specific ATI or nVidia extensions any more.
Also, if you are on Windows, using OpenGL does not prevent you from using any of the other DirectX libraries such as DirectSound or DirectInput. These are fully compatible with OpenGL. It's just the Direct3D portion that you would not be using. If you want to be truly cross pla
Re: (Score:2)
"Thanks for the post. I would say however that since OpenGL 3 released in 2008, the extensions have gone away and have been incorporated into the main OpenGL API. There is no need to use specific ATI or nVidia extensions any more."
This has historically only been true until the next time OpenGL ends up behind the curve. DirectX just seems to consistently remain ahead in implementing new features directly, even with the process of managing OpenGL development being more streamlined nowadays. Still they are con
Re: (Score:2)
That used to be the case. It is not so anymore with the change to the Khronos group in control. I'm afraid much of your reply uses ou
Re: (Score:2)
There is nothing wrong with DirectX and it's perfectly fine - just that some folks (not necessarily yourself) don't always know some of the advantages of OpenGL (although it is true it has some disadvantages, as I mentioned with input and sound support etc).
There are *lots* of OpenGL debuggers too, both commercial and free (eg. Bugle, glDevil, gDEBu
Re: (Score:2)
In the gaming world, you only care about the game working for its sale period, which is maybe two years at best
That's not really true anymore. First, a lot of games use a third-party engine (or toolkit / middleware). Even if they don't care about the game's code beyond two years, they are not the people making the OpenGL / Direct3D decision; the engine writers are. They tend to reuse their code and incrementally improve it a lot more than game developers so they do care that their code will still be maintainable in a couple of years. On top of that, games now go through a few cycles as ports now. If a game is s
Re: (Score:2)
"I hope all you DirectX programmers take note. Those who wrote for DirectX might have been able to make money on the PC+XBox but the software doesn't move to the PS3, iPhone/iPad, Android, Linux (while still running on Windows too) like OpenGL does. You all fell for Microsoft's deliberate plan to keep you on that platform (where is the Slashdot "it's a trap" tag when you need it, lol)."
No, we're just smart enough to understand the concept of a graphics abstraction layer where it's needed, and mature enough
Re: (Score:2)
> That's still a large potential source of revenue you're cutting out purely for the sake of immature partisan fanboyism.
Personally I don't care what is used so long as it is portable, so I actually agree with your argument. OpenGL is just further along the portability scale than DirectX without costing anything while still working with as many programming languages as possible and it is eas
Re: (Score:2)
"What is this mythic API that works everwhere, including XBox, Windows Phone 7 etc, and how much is it per-seat?"
Really? you think abstraction layers are a kind of API?
"Personally I don't care what is used so long as it is portable, so I actually agree with your argument."
No, I don't think you do. I don't think you actually understand the concept of abstracting away your rendering calls such that the vast majority of your code is actually completely independent of the rendering API such that the only job in
Re: (Score:2)
Re: (Score:2)
I'm not really sure what you're point is, there's still no point going purely down the OpenGL path when you can abstract away the platform specific stuff and keep the option of for example, XBox 360 development open. You still seem to be missing this fundamental point with your incessant insistence that OpenGL is the only thing you should ever use. GLSL is still limited to GL platforms.
OpenGL ES 2.0 isn't supported before Android 2.0, and the iPad, iPhone, and iPhone 3G and older versions of the iPod Touch
Re: (Score:2)
Cross-platform is what matters, as you state, and when Windows and Apple deliberately introduce balkanization that is bad and they ought to be called for it. That is why DirectX is bad, not the tech, but the fact it unnecessarily balkanizes the market. Why I prefer OpenGL to DirectX is that it used to be the *cross platform* libra
Re: (Score:2)
I certainly agree with you, but I can somewhat understand why Microsoft took the path they did. No one else really bothered to do a unified set of game libraries, and we now have OpenAL, and OpenInput but they're not as unified as DirectX. Also, it's only really in the last few years OpenGL has seen serious effort put into it again, it was largely stagnant for the best part of this decade and for that time I can certainly imagine that the DirectX team breathed a sigh of relief that they did have their own 3
Re: (Score:2)
By DirectX 9 things of course are a lot better, but I haven't forgotten the early days even if newer programmers never knew them. DirectX was never so Microsoft could 'innovate', your don't know your IT history if you think i
Re: (Score:2)
I never touched the first two versions, but dealt with 3, and it was fairly okay when it jumped to 5. I was developing still then though all the same, really DirectX came about to try and ween people onto Windows game development and away from DOS development as Microsoft was pretty clear in their will to eventually move away fully from the command line by this point, I don't think there was any real convincing evidence to the contrary, Carmack's early distaste of DirectX always seemed to stem from the fact
3D Bible (Score:2)
How awesome would "the" bible become if it were rewritten by 3D graphics geeks? Every time it's been rewritten over the thousands of years it's been more a story of what the contemporary rewriters believed god told them. And the OpenGL people think god tells them to make computer graphics more open and faster, with superstition and tribal supremacy not really in the script. Lord save me!
Re: (Score:2)
Enjoy!
Re:3D Bible (Score:5, Funny)
1:1 - In the beginning God created the heaven and the earth.
1:2 - And the earth was without form, and void; and darkness was upon the face of the deep. And the Spirit of God moved upon the face of the waters.
1:3 - And God typed,
1:4 - And God went back to the NeHe tutorial, and it was good, but somewhat out-of-date.
Re: (Score:2)
That's the best comment I've seen on /. for a good while. Thanks.
I have to buy another one? (Score:3, Funny)
Re:Bible? WTF (Score:4, Funny)
Re: (Score:2)
Can we stop using religious terms for technological things that are based in facts?
(n) bible (a book regarded as authoritative in its field)
Can we start learning the basic definition of words before we start ignorantly criticizing others for actually knowing what they are talking about?
OpenGL 4.1 is out (Score:2, Informative)
Re: (Score:3, Informative)
OpenGL 3.3 is basically a backport of a bunch of stuff from OpenGL 4.1 that they could make work on DX10 level hardware (OpenGL 4.1 needs DX11 level hardware).
Re: (Score:2)
Sorry, I meant OpenGL 4.0, not 4.1.
This book is for OpenGL 3 - does not work with OSX (Score:5, Informative)
Apple only supports OpenGL 2.1 (plus extensions). The Fifth Edition of the book only covers OpenGL 3. GLSL has changed a great deal since 2.1 and this book is very incompatible with any released version of OS X as of this writing.
If you want to write OpenGL that is compatible with a Mac, get the Fourth Edition of the book.