×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

OpenGL SuperBible 5th ed.

samzenpus posted more than 3 years ago | from the read-all-about-it dept.

Books 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.

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.

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

98 comments

SuperBible (-1)

Anonymous Coward | more than 3 years ago | (#34016060)

I'll wait for the OpenGL Ultimate SuperBible Pro, Extreme Edition.

Re:SuperBible (-1, Troll)

Lead Butthead (321013) | more than 3 years ago | (#34016098)

I'll wait for the OpenGL Ultimate SuperBible Pro, Extreme Edition.

I think I'll wait for the Turbo Platinum edition.

Re:SuperBible (-1, Troll)

Anonymous Coward | more than 3 years ago | (#34016556)

turbo your way to hell

Re:SuperBible (1)

SnarfQuest (469614) | more than 3 years ago | (#34016310)

Do Muslims have to wait for the SuperKoran version?

Re:SuperBible (0)

Anonymous Coward | more than 3 years ago | (#34016442)

Do Muslims have to wait for the SuperKoran version?

http://www.amazon.com/Ultimate-Programming-DirectX-Allen-Sherrod/dp/1584505591

Imagine (3, Funny)

Reilaos (1544173) | more than 3 years ago | (#34016136)

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:Imagine (-1, Troll)

Anonymous Coward | more than 3 years ago | (#34016196)

OpenGL rendered ANAL FETUS

Open Source Bible (1)

Lev13than (581686) | more than 3 years ago | (#34016156)

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).

OpenGL - do they still have that? (0, Troll)

fkx (453233) | more than 3 years ago | (#34016242)

OpenGL - do they still have that?

I thought Flash or Silverlight or HTML5 did away with that sort of bit diddle.

Re:OpenGL - do they still have that? (3, Informative)

Mysteray (713473) | more than 3 years ago | (#34016464)

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:OpenGL - do they still have that? (1)

hairyfeet (841228) | more than 3 years ago | (#34016984)

But seriously, how many AAA rated games come out for OpenGL anymore? Don't get me wrong, I rooted like hell for OpenGL when they fought side by side with Dx in the 90s, as I feared then they'd tie versions of Dx with windows (as they did with Dx10 and Vista) but it is pretty obvious now that the group controlling OpenGL cares more about CAD than actually making a competitor to Dx. And from what I've read the OpenGL ES (as in embedded) used by companies like Sony is just adding their own proprietary extensions so it isn't like it is easy to switch between the PS3 and Windows like Dx and X360, so what is the point?

Back in the 90s OpenGL was gonna be THE layer, and for quite awhile it was, that allowed anyone playing on anything that had OpenGL to play all the cool stuff and have the whiz bang features. Maybe it is time for the FOSS guys to do a LibreOffice and fork it away from the Kronos group and make OpenGL what it was back in the day, THE kick ass graphics layer. Because right now it sure ain't it, and hasn't been it for nearly a decade.

Re:OpenGL - do they still have that? (3, Informative)

nschubach (922175) | more than 3 years ago | (#34017344)

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:OpenGL - do they still have that? (1)

Narishma (822073) | more than 3 years ago | (#34018640)

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:OpenGL - do they still have that? (1)

UnknownSoldier (67820) | more than 3 years ago | (#34020032)

> 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:OpenGL - do they still have that? (2, Interesting)

pnewhook (788591) | more than 3 years ago | (#34017958)

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 only solution if you want to generate your own 3D stereoscopic scenes. DirectX does it for you in the driver but this is just a cheap approximation. If you want accurate, non-eye fatiguing stereo, then OpenGL is the only solution.

Re:OpenGL - do they still have that? (1)

TrancePhreak (576593) | more than 3 years ago | (#34018170)

Actually, unlike OpenGL, DirectX can be left handed or right handed. You get to decide.

Re:OpenGL - do they still have that? (0)

Anonymous Coward | more than 3 years ago | (#34018752)

You must not be familiar with OpenGL. You can easily implement either type of coordinate system using OpenGL. You're in full control of the matrix transforms and the depth buffer test so it's trivial to switch from one system to the other.

Re:OpenGL - do they still have that? (1)

pnewhook (788591) | more than 3 years ago | (#34020036)

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:OpenGL - do they still have that? (2, Insightful)

TrancePhreak (576593) | more than 3 years ago | (#34020460)

So you say there's no left hand coordinate system, then say D3D uses one... Then you post a link that says it can be either.

Re:OpenGL - do they still have that? (3, Informative)

pnewhook (788591) | more than 3 years ago | (#34023122)

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:OpenGL - do they still have that? (1)

TrancePhreak (576593) | more than 3 years ago | (#34025770)

So if you're doing all your calculations in right handed, and it accepts that right handed data... Then what does it matter what it is internally? BTW, some people have tried to figure out what OpenGL becomes internally, and it appears to be LEFT HANDED. It's just the graphics cards work apparently. So I guess you should stop using computers because they are left handed?

Re:OpenGL - do they still have that? (1)

pnewhook (788591) | more than 3 years ago | (#34026960)

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 world of DirectX.

OpenGL is most certainly right handed. Has been this way ever since its inception from IrisGL in the 80's.

Re:OpenGL - do they still have that? (1)

TrancePhreak (576593) | more than 3 years ago | (#34034110)

You don't seem to understand. You can setup your projection and all matrices in D3D to be right handed. All the data/calculations would be right handed. This is further evidenced by all the right handed functions available in DX. (Contrast with GL which only provides right handed functions). However, when submitting to the GPU, everything goes through a transform to left handed. Be it OpenGL or DX. (This is evidenced by the third row of the matrix, negative in GL and in DX when right handed coordinate systems are used).

Re:OpenGL - do they still have that? (1)

pnewhook (788591) | more than 3 years ago | (#34047940)

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:OpenGL - do they still have that? (0)

Anonymous Coward | more than 3 years ago | (#34043682)

I may be wrong, but I'm pretty sure that RenderMan and Luxrender/pbrt are based on left handed coordinate system (at least by default).
But they may not be part of "All of physics, engineering, robotics and most graphics"...

Anyways, OpenGL is an open standard, supported by open platforms and most of closed ones, it's a no-brainer.

Re:OpenGL - do they still have that? (1)

Matheus Villela (784960) | more than 3 years ago | (#34018214)

Starcraft 2, Diablo 3 and the next Blizzard mmorpg will run in opengl too for sure, can't see that changing.

Referral Link (1, Insightful)

Anonymous Coward | more than 3 years ago | (#34016244)

Smooth move getting a referral link on the front page of slashdot.

How about non-Windows and non-Mac? (1)

Yvan256 (722131) | more than 3 years ago | (#34016246)

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? (3, Informative)

WilyCoder (736280) | more than 3 years ago | (#34016276)

You're thinking of OpenGL ES. Theres a good book for that already.

Re:How about non-Windows and non-Mac? (3, Insightful)

Daniel Phillips (238627) | more than 3 years ago | (#34016438)

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:How about non-Windows and non-Mac? (2, Informative)

Anonymous Coward | more than 3 years ago | (#34017052)

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 and has everything you absolutely need to make pretty much anything. The next generation of OpenGL ES coming up next year will be based on OpenGL 3.x, cutting away all the deprecated stuff, the fluff and other useless extensions. But really, OpenGL ES and OpenGL are converging. GLES are adopting features from GL, and GL are deprecating stuff not found in GLES.

Re:How about non-Windows and non-Mac? (2, Insightful)

Barefoot Monkey (1657313) | more than 3 years ago | (#34018938)

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, so the biggest number you can store is slightly less than 32768. That is enough to represent a 320x320 kilometer area with an consistant accuracy of ~1.5 millimeters, which makes fixed point attractive format for data representation. On the other hand, floating point would been fine near the middle, but have been accurate to only 0.8 meters near the edge, and you'd probably end up having to shrink the area to down to 4x4 kilometers to avoid problems.

I agree with you that a device with only floating point and integer support is far superior to one with only fixed and integer, but fixed point is indeed very good to have in 3D graphics for those situations where it is more appropriate.

Re:How about non-Windows and non-Mac? (1)

Daniel Phillips (238627) | more than 3 years ago | (#34019514)

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:How about non-Windows and non-Mac? (1)

Barefoot Monkey (1657313) | more than 3 years ago | (#34022226)

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:How about non-Windows and non-Mac? (1)

Daniel Phillips (238627) | more than 3 years ago | (#34024520)

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:How about non-Windows and non-Mac? (2, Informative)

91degrees (207121) | more than 3 years ago | (#34016394)

Consoles tend to use their own APIs. The one on the PSP has a resemblance to OpenGL but it's quite different. Not sure about the others.

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? (5, Informative)

SplashMyBandit (1543257) | more than 3 years ago | (#34016398)

The last OpenGL SuperBible touched on OpenGL ES (the stuff Android phones, iPod/iPad/iPhone etc). OpenGL ES is a subset of the full OpenGL functionality so this book is a good start to both. You can also get an Addison-Wesley book on OpenGL ES as well but the SuperBible is still worth it for the techniques it teaches (how to best use the API and but stuff together for various effects).

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:How about non-Windows and non-Mac? (0)

Anonymous Coward | more than 3 years ago | (#34016520)

Porting a 'DirectX' app to another platform like PS3 or whatnot isn't all that hard or even time consuming ( a week or two even for a large project ). The hard part is taking advantage of hardware specific features that are available to you on the various devices in an intelligent way, and writing memory managers for the video memory. D3D and OpenGL are more or less glorified memory management APIs (create/lock/fill/release texture|buffer|constants|shaders) with some functions to fill in some structs and eventually invoke the command 'Draw'.

Re:How about non-Windows and non-Mac? (0)

Anonymous Coward | more than 3 years ago | (#34017022)

Porting a 'DirectX' app to another platform like PS3 or whatnot isn't all that hard or even time consuming ( a week or two even for a large project ).

Go tell that to Valve.

Re:How about non-Windows and non-Mac? (1)

Tr3vin (1220548) | more than 3 years ago | (#34017440)

To be fair, they had to deal with OS X's crappy OpenGL implementation. The GP is still a bit of an exaggeration, though.

Re:How about non-Windows and non-Mac? (0)

Anonymous Coward | more than 3 years ago | (#34016624)

PS3 doesn't use OpenGL, or that is no one uses OpenGL on the PS3 as the implementation is terrible, everyone uses libGCM.

Re:How about non-Windows and non-Mac? (1)

Blakey Rat (99501) | more than 3 years ago | (#34016810)

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

1) Don't be so snide.
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.
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.

Save some of that for the sequel (1)

tepples (727027) | more than 3 years ago | (#34017464)

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? (3, Interesting)

SplashMyBandit (1543257) | more than 3 years ago | (#34017468)

> 1) Don't be so snide.

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 ... and you should be thinking about the long-term *money* if you are a half-decent architect.

> 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:How about non-Windows and non-Mac? (1, Interesting)

Blakey Rat (99501) | more than 3 years ago | (#34017672)

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 a "3D means DirectX games on Windows only" crowd. Nor do I really know what that even means...

I understand your general point, but everything you bring up still doesn't necessarily make OpenGL the best choice for game development. Developers should pick the best tool for their task-- if they don't care about porting to consoles or Mac, if they don't care about mobile, if they don't care whether the game runs in 5 years-- DirectX could very well be the best tool for their task. And demonstrably is, for a lot of PC/Xbox games. Otherwise they wouldn't choose it.

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 ... and you should be thinking about the long-term *money* if you are a half-decent architect.

I didn't say the PS3 didn't have OpenGL, or that OpenGL wasn't "official", I said most PS3 games didn't use OpenGL. Which is true; most use LibGCM. OpenGL is mostly there to enable quick porting.

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.

Yes, but on the other hand:
1) Game development with OpenGL consumes significantly more time than equivalent development in DirectX.
2) There are a LOT of DirectX-skilled developers around, which could hugely drive down your staffing costs.
3) Microsoft is doing a very good job, with programs like XNA, of exposing developers to DirectX. OpenGL, in comparison, has very little in the way of community outreach except a few outspoken commenters on Slashdot. :) This helps keep the number of qualified DirectX programmers up.
4) DirectX's new features are driven by a small focused team who ensure that mainstream video cards fully support the features in a reasonable timeframe. OpenGL's new features are the results of a committee that's consistently 3-5 years behind the state-of-the-art, and implemented by OS and video card driver programmers who (and let's be frank) don't do a very good job.

And finally:
5) Your point falls a little flat, since it's really not very difficult to port a game from DirectX to OpenGL if needed. Again, it's been done dozens of times before, and it only (at most) a few months worth of work. You bring this up yourself in your last sentence, which I didn't quote.

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).

Look, if you have two politicians, A and B. A's in the news every day, running TV ads, plastering the city with flyers and posters-- who do you think people are going to vote for? If OpenGL doesn't have an evangelism, it doesn't get any users... that should be self-evident to anybody who's not completely aspie.

Since OpenGL is managed by a slow, bloated committee and not a single party who's interested in growing its marketshare, well, there's no evangelism, and thus there's not as many users. Again, there's no surprise here.

Re:How about non-Windows and non-Mac? (2, Interesting)

pnewhook (788591) | more than 3 years ago | (#34018046)

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:How about non-Windows and non-Mac? (1)

TrancePhreak (576593) | more than 3 years ago | (#34018104)

In most game developer's experience, the opposite is true. This is mostly due to the extra debugging and analysis support that they have in the DirectX SDK. It also come form support from MS, who will assign people to help your company with your project.

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 for you in the past, such as reference counting.

Re:How about non-Windows and non-Mac? (2, Insightful)

pnewhook (788591) | more than 3 years ago | (#34018364)

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:How about non-Windows and non-Mac? (1)

TrancePhreak (576593) | more than 3 years ago | (#34018740)

Well DirectX has solved this one by not having any other systems. It's Windows or nothing.

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:How about non-Windows and non-Mac? (1)

pnewhook (788591) | more than 3 years ago | (#34019952)

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:How about non-Windows and non-Mac? (1)

bonch (38532) | more than 3 years ago | (#34020808)

In most game developer's experience, the opposite is true.

You haven't surveyed most game developers to be able to make such a claim.

Re:How about non-Windows and non-Mac? (1)

Blakey Rat (99501) | more than 3 years ago | (#34018258)

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:How about non-Windows and non-Mac? (1)

pnewhook (788591) | more than 3 years ago | (#34020010)

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 do a complete rewrite. Conversely OpenGL 1 code will still compile with no issues even on a brand new OpenGL 4 system. This is the stability I'm looking for.

Re:How about non-Windows and non-Mac? (0)

Anonymous Coward | more than 3 years ago | (#34020040)

I thought this went away with opengl 3.0+?

Re:How about non-Windows and non-Mac? (1)

Xest (935314) | more than 3 years ago | (#34022330)

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 APIs (DirectSound, DirectInput etc.) and tying it altogether, than it is to use OpenGL and then some disparate set of other external libraries to handle things like Audio and such. The problem is that OpenGL is just a graphics API, and doesn't explicitly integrate as well with the other components required to build a complete game quite like the full set of DirectX components does.

All in all though, for simple to moderate, and even many high end (i.e. where extensions don't come into play much) graphics only tasks, I agree that OpenGL is a much more pleasant and quick to use choice to work with.

Re:How about non-Windows and non-Mac? (1)

pnewhook (788591) | more than 3 years ago | (#34027040)

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 platform, there are OSS equivalents called OpenAudio and OpenInput.

Re:How about non-Windows and non-Mac? (1)

Xest (935314) | more than 3 years ago | (#34028672)

"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 continually improving nowadays, so perhaps you're right, perhaps next time they wont be behind at all.

"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 platform, there are OSS equivalents called OpenAudio and OpenInput."

Of course, but the point is it's just easier when you're sticking to a unified set of libraries. It just makes it that little bit easier that's all but I'm certainly not saying it's a make or break thing, it's fairly trivial.

Re:How about non-Windows and non-Mac? (1)

SplashMyBandit (1543257) | more than 3 years ago | (#34018964)

> 4) DirectX's new features are driven by a small focused team who ensure that mainstream video cards fully support the features in a reasonable timeframe. OpenGL's new features are the results of a committee that's consistently 3-5 years behind the state-of-the-art, and implemented by OS and video card driver programmers who (and let's be frank) don't do a very good job.

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 out of date information.

> 5) Your point falls a little flat, since it's really not very difficult to port a game from DirectX to OpenGL if needed. Again, it's been done dozens of times before, and it only (at most) a few months worth of work. You bring this up yourself in your last sentence, which I didn't quote.

Again, extra cost == fail. If OpenGL didn't work well on Windows then there would be no competition. The truth is that OpenGL works on Windows *as well as* all the up-and-coming platforms. Where DirectX used to have significant advantages was the non-3D parts of an application: DirectInput, DirectSound etc. These are starting to be deprecated in favour of OpenAL etc. so those advantages are disappearing.

I can only lead a horse to water. You can resist the future which is more heterogenous in hardware. However, if you choose your development tools carefully you can be well insulated from this - and save on development costs in the process.

Re:How about non-Windows and non-Mac? (0, Troll)

Blakey Rat (99501) | more than 3 years ago | (#34019078)

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 out of date information.

Fair enough.

The truth is that OpenGL works on Windows *as well as* all the up-and-coming platforms.

I never claimed otherwise. I'm not even sure what you're replying to here...

I did claim that DirectX is significantly easier to develop for, both from the perspective of the hiring manager, and from the perspective of the developers themselves. (You can debug all the way into your shader, line-by-line, for example.)

I can only lead a horse to water. You can resist the future which is more heterogenous in hardware. However, if you choose your development tools carefully you can be well insulated from this - and save on development costs in the process.

Dude, I'm not pissing in your cornflakes. Relax.

I'm just saying that, with all costs considered, for a significant number of developers, DirectX is still the best choice. I don't even see *why* I need to say this, as the pure quantity of DirectX games makes this pretty self-evident.

Here's what I'm not saying:
1) I'm not saying OpenGL is bad
2) I'm not saying DirectX solves every problem with game development ever in history ever
3) I'm not saying you're a jerk

Ok? Relax.

Re:How about non-Windows and non-Mac? (1)

SplashMyBandit (1543257) | more than 3 years ago | (#34019924)

Am relaxed cheers, just trying to avoid confusion with clarification in case some of the readers are less well informed than yourself. Thanks for your posts.

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, gDEBugger, GLIntercept etc). Plus, the GLSL shading language does late compilation from source scripts. These are usually more readible than the equivalent DirectX shader statements (at least, when I have read both).

Cheers.

Re:How about non-Windows and non-Mac? (1)

TheRaven64 (641858) | more than 3 years ago | (#34018234)

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 successful on a console now, it may well be ported to a mobile phone in a few years. That's starting to change: as mobile phones become more powerful, they are increasingly just given the same games with less complex models.

Re:How about non-Windows and non-Mac? (1)

Xest (935314) | more than 3 years ago | (#34022306)

"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 to put childish fanboyism for some particular API aside when it comes to choosing the best tool for the job.

We also therefore get to enjoy the benefit of ensuring the best compatibility and performance for every platform we choose to develop for.

"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."

Yes, it also had an XBox port. Your assertion about the faster OpenGL implementation is irrelevant - this can be due to any number of things, from you simply talking out your arse, through to more time being spent on optimisation of the OpenGL layer, it tells us nothing about the relative rendering speed of each, of which there is really no difference between either, and where one draws ahead of the other depends on very specific tasks which tend to average out across a full blown game and fall into irrelevance compared to other processing tasks like preparing the data in the first place. The only thing we can really take away from this is that the developers of IL2-Sturmovik were smart enough to do as I mentioned, and use an abstraction layer, allowing them to port to every suitable platform, not just the DirectX subset, or the OpenGL subset. Guess what? professional developers get this, even if you do not.

"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."

But not the XBox, or Windows Phone 7, or probably any Microsoft platform outside the desktop. That's still a large potential source of revenue you're cutting out purely for the sake of immature partisan fanboyism. As with everything, use the right tool for the job. Sometimes, that is OpenGL, sometimes it is not OpenGL.

Believe it or not, some people are interested in just getting the job done, achieving the best sales possible, and ensuring best reusability of their code whatever the future holds. Tying yourself purely to OpenGL, and only OpenGL, does not achieve any of these goals to the fullest extent possible.

The point is why limit yourself to just OpenGL or just DirectX in the first place when you can, for a trivial amount of extra work, write code that is vastly more future proof in that you could trivially implement support for some as yet unimagined API even, and enjoy the best of all worlds?

Re:How about non-Windows and non-Mac? (1)

SplashMyBandit (1543257) | more than 3 years ago | (#34022396)

What is this mythic API that works everwhere, including XBox, Windows Phone 7 etc, and how much is it per-seat?

> 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 easier to suggest that DirectX-ers should try OpenGL than to suggest they try some unnamed niche library.

> The point is why limit yourself to just OpenGL or just DirectX in the first place when you can, for a trivial amount of extra work, write code that is vastly more future proof in that you could trivially implement support for some as yet unimagined API even, and enjoy the best of all worlds?

You can add arbitrary layers of abstraction. Sometimes you can't afford the luxury of extra layers. Hell, I am just finishing a project where the internal synchronization within the Java Date class to get a TimeZone is too expensive for an Internet-scale application. In such case small changes in performance mean big dollars when scaled up. Graphics apps are similar. You want some abstraction but not too much.

ps. Who is worrying about targeting Windows Phone 7? Don't put your life savings on that horse.

Re:How about non-Windows and non-Mac? (1)

Xest (935314) | more than 3 years ago | (#34022694)

"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 terms of portability is to create implementations for those abstraction layers that support the platform specific APIs. I get this impression because you're still talking about specific libraries, rather than demonstrating an understanding of the fact that good code means it's irrelevant what API you use because switching between them is a quick and easy task.

"OpenGL is just further along the portability scale than DirectX"

Really, it's not. You use OpenGL on the PC sure, but then you have to deal with platform specific implementation differences with Nintendo and Sony's platforms. You have to use ES for mobile devices, and even then you run into larger problems with hardware differences due to OpenGL often having cutting edge features implemented as vendor specific extensions whilst DirectX often has them implemented equally. You can't simply write an OpenGL app and have it compile on the Wii, the PS3, the PC, and each of the smartphone platforms without having to do a fair bit of work. It's certainly not as portable as you seem to be implying. This is just something that developers deal with though, and again, abstraction is the key tool here.

"and it is easier to suggest that DirectX-ers should try OpenGL than to suggest they try some unnamed niche library."

What niche library are you referring to? Are you still referring to your misconception that an abstraction layer is some kind of library? Why suggest anything at all? If people are developing for DirectX they probably know the existence of OpenGL, they probably either simply do not care about moving away from their current platform, of they're competent enough, like the Il2-Sturmovik guys you mentioned, to abstract away their graphics layer and offer a rendering path for DirectX and OpenGL to maximise the platforms they support with ease. You sound like the guys at the Wolfire blog who came up with the ludicrously childish and paranoid conspiracy theory that people use DirectX because of Microsoft's marketing, when in fact they often just use it because it's the best solution for the task they have at hand.

"You can add arbitrary layers of abstraction. Sometimes you can't afford the luxury of extra layers."

Bollocks. Sorry, but if you're trying to suggest you can't abstract away your graphics layer because of performance then you have to be a really sucky programmer. Even id Software have used abstraction frequently through the years to offer DirectX and OpenGL rendering paths and their stuff has always been right on the cutting edge of performance pushing hardware to it's limits whilst also providing the best graphical experience of the time- this is real world demonstrable high performance rendering that proves that abstraction layers are not a problematic performance hindrance. It would seem that if you truly believe abstraction layers like this are too much of a performance hit then you have little to no actual experience of developing high performance rendering apps and seeing what sort of things really do slow your app down and hence need optimising, these sorts of things are not your abstraction layers (well, unless you've done something truly braindead).

"ps. Who is worrying about targeting Windows Phone 7? Don't put your life savings on that horse."

I wouldn't, but are you suggesting that if it does get even a reasonable share of the smartphone market in the long run, say even as low as 5%, then it's not worth targetting had you engineered your code properly to make porting there a trivial task? That's still millions of potential customers for very little work if you do things right the first time round which means not explicitly hardcoding to be OpenGL only. The point is you don't have to worry about being able to, or not able to support new platforms because if you've written your code right and some new platform does turn out to be succesful then it doesn't take much real effort to port to it regardless.

Only 5 years, or really even 4 years ago, most people would've laughed at you if you'd have said the companies with the greatest long term potential to influence the mobile operating space would be Apple and Google via their own home grown operating systems, that touch would be the dominant input method, and Nokia and RIM - the two largest smartphone players - would be seeing themselves losing marketshare at a quite rapid rate to these two. With that in mind, pretending that it's not worth considering that a new challenger to the marketplace is not worth paying attention to, or planning for as a potential worthwhile target platform a few years down the road is rather stupid and shortsighted. You always have to consider these sorts of eventualities, and most importantly, as a software developer, your code should too, through abstracting away as much platform specific stuff as possible, wherever possible.

Re:How about non-Windows and non-Mac? (1)

SplashMyBandit (1543257) | more than 3 years ago | (#34026738)

Have you developed a 3D app lately? You keep talking about 'code' when in fact most of the work is writing in a shader language so it sounds like you actually haven't for a while. Cg is abstract and platform independent and is as you suggest but so is GLSL. The platform-specific code part is a far less significant part of the application and really is only there to support getting the shaders going and managing buffers. Not like the old days at all.

Re:How about non-Windows and non-Mac? (1)

Xest (935314) | more than 3 years ago | (#34029928)

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 which limits you to the FFP for these platforms. Similarly PSGL is a kind of half way house between ES 1.1 and 2.0 in that it better supports the programmable pipeline. I'll admit I know fuck all about development for Nintendo's platforms, but as I understand it they don't use plain OpenGL either and use a more dated OpenGL ES based paradigm (i.e. fixed function).

I'm all for OpenGL, but as I said originally, in the right place, at the right time. I know why you disagree with me, it's fairly poorly veiled- you don't like Microsoft, which is fine. My point is merely that dressing up what effectively boils down to an anti-Microsoft argument as a cross platform argument, when GL isn't that brilliant cross platform, is wrong. You know, I don't even disagree with you on a lot of things, I still think OpenGL is a much cleaner API than Direct3D, I too am a big fan of Java, and was quite amused by this post of yours when I read it yesterday in a different discussion:

http://slashdot.org/comments.pl?sid=1835964&cid=33997836 [slashdot.org]

I'm just not keen on being too overly anti-Microsoft myself, because as with that discussion, and as with many of Steve's decisions on his platforms over the last few years, as with Google's countless invasions of privacy, and with, despite the communities claims to the contrary, Linux's inability to provide a stable desktop experience due to second rate drivers and lack of user targetted development (as opposed to developer targetted development) I'm not sure the alternatives are really any better. I'm also not really into predicting the future of the market because things change so rapidly, this is why I firmly believe in keeping code truly neutral as far as possible- I hope you can at least respect where I'm coming from even if you disagree.

Re:How about non-Windows and non-Mac? (1)

SplashMyBandit (1543257) | more than 3 years ago | (#34030250)

Windows 7 is pretty darn good (I've paid, yes paid, for several personal copies) - although I use a lot of everything (various flavours of Windows, Mac, Linux, Android, Solaris).

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* library you mention. Sure there are other library that add even more abstraction to OpenGL, and they make sense if you can accept lower performance. When Microsoft introduces true cross platform technologies that work elsewhere as well (or almost as well) on other platforms then I have no problem with it (provided there are also independent implementations - no point getting shafted due to company politics).

Apart from context setup OpenGL used to run everywhere until those companies deliberatly introduced incompatibility. if OpenGL didn't run on Windows then I would be against it, the fact is that it runs almost everywhere including Windows and Apples, the XBox and older phones are the principal exceptions.

Re:How about non-Windows and non-Mac? (1)

Xest (935314) | more than 3 years ago | (#34035206)

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 3D API to work on without the hindrance of politics surrounding OpenGL over the last decade.

It's a common problem with FOSS, it's great in theory but all too often a combination of politics and self-interest derail it. It's a large reason I believe Linux has not made it to the desktop on a larger scale than it has- because too many developers are only interested in solving their problem, without a thought of how well their solution will work for the average joe. It takes a lot of discipline to ensure things work well for the user and there are examples of FOSS where this discipline has been enforced to great success- Firefox is of course perhaps the most obvious example.

So yeah I agree it's annoying DirectX doesn't just work everywhere, but as above, I can also understand Microsoft's motivations, and think OpenGL itself deserves a fair share of the blame in letting Microsoft steam ahead in the first place- there's no reason OpenGL couldn't be defining the graphics marketplace nowadays rather than DirectX had it not stagnated for such a long period. I too would like one graphics API (or better, one full blown multimedia API!) to rule them all, but at the end of the day we do have fragmentation, and as with fragmentation on Android sure it exists, but it's trivially dealt with via sensible abstraction and programming practices so I figure until the day comes where we do have a grand unified multimedia API then you might as well abstract what you can and just not care too much about what you use to fill in the underlying implementations of those layers.

Re:How about non-Windows and non-Mac? (1)

SplashMyBandit (1543257) | more than 3 years ago | (#34035522)

I programmed DirectX in it's first iterations and it was truly awful. DirectPlay for example had a static limit of 20 connections that were not refreshed, causing no end of problems [stale connections, crashes]. Did you have direct experience programming the first verisons of DirectX?

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 it was, it was a deliberate ploy to balkanize the market. DirectX was patently inferior technology than the Farenheit it meant to replace and the networking effect of Windows was used to promote it. That's why John Carmack etc reviled DirectX, simply because at that time it was so poor. Surely you remember if you were developing to it at the time?

Later, DirectX overtook the sclerotic OpenGL and with rapid advancement, a lot of marketing and the seemingly inexorable advance of Windows it made sense to use DirectX and forget anything else. This seems to be where you formed your personal opinion of things.

However time has since advanced and the pendulum has now swung again in favour of multiple platforms and starting with DirectX is the wrong choice for these times. Either a wrapper library *or* OpenGl is the place to start these days. This requires you to be courageous enough to ditch platforms deliberately locked out by the vendor - as I am for my own software product, which needs decent performance so I choose OpenGL over extra inefficient abstraction. This is guaranteed to disappoint the development purist who seeks *extra* layers of abstraction (even if abstraction is already present) in the false believe that if a little abstraction is good than even more must be better. In my 20 years of development I've come to realize that too much abstraction is nearly as bad as too little - this is a hardened view from the trenches, not what some university wonk got a speaking tour and book gig on.

Re:How about non-Windows and non-Mac? (1)

Xest (935314) | more than 3 years ago | (#34035724)

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 it was initially rather crap (which is also why I never bothered with it at first), rather than Microsoft's motivations- they didn't completely shun DirectX, just Direct3D IIRC as I'm pretty sure Quake II's software renderer was written using DirectDraw.

I would however say XNA is more of a problem in the respect you state, because it means you not only lose the ability to simply abstract away library specific stuff, but you're dealing with a completely different platform - you're having to develop for C# and .NET (which is no bad thing in itself as I like C# and .NET) but it's a problem in that it means if you write an XNA game then you really are struggling to get it onto other platforms without a much larger rewrite than if you could just use C++ and DirectX with an abstraction layer for graphics. It's probably this you should be concerned about more than anything because by and large, most AAA developers nowadays are quite content working with both OpenGL style calls (or a close relative of) on the Playstation and Wii, and DirectX on the 360. If Microsoft decided to go fully or at least much more heavily down the managed route next console iteration then you might well find less will to port to say the Playstation than there was this time round and vice versa- that really would be a bad thing IMO.

I still disagree with you on abstraction, you seem to be talking about extremes- too much or too little, when there is simply put, just the right amount of abstraction to ensure your game isn't dependent on any particular multimedia API, and again, as demonstrated through the years with various engines that do just this, it need not cause a measurable performance hit. From Quake through to modern cross platform games like Assassins Creed 2 that push the graphics capabilities of the systems they run on there's no problem with performance doing it this way. Some engines (Source included I think?) even offer DX9 and DX10 paths which is a real demonstration of how a well architected engine really can be neutral to the rendering technology without performing poorly. You also mention the use of wrappers, and a wrapper really is just an abstraction layer albeit generally a sloppy one in that it'll tend to follow an existing specific API's naming standards rather than provide a more generic and neutral interface, but it will tend to do the trick all the same. I guess we'll just have to agree to disagree on this.

Re:How about non-Windows and non-Mac? (0)

Anonymous Coward | more than 3 years ago | (#34034864)

Did you bother to RTFA? There is coverage of OpenGL ES at the end, after describing modern OpenGL in general.

deception # 1 US 'export', murder/mayhem 2nd (-1, Offtopic)

Anonymous Coward | more than 3 years ago | (#34016304)

bible? another 'work' of fiction? did we forget surveillance (of ourselves)? we must be in the top 10 there by now? december is rat out your neighbor month this year. next year, all year.

the corepirate nazi freemason holycost (life, liberty etc...) is increasing by the minute. you call this 'weather'?

continue to add immeasurable amounts of MISinformation (lies), rhetoric & fluff, & there you have IT? that's US? thou shalt not... oh forget it. fake weather (censored?), fake money, fake god(s), what's next? fake ?aliens? ahhaha. seeing as (we have been told that) we came from monkeys, the only possible clue we would have to anything being out of order, we would get from the weather. that, & all the other monkeys tipping over/exploding/looking afraid around US.

the search continues; on any search engine, mix & match for even more connections.

weather+manipulation

bush+cheney+wolfowitz+rumsfeld+wmd+oil+freemason+blair+obama+weather+authors

meanwhile (as it may take a while longer to finish wrecking this place); the corepirate nazi illuminati (remember, (we have been told) we came from monkeys, & 'they' believe they DIDN'T), continues to demand that we learn to live on less/nothing while they continue to consume/waste/destroy immeasurable amounts of stuff/life, & feast on nubile virgins while worshipping themselves (& evile in general (baal to be exact)). they're always hunting that patch of red on almost everyones' neck. if they cannot find yours (greed, fear ego etc...) then you can go starve. that's their (slippery/slimy) 'platform' now. see also: http://en.wikipedia.org/wiki/Antisocial_personality_disorder

never a better time to consult with/trust in our creators. the lights are coming up rapidly all over now. see you there?

greed, fear & ego (in any order) are unprecedented evile's primary weapons. those, along with deception & coercion, helps most of us remain (unwittingly?) dependent on its' life0cidal hired goons' agenda. most of our dwindling resources are being squandered on the 'wars', & continuation of the billionerrors stock markup FraUD/pyramid schemes. nobody ever mentions the real long term costs of those debacles in both life & any notion of prosperity for us, or our children. not to mention the abuse of the consciences of those of us who still have one, & the terminal damage to our atmosphere/planet (see also: manufactured 'weather', hot etc...). see you on the other side of it? the lights are coming up all over now. the fairytail is winding down now. let your conscience be your guide. you can be more helpful than you might have imagined. we now have some choices. meanwhile; don't forget to get a little more oxygen on your brain, & look up in the sky from time to time, starting early in the day. there's lots going on up there.

"The current rate of extinction is around 10 to 100 times the usual background level, and has been elevated above the background level since the Pleistocene. The current extinction rate is more rapid than in any other extinction event in earth history, and 50% of species could be extinct by the end of this century. While the role of humans is unclear in the longer-term extinction pattern, it is clear that factors such as deforestation, habitat destruction, hunting, the introduction of non-native species, pollution and climate change have reduced biodiversity profoundly.' (wiki)

"I think the bottom line is, what kind of a world do you want to leave for your children," Andrew Smith, a professor in the Arizona State University School of Life Sciences, said in a telephone interview. "How impoverished we would be if we lost 25 percent of the world's mammals," said Smith, one of more than 100 co-authors of the report. "Within our lifetime hundreds of species could be lost as a result of our own actions, a frightening sign of what is happening to the ecosystems where they live," added Julia Marton-Lefevre, IUCN director general. "We must now set clear targets for the future to reverse this trend to ensure that our enduring legacy is not to wipe out many of our closest relatives."--

"The wealth of the universe is for me. Every thing is explicable and practical for me .... I am defeated all the time; yet to victory I am born." --emerson

no need to confuse 'religion' with being a spiritual being. our soul purpose here is to care for one another. failing that, we're simply passing through (excess baggage) being distracted/consumed by the guaranteed to fail illusionary trappings of man'kind'. & recently (about 10,000 years ago) it was determined that hoarding & excess by a few, resulted in negative consequences for all.

consult with/trust in your creators. providing more than enough of everything for everyone (without any distracting/spiritdead personal gain motives), whilst badtolling unprecedented evile, using an unlimited supply of newclear power, since/until forever. see you there?

all the manuals say we're not to kill each other, & we're mandated to care for/about one another, before any other notion will succeed. one does not need to agree whois 'in charge' to grasp the possibility that there may be some assistance available to us, including from each other. there's also the question of frequent extreme 'distractions' preventing us from following the simple 'directions' we were given, along with everything we needed to accomplish our task. see you there?
boeing, boeing, gone.

3D Bible (1)

Doc Ruby (173196) | more than 3 years ago | (#34016696)

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:3D Bible (5, Funny)

Anonymous Coward | more than 3 years ago | (#34018128)

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,

glEnable(GL_LIGHTING);

...but there was no light, for GL_LIGHTING is deprecated in OpenGL 3.0, and even in 2.0 there's like five other settings that He would have had to enable to get anything to display.

1:4 - And God went back to the NeHe tutorial, and it was good, but somewhat out-of-date.

Bible? WTF (0)

Anonymous Coward | more than 3 years ago | (#34017292)

Can we stop using religious terms for technological things that are based in facts?

What's next? The DirectX SuperTanakh?

Re:Bible? WTF (3, Funny)

e4g4 (533831) | more than 3 years ago | (#34018666)

But "bible" is a completely appropriate term in this case. It tells you a great many details about something that was completely fabricated by humans.

Re:Bible? WTF (1)

GooberToo (74388) | more than 3 years ago | (#34024314)

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 is dead. (0)

Anonymous Coward | more than 3 years ago | (#34017576)

Hasn't netcraft confirmed it?

Re:OpenGL is dead. (0)

Anonymous Coward | more than 3 years ago | (#34068474)

Well, that post was as ignorant as they get.

OpenGL 4.1 is out (2, Informative)

neuro88 (674248) | more than 3 years ago | (#34018202)

This looks like a good book, but it covers OpenGL 3.3. Can someone provide a high-level overview of the differences between OpenGL 3.3 and 4.1?

Re:OpenGL 4.1 is out (2, Informative)

Narishma (822073) | more than 3 years ago | (#34018726)

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:OpenGL 4.1 is out (0)

Anonymous Coward | more than 3 years ago | (#34022570)

The most important change is tesselation.
DX11 and GL4 GPUs (like NVIDIA Fermi, etc.) have special hardware that speeds up generation of new triangles. This allows for interesting effects, like more realistic waves on the water, more detailed personas, etc.

bitI)ch (-1, Troll)

Anonymous Coward | more than 3 years ago | (#34020230)

has steadily See. The number 5ay I'm packing Share. FreeBSD is

This book is for OpenGL 3 - does not work with OSX (4, Informative)

Sludge (1234) | more than 3 years ago | (#34021260)

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.

Who needs 3? (0)

Anonymous Coward | more than 3 years ago | (#34036544)

Well I do serious graphics programming and I used the fixed functionality pipeline, i.e. CAE work. After all who needs later than OpenGL 1.1?

Must admit it would be nice to rip out the graphics and drop in a scenegraph, add in a Gooch shader and the product might even start to look a bit flash.

Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...