Slashdot Mirror
What is Happening with OpenGL?
Trapped In Windows Hell asks: "I was just at the local game store looking for a new game, and I noticed the absolute lack of ANYTHING other than DirectX games. Where has OpenGL gone, and what does this mean for games on GNU/Linux? If DirectX is so hard to program in, so clunky to use, and limits the game to being sold on only one OS, WHY do so many programmers use it? It seems logical (to me, at least) that programming as portably as possible, as simply as possible, and using standards where possible, leaves a lot more sales options open for the future... and DirectX seems to close all options *but one*." OpenGL use in Windows gaming has decreased dramatically in favor of the use of DirectX which is improving with each release. Will OpenGL continue to mature on the Windows platform (which arguably is the platform that drives most of the mainstream demand for graphics) or will it continue to stagnate as game and driver developers concentrate on the offerings from Microsoft?
When you only have 1 OS that you plan to sell your game on, why do you need something that is cross-platform? When 92% of home users run Windows, and many people who have linux also have a windows install for playing games, why would you put your extrememly limited money and time and effort into supporting something that's not needed? It's just like OS/2's problem. If they didn't support Windows applications, nobody would use their OS (even though it kicked ass), but if they did support it, nobody would natively develop for their OS because they didn't have to.
And from what I've heard, DirectX is not clunky nor is it hard to program in.
I think that once linux starts getting a much larger hold on the desktop, then we will start to see games being developed for more than one platform.
That just made me think, is there such a thing as an OpenGL for gaming consoles? Imagine how much nicer it would be if you could program your game once for one API, and run it on PS2, N64, GC, etc, etc. That would be really kickass!
If God gave us curiosity
Nowadays it seems that more and more new games are scheduled for release on the mac and pc simultaneously (or more often: the mac version released shorty after the pc version) Since most pc games are using DirectX, it's apparently not too hard to port them to OpenGL.
Come to think of it, the companies that are porting games to Mac OS are probably the ones that would be best at making linux ports. By porting the games to SDL they suddenly have a port that runs on two platforms.
Somewhere in the heavens... they are waiting.
Why must is be written with one platform in mind? Why not use SDL and OpenGL (if you need 3D). Put the Windows, Linux etc. executables on the same cd and what is there to loose? If the games sells poorly for linux the same package could just be sold to a windows user.
I've done extensive OpenGl (Mesa) programming, and no it isn't. My programs ran equally well on a UltraSparc running Redhat and also regular PII machines with RH 6.2, without me even knowing any of the graphics cards that were installed.
OpenGL is a 3d programming API, which means it allows the programmer to not be concerned with the hardware itself, only that OpenGL is present so it can be called.
By the way, OpenGL is not really "open" software, it is a very expensive license from sun if you want to use it. Most Opensource developers would be interested in Mesagl, which is basically an open source version with some changes.
The upcoming Detonator 4's (supposed to be released last week, now "very soon") will support OpenGL 1.3. A good sign, as they are the major player right now. This includes:
Cube map texturing -- for higher quality environment mapping and lighting support
Multisampling -- for order-independent anti-aliased rendering of points, lines and polygons
New texture modes that provide more powerful ways of applying textures to rendered objects:
Texture Add Environment mode
Texture Combine Environment mode
Texture Dot3 Environment mode
Texture Border Filtering mode
Compressed texture framework -- to allow higher quality textures in less memory regardless of file format
And remember DX offers MORE than just graphics. It also does sound, input and networking.
DirectX's networking protocol is pure crap. It is not client/server so both machines must be able to accept incoming connections. If you're behind a firewall you have to open about a hundred ports to get it to work and if you have any kind of NAT/sharing device you can only have ONE machine able to play games over the net.
Fortunately most developers have realized this and code their own networking code.
OpenGL only offers graphics, dx offers: graphics, joystick, sound, forcefeedback, mousecapturing.
Since DirectX is really a set of APIs (DirectDraw, DirectInput, etc.) I'm not sure this is a fair comparison. When we talk about OpenGL, of course we're only talking about a graphics API. Haven't you heard of OpenAL? It's a complementary open audio API. There's even an input API called OpenIL, and more? My point is, if you aren't going to compare MS's set of APIs to another complete set of APIs, like SDL, then at least compare it to the entire set of Open*L APIs. As new as some of them are, they do exist!
All fixed in DirectPlay 8. Do try to keep up.
There are well defined, cross-platform Fortran and C bindings for OpenGL - so if they *were* doing CFD or heat flow visualisation, then OpenGL is the most likely choice. Also, all really high-end cards are OpenGL first, DirectX second - they tend to be geared towards very large numbers of triangles necessary for scientific visualisation and modelling work, not the big textures abnd relatively low poly counts found in games, anyway, so OpenGL is the logical choice.
Direct3D means you basically have to use MS VC++ and COM on windows. I know that, in theory, you can use the COM objects from other languages with COM bindings, but that's painful.
Choice of masters is not freedom.
That's not correct. Alice uses DirectX only for setting the screen resolution. The rest is all OpenGL. Trust me - we have it working just fine in Wine.
-Gav
--
Gavriel State, CEO
TransGaming Technologies Inc.
gav@transgaming.com
As far as I know, D3D has yet to retire the "capabilities" bits that you have to check to determine whether features are supported but which still cannot fully specify feature interlocks (feature A isn't supported at the same time as feature B)--OpenGL disallows feature interlocks. D3D also allows different hardware to provide different numbers of, say, texture units. OpenGL 1 and 1.1 are the only APIs that provide a single consistent baseline that always works. (1.2 adds optional multitexture and a few other optional components--personally, I think controlled, macroscopic options are a lot easier to deal with than low-level detailed ones.)
By definition, any API which totally works for all hardware perfectly is a least-common-denominator API. There are three consequences of that: one, when something new like DOT3 lighting comes down the pipe, there are some cards that have it and some that don't. So of course it can't "just work", whether OGL or D3D; it just works in the sense that the feature is unavailable (D3D for a year until they release the next version) or else programmers have to cope with OGL extensions or D3D caps bits.
Second, OpenGL developers were using DOT3 lighting on GeForce long before DX developers, because of the availability of an extension mechanism. That OGL interface still works, unlike D3D code--the D3D interfaces change every other revision. Eventually people get together and agree on a general, multi-vendor extension, like the ARB_MULTITEXTURE extension. Some extensions--for example many of Nvidia's--are actually well-designed enough that other vendors can just implement them as is, despite their hardware not working in the same way. And the ability to fall back on the detailed extension is great when you want to push a piece of hardware to the limit--is it possible to even come close to the capabilities of NV's register_combiners GL extension on GeForce 256 and GeForce 2 when coding in the newest gee-whiz whizbang D3D stuff?
Third, Microsoft's D3D effort is driving the marketplace to homogenize--for every hardware developer to provide the exact same feature set. If that happens (it hasn't yet), that will be bad for future feature developments, since the hardware developers will just be putting in whatever features MS is defining in the next D3D rev, and focus on distinguishing from each other on raw performance. Should MS be defining the featureset of third-party hardware? (If your natural response is 'yes', go look at Talisman.) Without an extension mechanism (D3D still doesn't have one, and MS is adamant about not putting one in), if OpenGL dies out, MS is just going to put in whatever random features they feel like (like the original poorly-designed EMBM support).
As OpenGL advocates said from day one: yes, MS can keep revising D3D to add features from OpenGL (e.g. stencils), and eventually it won't suck. But the only reason for them to do so is so they can own the API--OGL would have been a perfectly fine 3D API as soon as all hardware had the minimum baseline (e.g. Voodoo 1). Lo and behold, they've beat on it enough, it doesn't suck, and now they're owning the API and starting to dictate significant feature sets (e.g. vertex 'shaders').
I cosigned the OpenGL developers' open letter to MS, and you know, they never did ship the direct draw bindings for OpenGL, nor the Win95 MCD-driver support (which would have made it a lot easier for hardware vendors to release OpenGL drivers that only accelerated rasterization, just like the first 6 versions of D3D, and which they had released for NT). I'm sure it would have been a poor business move for them to do so: because they wanted to own the API.
So yes, let's all forget all those details and just repeat the MS FUD: "OpenGL is for scientific/modelling apps, D3D is for games!" and "OpenGL works unpredictably on different hardware, whereas D3D is consistent". If there's a truth to the latter, it's due to the OpenGL drivers... and I'm comfortable laying a lot of the blame for that at MS feet.
--Sean Barrett, renderer programmer for "Thief: The Dark Project" and "System Shock 2" (both D3D)
The DirectX SDK comes with a lot of documentation, examples, background info etc, so a beginner and a novice and even an expert can jump right in and start hammering out code.
With OpenGL that's totally different. First you have the OpenGL 1.1 documentation in the MSDN (clearly the best around, sorry), and for extensions you have to dig into pdf's, vague marketing info and other crap.
Example? nVidia will soon release an ICD that is OpenGL 1.3 compatible. But... how to use that OpenGL 1.3 API in your code? Is there a nice piece of examplecode that 1) explains the 1.3 (or 1.2!) functions extensively, 2) shows you how to actually USE these functions in your code without having to hassle around with glext.h's that are out of date and lack definitions for 1.2 or 1.3 functions and constants.
Never underestimate the relief of true separation of Religion and State.
I'm still developing everything with OpenGL, and I'm still targeting mac and linux as well as windows, but I want to rationally address some points in the API debate:
D3D is clunky, etc
Not really true anymore. MS made large strides with each release, and DX8 can't be called a lousy API anymore. One can argue various points, but they are minor points. Anti-Microsoft forces have a bad habit of focusing on early problems, and not tracking the improvements that have been made in current versions. My rant of five years ago doesn't apply to the world of today.
I do think that the world would be a slightly better place if Microsoft had pulled an embrace-and-extend on OpenGL instead of developing a brand new API that had to be rewritten a half dozen times, but its water under the bridge now.
Open for more sales, etc
It has been pretty clearly demonstrated that the mac market is barely viable and the linux market is not viable for game developers to pursue. Linux ports will be done out of good will, not profit motives. From an economic standpoint, a developer is not making a bad call if they ignore the existence of all platforms but windows.
DX8 Gives more features
Some people have an odd view that an API gives you features. Assuming you don't care about software emulation, hardware gives you features, and an API exposes them. If you try to use vertex programs or bump env map on a TNT, DX8 doesn't magically make it work. DX8's hardware independence is also looking a bit silly now as they make point releases to support ATI's new hardware. They might as well say D3D-GF3 or D3D-R200 instead of DX8 and DX8.1.
All of Nvidia's new features have showed up as OpenGL extensions before they show up as new D3D features.
Divergent extensions haven't been a problem up until very recently. All of the vendors tended to support all the extensions they could, and if they had unique functionality, like register combiners, they made their own extension. The current status of vertex programs does piss me off, though. I really wish ATI would have just adopted Nvidia's extension, even if it meant not exposing every last bit of their hardware.
Abstraction in a high performance environment can be dangerous. If you insist that all hardware behave the same, you prevent vendors from making significant improvements. If the spec for behavior comes from people that aren't hardware oriented, it can be a huge burden. D3D still suffers somewhat due to this, with some semantics and odd features that make hardware guys wince.
The Good News
We are rapidly approaching a real golden age for graphics programming. Currently, cards and API's are a complex mess of hundreds of states and function calls, but the next two years will see the addition of the final primitive functionality needed to allow arbitrarily complex operations with graceful performance degradation.
At that point, a higher level graphics API will finally make good sense. There is debate over exactly what it is going to look like, but the model will be like C. Just like any CPU can compile any C program (with various levels of efficiency), any graphics card past this point will be able to run any shader. Some hardware vendors are a bit concerned about this, because bullet point features that you have that the other guy doesn't are a major marketing feature, but the direction is a technical inevitability. They will just have to compete on price and performance. Oh, darn.
It's a Turing machine point. Even if OpenGL 2.0 and DX10 don't adopt the same shader description language, they will be functionally equivalent, and could be automatically translated.
There is lots of other goop like texture specification and context management that will still be different between API, but the core day-to-day work of a graphics programmer will be basically above the disputes.
John Carmack
The Playstation II game "Star Wars Starfighter" was developed using a Playstation II version of OpenGL. It looks, from reading the 'postmortem' on Gamasutra that this decision was made when the game was initially being developed for the PC, and that the change allowed the code to be migrated to the PS2 with relative ease.
Maybe the 'saviour' of OpenGL as a games-level API lies in allowing similat (I know about card-specific bits..) code to be used on all main games platforms, Windows, PS2, XBox, and so on?
404 Not Found: No such file or resource as '.sig'
From the Mesa site (http://www.mesa3d.org) :
Please do not refer to the library as MesaGL (for legal reasons). It's just
Mesa or The Mesa 3-D graphics library.
At that point, a higher level graphics API will finally make good sense. There is debate over exactly what it is going to look like, but the model will be like C.
It seems odd to adopt C as a model for universality. I was working with a co-worker of mine who was having trouble compiling some good-old-fashioned ANSI-compliant C code on MSVC 6.0, because it isn't standards-compliant. While most architectures seem to be able to compile a dialect of C, I dunno if one can really say C is universal. While the rate of change for introduction of incompadabilities with C seems to be slowing, it acts very much like an organism continually mutating and diversifying itself.
An interpreted language like Python may be a better model, because it behaves transparently in spite of the underlying architecture. That and some folks are already using it as a high-level graphics language.
I have personally always questioned the existence of Direct3D (I am not talking about DirectX in general here), since I really can't find anything it has contributed to but fragmentation of API:s and drivers. I am not out to bash Microsoft here, but I really can't help to see how well Direct3D fits in with Microsft's known ability to use its power (and near monopoly) to crush the competition. Direct3D does not only hurt OpenGL, but also gaming on other platforms in general, thus forcing consumers to the one and only alternative... Anyone but me thinks Deja vu? Why didn't Microsoft simply develop a DirectX wrapper around OpenGL, like SDL? This would allow OpenGL to integrate transparently into the rest of the DirectX stuff and at the same time avoiding the introduction of a completely new redundant API.
>>>>>>>
The public has a short memory indeed. While MS no doubt uses Direct3D to compete with OpenGL, its not D3D's main reason for existance. D3D was created to keep Glide from becoming the de-facto Windows 3D API. MS had lost a lot to Apple when Quicktime became the major media format on Windows, and Bill wasn't having a competing propriatory API on his platform. OpenGL wasn't even an issue until Carmack decided to use it for GLQuake, and even then, it didn't become popular until NVIDIA introduced full-blown ICDs into the consumer market. Thus, your wrapper idea has two flaws. First, the whole point of DirectX in general is to remove as many abstractions as possible while still maintaining hardware independence. Wrapping around OpenGL (which significantly more abstract than D3D even today, and was much more so back when D3D was created) would have gone across the grain of the D3D API. Second, since OpenGL wasn't even a player in the consumer industry at the time, MS might as well have wrapped over Heidi for all the good it would do.
OpenGL works great (why else do the #1 3D-genius favor it),
>>>>
Carmack is the One True Game Creator (TM) now? He favors it because it didn't like the early versions of DirectX, and because it is cross platform. I haven't heard him say anything about its technical merits in a long time.
just look at the Quake-engine games and the upcoming Doom... OpenGL had this when Direct3D didn't even exist and was clearly the better API for a long time.
>>>
Keyword, "was."
It is robust, also cross-platform and not controlled by a gigantic "closed" company. So the choice should be a no-brainer, right?
>>>>>>>>
Not for Microsoft! Or have you changed the subject somewhere and I just missed it?
I believe the developers are to blame. Tim Sweeney once chose to replace the ageing proprietary Glide API in his Unreal engine. He decided (about the time of DirectX5) to go with Direct3D, citing better driver support. This is just such a bad argument... Direct3D drivers may have been better back then, but OpenGL support is today as good as Direct3D. OpenGL was back then already a mature, proven API. How would driver support be for OpenGL today if OpenGL was the only (or favored) API?? Just think about it....
>>>>>>>>>
I don't know how bad a decision it was for Sweeny. A lot of people will say that D3D is technically superior to OpenGL today, and 99% of UTs users are on Windows anyway, so I don't think he's lost much.
If developers really care for gamers they should do like John Carmack. He has put free effort into bringing his gaming experiences to as many people as possible, no matter what underlying platform they use, by contributing to the improvement of free OpenGL drivers himself (through the Utah-GLX project). His creations run on virtually every platform out there and they have always been on the bleeding edge. This prove that cross-platform gaming is possible, but only if the will is there and the right choices are made.
>>>>>>>
Let's get this straight. Gamers run Windows. Consumer D3D drivers, in general, are better than consumer OpenGL drivers. D3D is also more powerful, for game development anyway. If developers want to help gamers, they should use the API that runs their game best on the user's hardware. Right now, and for the forseeable future, that API is Direct3D. Now whether or not it is good for the OS market in general is another issue entirely.
So, my question to game developers is: Why choose Direct3D? It's not as if OpenGL won't run on Windows...
>>>>>>>>
Its more compatible. Only a few vendors have really good OpenGL drivers, even today. Its more powerful, since it has more default features. It is easier to support, since there are far less problems caused by buggy OpenGL drivers, and the extension mechanism (which developers detest by the way) isn't present in D3D.
A deep unwavering belief is a sure sign you're missing something...
Direct3D means you basically have to use MS VC++ and COM on windows.
Actually, you can use CodeWarrior to write DX code. I know a bunch of people who do.
As for the whole DX OpenGL thing, After watching my co-worker play Max Payne for 4 hours, Direct3D has actually become a very good looking way of presenting 3d graphics. And at points, i find it to be better than OpenGL, much cooler effects, and much smoother, but that's just me. Anyway, most probably won't read this. Yay moderation!!
Slashdot...it's like Fox news, but without the biased sl...or maybe not.
Was it by any chance this company: http://www.5dt.com/? Chances are it was .. there aren't more than a small handful of companies here doing this line of work. Anyway, I work for 5DT, so perhaps I could offer a little more background. We do mostly use DirectX, but we have developed a Software Development Kit for our own use that provides an abstraction of a generic 3D renderer. Behind this abstraction we have both Direct3D and OpenGL implementations. This allows our software to run using both OpenGL and Direct3D. The main reasons we have done this is (a) possible portability in future, should we need to sell systems using OpenGL, (b) Direct3D programming is clunky and difficult, and it is counter-productive if most of our programmers have to learn it, and lastly (c) by supporting both, we ensure the process has resulted in a "good abstraction". Using such an abstraction provides for easier/faster learning curves and more stable, robust software. So we now only really need one programmer dedicated to knowing all the ins and outs of Direct3D, the other programmers can focus more on the important stuff - the application development. Creating this SDK has allowed us to have much faster application development times, as well as having more robust software.
In the past, our OpenGL support lagged a little behind the Direct3D support - previous iterations of our software were Direct3D only, and the main reason in the beginning for this was a decision to try stick to Microsoft standards wherever possible (trust me, this was not my decision :) (See my website for my own opinion of DirectX) Anyway, our OpenGL support is now on about the same level as the Direct3D support, so all of our new applications work interchangable with both.
From the perspective of our clients, most of them couldn't be bothered if the software uses OpenGL or Direct3D - they just want the software to work. From a performance perspective, we've found that both OpenGL and Direct3D are extremely similar, there is no real advantage for clients to use any particular one. Interestingly enough though, when using dynamic texture techniques (procedural textures / texture caching), we've found that on Windows2000, Direct3D has some horrible performance problems (becomes very jerky), while OpenGL remains smooth. We've never had clients that insisted on one over the other (OpenGL/D3D) though.
We also use other components of DirectX for input and sound. For networking we use sockets (DirectPlay is a waste of time, tried it), although for that too we have our own abstraction layers, thus allowing our software to be more potentially cross-platform, should a client require a different platform. Pretty much all our clients up until now have used Windows.
D3D is technically in the lead, but using GL extensions makes up for this.
Its true, DirectX will be run reliably on cheap Windows boxes. But so will OpenGL. We primarily use nVidia cards, on which both are supported. However, this wasn't the case when we first made the decisions - when we first made the decisions to go with Direct3D, mainstream 3D acceleration had only just started to take off, and the future of OpenGL looked a little wobbly at that stage - acceleration support for OpenGL on mainstream cards was almost non-existent in the beginning, while most card manufacturers *were* getting D3D support. This was the main reason for the decision back then. This reasoning is no longer true, generally support for GL and D3D are very similar, but our software is anyway now structured such that both are as easy to use. One other main reason to focus on D3D? Its "safer" - Microsoft is most likely to be around ten years from now. The future of OpenGL (and of SGI itself) has looked a little wobbly in the past, and although better now, still isn't as assured).