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?
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?
By the sheer amount of DX games out there, isn't it obvious that the game industry doesn't find DX clunky and hard to program in. And remember DX offers MORE than just graphics. It also does sound, input and networking.
As we've seen this year, game companies don't care whether DX limits them to windows or not because:
1- Almost everyone uses windows to play games on.
2- If they ever did want it ported to other platforms, there are companies (you know who they are) that will do the porting for you (yes, that includes porting DX games).
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.
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
OpenGL only offers graphics, dx offers: graphics, joystick, sound, forcefeedback, mousecapturing.
There are libraries giving you all these features using GL graphics, but they are not made full time and/or they are made by hobby programmers. The keyword here is time. MS have employed programmers to create, maintain DX. This means better time, and resources making a better product overall. Not just the graphics part. The graphics part of DX is not better than OpenGL, it's just everything around it.
Look a monkey!
Btw, you're comparing apples to oranges here; DirectX is a gaming architecture, while OpenGL a graphics one. You should compare Direct3D with OpenGL. :-)
:-)
Simple answer:
Direct3D is now simpler to use, better supported by video card manufacturers, and more OO than OpenGL.
Long answer:
Up until recently, OpenGL was considered more advanced because it was more high-level. You didn't have to write as much OpenGL code to get stuff to work as you did in Direct3D. (Immediate mode, we're talking about here; only a complete moron would write Direct3D retained mode code, what with the overhead it causes.)
However, with the release of DirectX 8.0, this has changed. Direct3D is now a lot cleaner and easier to use. No more does every card have all these annoying mode bits for every single little thing; the market has consolidated in such a way that the major players all support simultaneous use of the most important stuff. (In the olden days, you had to check mode bits to see if you could use alpha blending and bilinear filtering at the same time, for example. Some cards did it, some didn't. You had to have a work-around in case each of these things failed. This is no longer a problem.)
Additionally, Direct3D 8.0 takes OpenGL's way of looking at things, adopts, extends and surpasses. Ever heard of vertex shaders? Pixel shaders? In OpenGL, these are just extensions that are implemented differently by the video card manufacturers. (If they're available at all..) In Direct3D, they're an integral part of the API. And they'll become even more important in years to come. Here's why:
Anyone remember back before video cards could do stuff on their own, when you did everything on the main processor and pumped it to the video card raw? Well, we're in those days right now with video card design. These processors have very specific things they do; if you want to make a dynamic texture, you'll have to ship it back to the main CPU to process it there. Weighted vertices that use in excess of a certain number of matrices (I'm talking about skinned animation systems here) have to be done on the CPU. The message here is that what the video card can do is very limited, and is "hard coded" in the hardware. There isn't much flexibility here.
Enter "shaders." These are little applications (more like scripts, though, since there are no branches in execution) that you can run inside the video card. Instead of going through all the vertices on the CPU and transforming 'em or whatever on the CPU, you can write a little program called a vertex shader which'll do it for you on the video card. And pixel shaders will do the same for your textures; now you can have zoom effects, warp effects.. heck, you could probably implement Photoshop as a set of pixel shaders. (In fact, I don't doubt they're looking into it as I type.)
You see, the graphics API's no longer just a one-processor API with DirectX 8; Direct3D has become an operating system unto itself! Vertex shaders and pixel shaders are like specialized mini-drivers that you load to access the additional functionality. It's really quite neat! I can't wait to see what the demo scene does with these things; the possibilities are endless!
As for the OO thing, have you ever considered just how many games are OO? Considering OpenGL's very C-ish nature, C++ programmers are easily going to gravitate towards Direct3D, simply because of it's C++ OO design. (And lets not even get started on what happens whenever you throw more than one monitor into the mix. I mean, with DirectX, all you do is use another pointer; what do you do in OpenGL..?) Add in the fact that you'll need DirectX for input and audio either way, and..
Wrapping things up, until OpenGL catches up to Direct3D in terms of it's integration of vertex and pixel shaders directly into the API, (programmers are lazy; they don't want to have to go searching for a frickin' function pointer to access an extension..) it'll be playing second fiddle to Direct3D in the minds of developers. Especially with the X-Box coming out, and everybody and their cow wanting to port to it.
Anyways, carry on..
James
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
I see this "If you code in DirectX, at least it will work on all cards" canard repeated so often, I can only marvel at Microsoft's propaganda machine and the essential stupidity of mankind. Why do you think so many new DirectX games fail to work under a number of cards until they release patches?
As someone who's coded in both (and Direct X for a game that must support a wide range of cards), an OpenGL program is far more likely to work on a given range of cards if you haven't coded in explicit support for those cards. The equivalent DX program will require far more setup and test code.
People don't seem to understand this about Direct X: It supplies a feature set, but different cards implement different parts of that feature set. You have to *explicitly test* almost any feature you can name to see if the card can support it, via "capability bits". Try getting hold of the DX caps viewer, and you'll be able to see just how many of them there are.
In fact, it's worse than that. Because old drivers often lie about their caps. (Hello Virge.) Also, the caps, especially the texture caps, often don't map nicely to a card's capabilities. So the only real way of seeing whether a particular texture stage setup will fly is to try it, and see if the driver rejects it. Plus there are the weird-arse ones like the NVIDIA 8-stage setup where they jump through the hoops of the DX API to expose their register combiner functionality. (Functionality that is directly exposed in OpenGL, BTW.) Cards also have different capabilities depending on which release of direct X their drivers support. So the same card can report completely different caps depending on driver version. It's a support and programming nightmare.
The only real way to deal with all this is know what each card is capable of, read the manufacturer's release materials, and spend time on the DX mailing list. You spend a lot of time programming a particular effect in a number of different ways, and hope like hell all your combinations cover all the cards out there. You cannot guarantee a particular card will work with your app until you test it.
You may assume that DX provides fallback paths for some features, but you'd be wrong. Or where it does, it does it in a braindead way; because your card lacks fabby next-generation feature X, and you requested it, wham, it emulates the *entire* pipe in software instead of just feature X. You lose T&L, and your framerate slows to a crawl. Then you either code your own pipe to do feature X on the CPU and then hand off properly to the card, or you just go without. Either way involves a lot of testing code. OpenGL is much, much better about falling back gracefully.
I'm also not clear on why people think DirectX has a technical edge. Microsoft do a fine job of going to the current hot hardware vendor, incorporating their upcoming features in their API, and then making a lot of noise about it. But you could access vertex shaders on the GeForce3 from OpenGL on the Mac before you could ever use them from DX. The OpenGL extension mechanism means that when a part comes out, you almost immediately have access to its new features, rather than having to wait for the next DX rollout. (Remember, NVIDIA had to install a "back door" to provide access to the full register combiner functionality of geforce1-2 cards from DX. Many people don't even know it exists.) Go to NVIDIA's web site and ponder how many of their tech demos these days are in OpenGL.
The only thing DirectX has going for it, its so-called unified API, makes no difference at all in the end. You end up doing exactly what you'd do in OpenGL -- testing for certain cards, and using their exposed abilities if they exist. Writing a lot of fallback code. In the end, you're better off going with the card manufacturer's APIs, IMHO.
Think of it this way: rather than exposing a unified API, DX exposes *every possible API*. So many wonderful standards to choose from! If you're a unix guy: DX8 is the X11 of the 3D graphics API world.
A.
P.S. Sheesh, I haven't even touched on the headache that is resource management in DX.
P.P.S As someone who has to deal with all this shit (card compatibility), I'm a mite touchy on the subject =)
I write 3d game engines for a living, and have been fighting this issue for a decent part of my career.
The OpenGL ARB really doesn't give a crap about games. Sure, there are a number of vocal game advocates, but the majority of the membership is far more interested in maintaining backwards compatability to older SGI and Evans and Sutherland hardware than keeping up with accelerator progress.
If the ARB did care about games, there would be a concerted effort to standardize on vertex and pixel shader instructions between card vendors, and a move to get these into the standard AS FAST AS POSSIBLE, and a push to actively participate in ongoing features. Instead, it took them years to drag in a few interesting extensions, and Microsoft has assumed the unifying role in the gaping vacuum.
As a game developer who has spent too many man-years fighting abysmal M$ API bugs and design limitations since Win 3.0, even I will admit that Direct3D has completely exceeded OpenGL as a 3d game development platform. Why should I invest six+ months tuning seperate nVidia and ATI shader support engine features under their respective OpenGL extensions, knowning that this GL code is barely reusable and is tied to a VERY limited set of cards?
Add to that M$'s role at the ARB, and the influence they throw around with their money to keep other members in line (remember Farenheight?)
Unless the ARB makes tremendous changes in its policy of staying 3 years behind the hardware, I strongly feel OpenGL is relagated to the niche BASIC fell into. Sure, you can get it on all platforms, but its so slow and feature poor, why bother?
I wouldn't hold my breath...
> I think it's only been established that Id didn't do well with the Linux gaming market
All linux games sales EVER don't add up to one medium selling windows title. We are one of the creditors that aren't likely to see money that Loki owes us, so we have some idea just how grim it is.
That isn't saying that it can't change in the future, or that doing linux ports isn't a Good Thing, but it isn't an economic motivator at the present time.
John Carmack