Slashdot Mirror

Sir, this is complete, utter bullshit.

DirectX gets almost nothing “much earlier”, because it has no extension mechanism. With DirectX you are stuck with the latest version. It has obvious advantages, but early features are certainly not amongst them. Think what you want about the ARB, it does release and releases often.

As for the documentation being terrible and vague, that's pretty uninformed, too. Every extension is fully documented and the vendors know precisely what needs to be implemented. There is no Direct3D equivalent of the 600-page OpenGL specification. The DirectX documentation is a programmer’s guide, not a specification. Every single version of the GLSL standard comes with a full grammar of the language which lets you reimplement a parser or compiler. There is no such thing as a grammar for HLSL (the D3D equivalent). What Microsoft calls a “grammar” for HLSL can be found here and anyone not even in the field of graphics programming will immediately understand how much of a joke it is compared to this (pages 166 to 174).

(Source: I work on Windows, Linux, PS3, Xbox and mobile game engines)

Sir, this is complete, utter bullshit.

DirectX gets almost nothing “much earlier”, because it has no extension mechanism. With DirectX you are stuck with the latest version. It has obvious advantages, but early features are certainly not amongst them. Think what you want about the ARB, it does release and releases often.

As for the documentation being terrible and vague, that's pretty uninformed, too. Every extension is fully documented and the vendors know precisely what needs to be implemented. There is no Direct3D equivalent of the 600-page OpenGL specification. The DirectX documentation is a programmer’s guide, not a specification. Every single version of the GLSL standard comes with a full grammar of the language which lets you reimplement a parser or compiler. There is no such thing as a grammar for HLSL (the D3D equivalent). What Microsoft calls a “grammar” for HLSL can be found here and anyone not even in the field of graphics programming will immediately understand how much of a joke it is compared to this (pages 166 to 174).

(Source: I work on Windows, Linux, PS3, Xbox and mobile game engines)

Create Open3D so that all makers are in.

They already have that. It is called OpenGL

They did that already. As of OpenGL 3.1 the only non-deprecated rendering method is Vertex Buffer Objects. Link.

There are a lot of things OpenGL could do to make itself more accessible - better-supported crossplatform utility libraries, three or four shortcut commands that set the various glEnable() states that 95% of new developers actually care about, streamlining eyebrow-raising pile of mipmap generation options, the entire process of setting up a vertex buffer object could be MASSIVELY simplified...

Honestly, what OpenGL needs isn't fewer features, but rather for the features most people want to use to be placed front and center with extremely simple, well-documented data formatting rules and optimized, efficient helper functions. Microsoft might have been Slashdot's Great Satan for a long time, but they do listen to the sort of developers they're hungry for, and DirectX is one of the better examples of that.

http://www.opengl.org/documentation/current_version/

Graphics cards are now sold with OpenGL 4.0 support. It's not stuck at 2.0, like you're suggesting with Direct3D 9.

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

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/

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.

Most of the tutorials are outdated and won't work in modern OpenGL core profile. Avoid tutorials that use glBegin(), glVertex(), glLight(), gluPerspective(), glMatrixMode(), glVertexPointer(), or learn just enough from them that you can create a context and draw stuff in Linux. After that you can adapt Windows-specific tutorials's code to Linux. I liked these tutorials:
http://sites.google.com/site/opengltutorialsbyaks/introduction-to-opengl-3-2---tutorial-01
http://www.opengl.org/wiki/Tutorial:_OpenGL_3.1_The_First_Triangle_(C%2B%2B/Win)

And Thirded. GLUT / freeGLUT is simply the easiest way to get an OpenGL application running without having to create the window, the opengl context, etc. GLUT library documentation is: http://www.opengl.org/documentation/specs/glut/spec3/node1.html

Seconded. GLUT is probably the easiest way to get started. If you go to the GLUT page you'll also find a list of OSS alternatives to GLUT (GLUT is free but closed-source) if you'd prefer to use one of those. Although this tutorial makes a reference in the beginning to some MSVC-specific pragmas to set linker options, it's probably pretty good for your purposes on the whole. Finally, there are other forums more specifically geared towards the things you're interested in; e.g. gamedev.net.

It might be primitive, but using GLUT is always an option. Its cross platform and usually the examples run on all platforms without modification. http://www.opengl.org/resources/libraries/glut/

My computer has a opengl32.dll, and it has a Microsoft copyright. However, it does require the graphics card manufacturer to provide a driver for their card. I don't know which graphics card would not come with one these days. Have a look at Windows Vista and OpenGL - the facts.

You need to find an SDK for the language you want to use opengl.org should be a good starting point. That and you're graphics card needs to support the version you want to develop for.

Bet you're not a game developer, are you?

You're the one full of shit clinging to decade old quotes. Carmack himself later said DirectX is better nowadays. Maybe the notion of some things getting better and the other things degrading is foreign to you. Anyway, read this and the comments http://braid-game.com/news/?p=364

http://developers.slashdot.org/article.pl?sid=08/08/11/2135259

http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=243195&Main=45784#Post243195

Stop sitting on your couch and spouting off things that game developers should do, they have their own constraints.

From the Amazon link, I found several reviews giving the book a thrashing for continuing to include deprecated APIs and not teaching the new paradigms of the APIs after OpenGL 3.0. One review was upset with the regurgitation and lack of new material. Another reviewer was looking for a book that concisely covers OpenGL 3.1 and the new way of coding things since 3.0 instead of the backwards compatible context and forward compatible context intricacies.

I was thinking of picking up a good OpenGL book but this one sounds like it'd be most useful to people who need to move old projects forward and have to deal with old APIs and transitioning the graphics up to 3.0. But if you're coding from scratch and want the latest OpenGL, this book might have a lot of material you shouldn't even pay attention to because it's deprecated. I guess for hobbyist meddling I'll stick to the wiki as it's a difficult task for people to write documentation books on a changing spec. Probably a good one stop shop for all versions of OpenGL but I think sometimes the spec implementers just want you to move forward and aim to ask you to do that as infrequently as possible. I guess 3.0 appears to have addressed that.

From the Amazon link, I found several reviews giving the book a thrashing for continuing to include deprecated APIs and not teaching the new paradigms of the APIs after OpenGL 3.0. One review was upset with the regurgitation and lack of new material. Another reviewer was looking for a book that concisely covers OpenGL 3.1 and the new way of coding things since 3.0 instead of the backwards compatible context and forward compatible context intricacies.

I was thinking of picking up a good OpenGL book but this one sounds like it'd be most useful to people who need to move old projects forward and have to deal with old APIs and transitioning the graphics up to 3.0. But if you're coding from scratch and want the latest OpenGL, this book might have a lot of material you shouldn't even pay attention to because it's deprecated. I guess for hobbyist meddling I'll stick to the wiki as it's a difficult task for people to write documentation books on a changing spec. Probably a good one stop shop for all versions of OpenGL but I think sometimes the spec implementers just want you to move forward and aim to ask you to do that as infrequently as possible. I guess 3.0 appears to have addressed that.

What I see in this video is "just" a state of the art game engine renderer. The current generation of games only expoits a subset of the features of current generation hardware. Were it not for the strict realtime requirements that are present in games, which push the available CPU time for rendering in the range of 3 to 6ms for 60FPS (the rest of the time is taken up by other parts of the game), the visuals could be immensely more impressive. And none of that is something that can be done in DirectX exclusively.

Hardware tesselation is demoed in the video you mentioned, but this is only available on highest end ATI hardware at the moment and AMD published extension specifications for that as early as March 2009 (see for example http://www.opengl.org/registry/specs/AMD/vertex_shader_tessellator.txt)! When did Windows 7 hit the market? October?

Then Microsoft decided they'd cancel support for OpenGL in Vista/Win7

Really? Then why do software programs that use OpenGL work on my Vista and Windows 7 machines? Here's why, you uneducated troll.

I'm surprised this misunderstanding holds 3 years after the fact.

With Vista, Microsoft intended to improve OpenGL support when you don't have an ICD installed. Somehow, this was miscommunicated and we thought Microsoft was going to drop OpenGL support from Vista.

To clear up the confusion, Vista provides 3 ways to use OpenGL compared to 2 ways on XP:
1. Microsoft's GDI renderer (1.1)
2. ICDs (1.1 - 3.0, depending on the driver and hardware).
3. Microsoft's DirectX wrapper (1.4, Vista only)

1 and 3 have always been available. 2 was added on Vista and will probably stay as is on Windows 7.

OpenGL 3.0 support is the responsibility of IHVs, not Microsoft.

Source

Heh... Normally, I'd just tell you google for "opengl api documentation" but I'll just be nice and hand you the first link from the aforementioned search...

Why don't you look here, hm?

At this page, there's an amazing array of documents, including the specification (which explains what's going on underneath the hood amongst other things...), API references for 2.1, 3.0, the OGL Shader Language, and other things.

Windows Vista fully supports hardware accelerated OpenGL.

You're completely delusional right? http://www.opengl.org/sdk/docs/man/

Fail, fail: First of all, plug and play is a standard feature of PCI, and NT4 couldn't support PCI to the extent that it does without it. Second of all, there is a secret but easy way to enable ISA PnP in NT4.

NT4 is a gigantic piece of shit, and so is DirectX; Direct3D is an abortion which would never have happened if those assholes at 3DFX had gone with MiniGL from the get-go instead of going the egotistical route, and allowing their collective hubris to cause them to create a wholly new 3D API, something which was totally unneeded as well as undesirable at the time... or ever. OpenGL's slow pace was not a problem even then, as the full functionality of the 3DFX chip had analogues in OpenGL, including their much-lauded multitexturing support, in the form of SGIS_MULTITEXTURE — now an integral part of the standard as ARB_multitexture, but even then perfectly usable under its original, vendor-specific (and -derived) name.

The biggest irony here is that you could, for obscene amounts of money, acquire 3D accelerators which operated under NT 3.51, especially including examples from 3D Labs. Most of the changes from NT 3.51 to NT 4 could have been made without making the single largest change, which was the merge of the Kernel and GDI memory spaces to improve graphics performance. But had the graphics accelerator revolution arrived sooner, that might never have even happened. Meanwhile, NT4's facelift could be faked trivially enough by appropriating the shell and required, upgraded DLLs from Windows 95 and slapping them onto NT 3.51. 3.51's biggest problem is its limited addressing, which prevents the use of filesystems larger than 2 gigabytes (among other problems.) In fact, NT 3.51 only has 4GB of virtual memory. But there seems no reason why these failings could not have been corrected without merging memory spaces that caused NT4 to be substantially less reliable than NT 3.51.

In any case, curse you, Microsoft!, and a special shout-out to 3DFX: fuck you!

Fedora was constantly broken, sound broken since f11, other misc breakages once in 1-3 months.

Vista is very stable, one update caused infinite reboot, also found some rendering bugs.

Ubuntu is the best, the worst problem in years was it forgot static IP during upgrade

Snow Leopard seems poorly tested, bundled app from Apple crashes, some settings don't work (still very short experience)

It's just my experience, using all systems for the same tasks, development of Lightsmark. The message is clear: ditch Fedora, get Ubuntu.

DirectX is good for games on the PC and XBox360. OpenGL is good for games (eg. IL2) and engineering on the PC, PS3, iPhone/iTouch, cellphones, military avionics, professional movie rendering, scientific visualization, Solaris/Unix etc. The only platform you can't develop for using OpenGL is the Xbox (less than 1% of computable devices out there), with OpenGL you can use it almost everywhere else (including using software rendering with Mesa on headless platforms). Also, OpenGL changes more slowly than DirectX (which game developer's hate but the rest of us quite like stability and protection of our investment in our existing code - it is too expensive for larger pieces of software to keep getting re-written unlike games which are maintained for a couple of years at most). Your call which way you'd like your career to head.

Unlike an earlier poster I would not suggest learning graphics algorithms first (I guess that person was a computer scientist, this is the kind of thing they recommend). It is like saying you ought to learn assembly language rather than learning how to make shippable programs in something more widely (commerically) used like Java. I would suggest learning OpenGL using something free and easy to start with like the JoGL plugin for Netbeans (syntax highlights GLSL shader language). If you really do have a passion for graphics after you've learned OpenGL then I would say learning the underlying algorithms is an excellent idea and will make you a better graphics developer. But IMHO it is worth learning to be basically productive before trying to learn at an expert level.

However, I haven't found such issues with mathematicians, artists or musicians, that provided helpful advice in a much more friendly way, even discussion and tips, linking to user-friendly references that were easy to understand and straight to the point, without the wide load of "TV character" sarcasm provided by developers or extremely technical papers.

One problem you may be facing is that a lot of people do go onto IRC and community forums asking for code that they can cut, paste, and compile. It is a very frequent occurance, and unfortunatly people who regularly hang out in technical chat rooms have become suspicious of almost everyone outside of their known group. From students asking for answers to their HW, to even employees of some cheap off shore programming firms looking for help with their commercial project, experienced programmers have unfortgunatly beocme wary of helping others.

I would recommend you join a community that is specifically focused on helping beginning game programmers. Such communities do exist, something such as XNA might be of help, it is DirectX and C# based, not OpenGL, and although DirectX and OpenGL differ by a fair bit, the important thing is that you find an established community of people willing to help you.

Programming is really one of the more open fields. Compared to the physical sciences it has a very low entry price (the price of a computer, no other supplies needed!) and as you have found out for yourself, it is something that anyone who has a desire to can take up.

(Also IRC is full of dicks :P Try a discussion forum, #1 search result is OpenGL coding: beginners)

Instead of links to advanced reading material, maybe the not-so-advanced reading material could have been more useful. What left me with the impression of elitism was the way they reacted, being totally rude and overdone, like if I they thought I was someone they hated in disguise.

People have on hand the references that they use most often, it may very well be that the people you are asking are not aware of the latest up to date introductory references, as it has been a while since they themselves made use of that sort of material.

If you want "close to the metal" POSIX API compatibility then there's Cygwin which is easier to use IMO and more actively developed but doesn't support the *full* POSIX spec or there is UWIN which supports most of the POSIX spec.

Combine this with OpenGL, OpenAL, the SDL and Cygwin/X, QT, a Java layer using the SWT from Eclipse, *shudder* GLUT *shudder* ;) or IMNSHO preferably wxWindows/wxWidgets and you've got yourself a full cross-platform programming toolkit that can do just about anything.

jdb2

If you want "close to the metal" POSIX API compatibility then there's Cygwin which is easier to use IMO and more actively developed but doesn't support the *full* POSIX spec or there is UWIN which supports most of the POSIX spec.

Combine this with OpenGL, OpenAL, the SDL and Cygwin/X, QT, a Java layer using the SWT from Eclipse, *shudder* GLUT *shudder* ;) or IMNSHO preferably wxWindows/wxWidgets and you've got yourself a full cross-platform programming toolkit that can do just about anything.

jdb2

"So I'm stuck using Vista, which is a huge beast, slow, and shitty. Now that Windows 7 is coming out, I would love to use that instead, but I get stomach pains when I think about handing my hard earned money to get what Vista SHOULD have been. Now I wait for the /. crowd to flame me to death me for using windows." - by purpledinoz (573045) on Wednesday August 05, @02:32AM (#28952599)

Not here to flame, but rather, to "enlighten you", on 3 things in VISTA/Server 2008, & yes, Windows 7 that you may or may not be aware of & that have been BLATANTLY DONE WRONG...

First, there is the lack of "NATIVE-TO-THE-OS by default" (for lack of a better way to describe it) OpenGL gaming support (which MS has 'torn out' of VISTA, & forces a user to 'hack in' something called an OpenGL icd (client driver) layer in order to play OpenGL games (which from what I heard long ago, this icd merely translates API calls to OpenGL from games into corresponding DirectX api display calls only, & looks like crap upon said translation but don't quote me on that, because I read this here on that note -> http://www.opengl.org/pipeline/article/vol003_7/ & it merely states MS is removing native OS support for OpenGL & you have to rely on your vendor for your vidcard to supply it only.

Without that "OpenGL icd 'hack'"? Well - From what I have heard, very recently too mind you from a pal of mine that is outraged he cannot install & play his copy of OpenGL based Quake 4 on VISTA even?? It's ticking folks off that have existing investments in OpenGL games... & I also do myself, & this also makes me 'steer clear' of VISTA + its descendants in Server 2008 + Windows 7. To myself @ least, it appears to be a "cheap trick" on MS' part to make "DirectX 'Uber Alles'" on the PC gaming front, by removing OpenGL as a competitor to Ms' own DirectX... I cannot respect that, & I DO consider it, "dirty pool". Yes, that is what I think of the "why" of why MS has done this to native OpenGL support in VISTA onwards.

Gamers: Feel FREE to correct me on this note though - I am NOT the gamer I once was, & I do NOT use VISTA, Server 2008, OR Windows 7 here (I only support them on the job on occasions where it is used, rare really, & not for gaming when I have done work on them), so I MIGHT be "off" on this account... however? On the next parts I note below, HOSTS & WFP?? That much I am confident of in what I state.

Thus, anyhow/anyways - I just cannot SEE how Microsoft can say "BEST WINDOWS EVER" etc. et al, when VISTA, Server 2008, & yes, Windows 7 clearly have been CRIPPLED on this account (&, yes, others too, I get into them next, though they are NOT about gaming but imo, something more important) &, the Operating System now LACKS FUNCTIONALITY compared to its earlier predecessors on this account (OpenGL gaming)

Secondly, & imo @ least, MORE IMPORTANTLY?? What's happened to HOSTS files, & the design of the WFP (windows filtering platform) for security... these deal in efficiency & security, respectively, & here we go on THAT note:

Windows 7, VISTA, & Server 2008 have a couple of "issues" I don't like in them, & you may not either, depending on your point of view (mine's based solely on efficiency & security), & if my take on these issues aren't "good enough"? I suggest reading what ROOTKIT.COM says, link URL is in my "p.s." @ the bottom of this post:

1.) HOSTS files being unable to use "0" for a blocking IP address - this started in 12/09/2008 after an "MS Patch Tuesday" in fact for VISTA (when it had NO problem using it before that, as Windows 2000/XP/Server 2003 still can)... & yes, this continues in its descendants, Windows Server 2008 &/or Windows 7 as well.

So, why is this a "problem" you might ask?

Ok - since you can technicall

The problem in this case is Microsoft using it's ability through the OS to lock you into a platform by incorporating technologies. If the directx API was opened up to the world and anyone on any platform could use it that'd be a different matter. It would be like them opening up their document formats fully free of patent encumberances. If the DirectX API was open and free we'd have cross platform gaiming, instead, we have developers only developing for one platform.

What is preventing a third party from implementing DirectX? What exactly do you think Wine is? How does TransGaming Technologies get away with selling a DirectX implementation in the form of Cider so that game vendors can "port" their games to OS X? Why do game developers continue to use Direct3D even when Windows supports OpenGL, even in Vista?

Should software vendors be forced to provide detailed implementation information of their APIs to other vendors? This goes well beyond file format and protocol specifications. It's not like Microsoft is keeping certain DirectX APIs undocumented to the outside world so as to cripple competing game developers.

Game developers that use DirectX are *choosing* to develop for Microsoft's APIs; Microsoft hasn't prevented them from using OpenGL and other APIs on Windows. Many are *choosing* to only market computer games for Windows, or selling them for Mac OS X by licensing a third-party DirectX/Win32 implementation. They are *choosing* not to make versions of their games for other platforms by using winelib.

The OpenGL 3.1 spec was released this week at GDC and is already getting some pretty positive feedback.

Perhaps Khronos learned from its past misteps and is moving forward in a positive direction? Here's to hoping!

What's with that OpenGL press release then? There it specifically says "...the company president showed off the development kit hardware and confirmed and the choice of OpenGL ES as the graphics API in order to facilitate rapid developer adoption and content creation. The Sony Playstation 3 will be using OpenGL ES for the 3D graphics API,..."?

So you have some contradicting information that you can provide? Give me a source that explains what PS3 graphics is build on or something. I'm glad if you can clear that up for me. From what I can see it's OpenGL ES (or maybe they use that for the menus only or what?)

[1] http://www.opengl.org/news/comments/sony_confirms_playstation_3_to_use_opengl_es/

Valve didn't port to OpenGL for the PS3; I'm pretty sure it was written "down-to-the-metal".

Well the speculation is (it makes sense) that the foundation for the Source engine on the PS3 is OpenGL ES (for Embedded Systems) -granted, I got that from Wikipedia "Citation needed" but someone got that info from somewhere. I also know that the PS3 uses OpenGL ES. I'd be very suprised 1) if Valve actually invested that much time and effort into hand-recoding the engine for a not (yet) so lucrative market and 2) if they couldn't use the OpenGL implementation of the PS3 version. It's apparently written to OpenGL specs and it should be a walk in the park re-engineering that to run on regular hardware (at least compared to manually re-writing the whole thing).

But, every major engine has OpenGL support. Some just choose to turn it off. It wouldn't be hard to turn it back on.

I'd don't know about that. Many engines are developed around DirectX nowadays and those need some major code rewrites to work without a Microsoft supported platform. That's why DX is a rather attractive system because it has a lot of tools and does tons of effects for you (basically a non-Open OpenGL).

Steam has been on linux. How else do you get Left 4 Dead linux servers?

Don't jump to false conclusions. A game server is WAY different from the client. Different like Apache is different from Firefox. They both work together all the time but they do completely different things and have other requirements. The client software has to do all the audio/video processing and rendering as well as user inputs and outputs. That's why it is so difficult to write for the different platforms because they all have different APIs and such to do your work. The server on the other hand just receives status informations generated by the client and replies with his set of data combined from all the other players. Linux game servers have been around since forever but someone taking the time porting a high-end client to Linux is actually a great big step forward (I'm still waiting for the UT3 client that was promised to me more than a year ago).

... But it would be nice to see a full, officially supported, Steam client & source engine for linux. It means something.

Let's just hope it actually happens when Postal 3 comes out or at least shortly after. I'd buy P3 even if I don't like the game just because I want to see if and how it runs.

Yea. This card is made for Cad functioning and not shading or any kind of gaming. The card is more for workshops.

Excuse me? Nvidia says

The reference standard for Shader Model 4.0 and next generation operating systems
Enabling breakthrough ultra-realistic, real-time visualization applications.
Available only on the Quadro FX 3700

Flip through the OpenGL specifications sometime. Ask yourself whether there are any features of OpenGL which are not useful for games.

Examples that have been used to sell Quadro cards in the past include:
wireframe antialiasing (as opposed to full screen antialiasing)
multiple clip planes
two sided lighting.

Come on! Do you play games in wireframe mode?

Yes, you might be able to fool the computer into thinking your GeForce is a Quadro, but, iirc, the quadro devotes a bit more silicon to these features, so the performance hit isn't quite as severe.

On the other hand, the Quadro is designed for precision over speed. If a frame is a bit more complex than usual, your framerate will drop. Not good for games.

I've got no funds, and I'm targetting Mac OS X and Windows initially, and maybe XBLA/WiiWare later. The first step is choosing a multiplatform framework (I'm using Playfirst's Playground SDK) or even a cross-platform library to develop your own framework (like SDL, OpenGL and OpenAL as appropriate).

Limiting yourself to one platform limits your potential customers. If you start with multiplatform at the beginning of development, it doesn't take much more time/effort (look how Blizzard works, they ship Mac and Windows binaries on the same disc).

There are other advantages to working multiplatform, too. Different compilers flag different errors and warnings, reducing your post-release support costs (for code bugs, at least). Different platform behaviours and expectations will point out UI and game play issues earlier. You've always got at least one current-ish backup of your code/assets on your "other" platform. ;-)

But, for the love of gaming, if you're not going to work multiplatform, don't make it impossible for third-party porting houses to do the work for you. And I'm not talking about your code here, I'm talking about wanting piles of cash up-front to "let" the third parties do the porting for you, or simply ignoring them.

Please check exactly what is covered by the SGI B and GLX licenses before you shout "Awesome!". The truth is, very little is covered.

All they've really tidied up to the FSF's satisfaction are the licenses on the GL and GLX headers and machine-readable specification documents, which are used in many FOSS bindings. It has also fully freed up SGI's sample OpenGL implementation, but that is 8-year old abandonware, and not used by anyone for anything.

This improvement in the license is undoubtedly helpful, but mainly to license Nazis, not to engineers.

It provides nothing new to anyone actually working with OpenGL, since the only working FOSS implementation of OpenGL (but unvalidated) is still Mesa 3D, which isn't dependent on SGI's license. nVidia's OpenGL implementation appears to be their own and not licensed from SGI (as far as we know), so nVidia OpenGL is not freed up by this relicensing --- they probably only license the OpenGL trademark from SGI (and that's a code-free SGI license).

So no, it's substantially less than awesome, since we still have no fully-accelerated OpenGL. And nothing changes, in practice, as a result of this announcement. (Check out #OpenGL on freeenode to see how underwhelmed everyone in the GL community is.)

What we really have here then is just a "PR success" which helps SGI and helps the FSF, but doesn't really do anything of significance.

What will definitely be "awesome" news for OpenGL+FOSS is when the FOSS community finally turns all that documentation we received from AMD and Intel and Via (but not from nVidia) into accelerated 3D drivers to work with a Mesa-based OpenGL. But that's a shitload of work (and our guys *ARE* working very hard at it), and so working systems won't be with us for several years yet.

So, sorry, not awesome, just PR.

Um, OpenGL already has a documented extension mechanism that is widely used, by virtually every vendor, to provide documented and open access to their extensions. Changing the licensing on one implementation of the standard will not increase the fragmentation of OpenGL, and fragmentation of OpenGL has not led nVidia and ATI to drop it.

In fact... looking at the listed extensions I see 15 _ATI_ extensions and 54 _NV_ extensions. :)

GLSL quick reference is pretty much all you need printed on your desk when writing vertex/pixel shaders :-)

There's always room for improvement.

Exactly. That's what OpenGL 3.0 was supposed to be - an improvement. We've been preparing for it for the last couple of years, only to be let down at the last moment. I'm not angry about that, just sad. I've spent the last 10 or so years working with OpenGL, and for some time it's been in desperate need for a clean break in order to remove the dependency on legacy cruft. Working in OpenGL often feels like you've been presented with 101 ways to skin a cat. Rendering a triangle in OpenGL is a good example. Display Lists, VBO's, VBA's, vertex arrays, immediate mode, NV fence, VAR, CVA, MultiDraw Arrays, interleaved arrays, and the list goes on. In D3D you have 2 methods - DrawPrimitive() or DrawIndexedPrimitive() and that's it. Any sane person would quickly realise that it's going to be a hell of a lot easier writing a driver for that than the GL methods.

They could be targeting all platforms with little extra effort. It's only M$ that doesn't want that to happen.

You didn't read my response correctly. If a developer is targetting windows only, you have 2 choices, D3D or GL. The difference in driver quality between D3D and GL is pretty big - due primarily to the current complexity of the openGL spec. A D3D driver in comparison has none of that legacy cruft and the result is relatively stable drivers for more or less every graphics card (Intels graphics cards are a good example - appalling openGL support!).

Hello? I feel like I'm talking to a marketing zealot here.

No, you're talking to an openGL programmer who writes animation software for a living (which incidentally is cross platform). Have you not been following anything that's been going on here? There is no astro-turfing going on for god's sake - In this instance Microsoft has been able to sit back and watch with amusement as the khronos group have erected their own gallows and hung themselves.

What part of "Look at all the posts that repetitively try to imply OpenGL isn't complemented by many other libraries." do you not understand?

I understand you perfectly - from experience they tend to be a bit of a mixed bag. More often than not, those libraries use display lists, immediate mode etc etc - all the things you don't want to be using in a high performance graphics app.

There are any number of free math and matrix libraries available.

Which are SSE optimised, fully featured, unit tested and include full documentation?

Your comment about the device driver bugs is makes sense though my understanding is that's a mainly a problem with the driver developers, not OpenGL.

It's not the driver devs, it's the GL spec that is the problem, plain and simple. ATI and Nvidia originally proposed GL3.0 as a way to simplify the driver writing process and better expose the power of the hardware to OpenGL. Take for example glBindTexture. Are you compiling a display list? Is aprogram bound? Does the texture object exist? (The spec makes no requirement for you to use glGenTextures() to generate the ID's - so the driver has to deal with those rare cases - even though few devs actually do that). The process of binding a texture has to interoperate with a multitude of legacy extensions, the vast majority of which are not used by developers these days. The net result is that the drivers are complicated, and anywhere upto 10% slower than they need to be (NVidia's figures, not mine). Take a look through some of the GL extensions and have a look at the dependencies section. That might start to give you an inkling as to why the drivers are buggy - It's a damned hard spec to code a driver against.

Lets take another example, geometry shaders. DX10 has had geometry shaders that run on ATI, Nvidia and Intel cards since it's release. OpenGL 3.0 was supposed to add them as a core part of the spec. It didn't. So now

May I suggest to look at this explanation posted by somenone who worked on the spec. It gives a list of clues of why the API is in that state.

The most fundamental alteration packaged with OpenGL 3.0 is the addition of EXT_direct_state_access, which allows programmers to bypass a lot of the sticky "state" based behavior that's been the over-long kludge of OpenGL. Carmacks name is on it.

EXT_direct_state_access is their answer to your state machine problems. Although it hasnt abolished state, the extension is designed to make it accessible: whereas previously programmers had to update selectors and latch in state, the EXT_direct_state_access extension attempts to, from what I can discern, provide easy on-demand access to various states, no context switching required.

As you are the only sane comment I've read from this entire thread, I'd be interested to hear what you think of EXT_direct_state_access.

Take a look at this extension: http://www.opengl.org/registry/specs/EXT/direct_state_access.txt This is actually quite significant. I think it could form the basis of the object system that was promised but not delivered.

"XP wasn't a flop"

How can you say it was or wasn't when there is only one one significant OS vendor?

There are plenty of OS vendors, and substantially more that give their OS away for free. Yet, the combination of all those people haven't managed to expand out into more than 10% of the market. I can pretty confidently say that XP wasn't a flop.

MS didn't support OpenGL very well

The people at OpenGL think otherwise.

Not really, OpenGL and DirectX have always been more than competitive.

Also OpenGL technically benefits MORE from the new WDDM in Vista because of the RAM allocation system and GPU scheduling as the OS handles all these details for OpenGL and OpenGL applications.

The ICD still has to be optimized to pass through and work with the new Vista WDDM model, so as Vista was first released to now, just like with DirectX - OpenGL on current drivers is considerably faster than the horrid RTM drivers from both NVidia and ATI for Vista.

Right now in MOST circumstances, even games running in an Aero Window, they are running faster under Vista than XP, no matter if they are OpenGL or DirectX.

http://www.opengl.org/pipeline/article/vol003_9/

One game a technician here plays is City of Heroes, that is a hybrid DirectX/OpenGL application (see NCSoft for more details), the tech runs the game inside a Window with Aero active, as it is 10% faster than running it full screen, which turns off Aero's composer. Why the improved performance with Aero is unknown, but measurable and a testament to the speed of how Aero is implemented with the shared device context and texture methods it uses instead of dual memory or double buffering like you find with Linux or OS X.

I personally have more regard for DirectX because of being involved with SGI and the 90s OpenGL specifications, where MS couldn't force the OpenGL participants to move to 3d Hardware gaming type constructs, even after writing a few test specifications for OpenGL. If OpenGL would have had a better view of the future, there would have NEVER been DirectX as MS wanted to be a big OpenGL proponent.

I think OpenGL shot themselves and a lot of users in the head with their closed minded moves, and if it hadn't been for the gaming movement of Linux when 3D acceleration was becoming a normal aspect of computing, OpenGL to this day might have disappeared or remained a 'high brow' 3D specification that didn't want to dirty their hands with more direct 3D hardware support or features condusive to gaming.

Anyway, check out the link, there are several posted about OpenGL performance on Vista in the past few months comparing both it and DirectX to various situations and XP, showing that the rewriting and optimizataion of the Vista drivers fro NVidia and ATI for the past few months are finally as mature as the XP drivers. (Which isn't too bad considering they were written from scratch late 2006, with no real world performance or game profiling optimizations that the XP drivers had built on for years.)

Here is another thread a tech here has been following and forwarded to me this morning, since I was reading it right before I flipped to SlashDot, I thought I might as well include it as well, not a concrete study or test, but more of what users are experiencing to their surprise after all the negative Vista vs XP press:

http://futuremark.yougamers.com/forum/showthread.php?t=72298

http://www.opengl.org/pipeline/article/vol003_9/

"Some have suggested that OpenGL performance on Windows Vista is poor compared to Windows XP. This is not the case."

If there is anything that I have learned in the past 10 years of writing code (since before high school), I have learned that the following sequence of learning is ideal.
1. HTML/CSS/JavaScript - Get acquainted with web programming. None of that Nambly-pambly BBCode crap that they offer on MySpace.
2. Python - I wish I had got into this before I learned C++. Good for learning about shells if you decide to switch to Linux or BSD, especially if you decide to create your own website through a webhosting provider that uses SSH.
3. C/C++ and/or PHP/MySQL. - Playing with the big-boy toys at this point. The safety net that points 1 and 2 provided has been lowered.
4. OpenGL or Assembly Programming. - Really advanced programming! OpenGL is high-level. Assembly is low-level.
From there on, the sky is the limit.

It also works on XP, linux, Mac OS X, ... , and has the same capabilities as directX10, and is furhtermore used in cad, design, ... software.