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).
Kudos to Cliff for not just taking the anti-MS-at-all-costs FUD from the questioner as gospel. DirectX improves a LOT with each release. DX3, or even 5, was a nightmare, but DX8 is pretty easy to use.
The more significant reason is driver quality (from the hardware company), and the 3D-graphic card industry is so cutt-throat that even a momentary falter into, admittedly, a non-mainstream-for-games OS like Linux can be fatal. Of course, they COULD release enough specs to allow OS drivers... but there are trade-secret issues there (with actual hardware, that don't apply, in my mind, to software).
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
How well is OpenGL supported by the video card drivers? If it is slower or buggier then DirectX then people won't be so thrilled to use it. Remember non windows boxes are less then 10% of the market (Apple had 5% at the start of the year, I doubt Apple+Apple's growth+Linux+BSDs can top 10% -- if the PS2 or GameCube use OpenGL my 10% guess is wrong though).
Plus DirectX handles input, and some non-graphical output. And I think sound. As far as I know OpenGL only does drawing.
OpenGL is what Apple recommends using for 3D game on their platform (at least under OS X), but they have their own APIs for sound and input, and hopefully force feedback (and one would hope that to the extent that DirectX "got it right" Apple copied it). So OpenGL isn't dead, unfonturely it give MS an even bigger reason to fight it.
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.
1. DirectX is changing. It's updating, moving with the times, and incorporating new developments in graphics card technology in a standard way, there's features some cards don't support, but they're parts of directx, and they'll be on future hardware. On OpenGL, if you use the nvidia extensions, they're not going to be there on ati cards, even a few generations down the track when the same features are standard across platforms.
2. Since dx5, it's been a good environment. It took MS a while to get it right, but they're constantly updating it, which yes, means there's a continual learning curve, but that's what makes game programming the fun it is! OpenGL is controlled by comp scientists, DX by money, which means DX will always be quicker off the line with the features developers and customers want.
I know that MS makes it, and as a whole, MS is bad, but the company's tactics don't make the technology suck, and joe sixpack who wants to just go play unreal doesn't care if MS bundles ie to make his life easier or to kill netscape, cause it makes his life easier. There's one constant in life these days- people as a group, are cronically and terminally lazy. Most people view money less important than effort, and even their time less important than effort... Somebody would rather take 2 hours to do a 15 minute job if it makes it seem like less work to them.
</rant>
Send lawyers, guns, and money!
OpenGL 1.3 closes the gap quite a bit, but DirectX 8 still has a higher featureset and will gain more features sooner than OpenGL will.
Game programmers don't give a rat's ass about portability. All it has to do is run on their target platform at an acceptable speed.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
With XBox drawing near, and XBox's adoption of Direct** APIs - we can seriously expect to see this trend accelerate.
MS is providing a bridge, via XBox for PC games programmers to get their apps on a console. If the rumours that consoles are the sole future of gaming are correct - then we can expect to see our PC Game developers very happy to have this new area to sell to.
But, considering this, what does this say *REALLY* about M$ and its XBox? Arent they in fact cutting off PeeCee sellers from a market - the would-be-desktop-computer gamers market? Isnt M$ REALLY competing with its own customers in this case? With M$ focusing on realeasing a box themseleves - wont that mean decreased sales for their own customers?
I see M$ XBox as being its most obviously brazen move yet. I understand M$ has been into hardware for sometime, but brand-ed mice and keyboards arent at this level.
What does this have to with directX? It means that once again, M$ is using their weight in one market (pc gaming os) to move into another (console manufacture). I really wonder what Compaq, IBM and Micron think about this, wont this mean a drop in their sales of Electronics-boutique level machines?
Imagine for a moment, with Sony talking about making PS2 a Linux Computer (with HD, Keyboard, Mouse etc) wont this invite M$ to do the same? Will the XBox become a "Microsoft Desktop Computer"?
With PC developers looking at the XBox as an opportunity to expand their marketplace - you can bet they are not going to be too eager to use OpenGL and cut themselves off from the XBox-platform.
Just an observation here. I was in South Africa last year, working with some companies in the simulation/training market. Most of them are developing their apps for DirectX--OpenGL was not used much at all. When I asked why, I was told that the reason is that DirectX apps will run reliably on cheap Windows boxes, which is what they're using; OpenGL is seen as something running on high-end UNIX machines. I wonder how widespread this viewpoint is?
Some companies are doing things for linux gamers. Bioware is releasing Neverwinter Nights, which could arguably be the best rpg ever released, is going to be released for linux as well as windows, and most likely it will use opengl(is there another graphics api that does 3d in linux?). Nvidia is giving full OpenGL support in their chipsets. And let's not forget the guys at ID love opengl as well. Even if their numbers are few, there are people who still want to keep OpenGL alive, and they are pretty big names is the gaming industry.
Got Freedom?
Thinking?
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!
The modern games developer will use DirectX over OpenGL every time. Incidentally, the incredibly poor support for DirectX in Linux is one of the reasons it is failing in the games market.
Now try to make a 3d engine with the features of Alice or Anarchy Online in OpenGL with OpenGL.
Erm, Alice uses the Quake 3 engine, which is certainly using OpenGL.
Bioware's next game, Neverwinter Nights, will use OpenGL for cross platform compatability. (They will ship for Windoze, Mac, Linux, and BeOS, and all on the same CD to boot!) If the game is a success (and averyone expects it to be), then maybe this might turn a few heads in the gaming industry, and a more serious look at cross-platform gaming (and thus using OpenGL) might happen.....
You say that sheer volume proves it's easy. ASM on x86 isn't exactly the nicest thing. Or, do you _like_ being limited to 8 general purpose registers, and a crappy FPU stack?
If we go by sheer volume, x86 must be a freaking dream to write software for, and it must be some heavenly architecture!
I think some people are missing the point.
The big argument against DX is it only runs on windows. The same things that make windows awful for most things makes it superior for gaming. Windows has such an incredible boost for foreground applications (especially ME/98) that it makes it much easier for gaming..
How many times have you had an mp3 skip because something stupid is happening in the background on linux?? It's great that you can game or do multimedia on linux, but the fact is that what is the point of ramming the square peg into the round hole??
Ummm, almost everything in OpenGL is the same for different cards, and for different platforms. This is a huge advantage of OpenGL.
However, when a graphic chip company creates a new functionality, it usually creates its own OpenGL extension. But this will evetually (if it succeeds, that is) become a standard extension (i.e. ARB extension) and later become part of the OpenGL standard. Many games don't even use some of these features, because the market share of the hardware supporting them isn't large enough yet. (Though gamers are fast to upgrade their hardware.)
Also, don't forget that you have to write hardware-specific code even with DirectX, because you really don't want DirectX to use the software rendering for you. You'll have to check if a certain feature is hardware supported, and you usually need a slightly different algorithm in case it's not.
I think the main reason for DirectX's success is that most games are Windows only anyway, and that DirectX is more than Direct3D. If you write a Windows game, you'll have to use DirectInput, DirectSound etc. anyway, because it's the only standard API offering input, sound etc. functionality for games on the Windows platform. But if you have to use DirectX anyway, why not use all of it?
Yet another reason might be the object-orientation hype that's going on. Obejct orientation is marketed as an extra feature, not as a design choice. (Whether the design choice is justified I don't know, I'm not a 3D developer, though I've played around with OpenGL a bit.)
Sig (appended to the end of comments I post, 54 chars)
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
It should be OpenGL vs. Direct3D
DirectX is an entire API for 2dD graphics, sound, input, and probably a dozen others (DirectNetwork! DirectSideScroller! etc).
Direct3D is what sucked so much. OpenGL would've been the obvious replacement. The industry even petitioned Microsoft to drop Direct3D in favor of OpenGL. They of course refused. They even had some marketing chick come out and try to say that OpenGL was inferior because of "procedural overhead" (as OpenGL is a procedural API).
So, Direct3D slowly gets better, everyone else suffers because of Microsoft's bullshit.
OpenGL plus OpenAL plus SDL on Linux is probably enough to make a great game.
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.
It must do one, and only one thing:
Work better than Direct3D
It is that simple. As many people have pointed out DirectX runs on 80%-90% of all home pc, so switching to Open GL to capture more marketshare is only feasible if the cost of development are the same. The problem is: they are not.
Microsoft has poured unknown millions into the development of DirectX and has produced a universal set of API's that work on any video hardware. Until OpenGL or MesaGL etc. can function out of the box with the same (relative) ease development houses will stick with DirectX.
In simple economic terms, DirectX and OpenGL are not close substitutes. One is well known entrenched and universally supported, the competition resides more on the margins and has universal compatability problems. And these compatability/extension issues drive up the price of developing with OpenGL so it becomes an even less attractive substitute.
The OpenGL/Direct3D battle is no different from the Linux/Windows or IIS/Apache or any other open source/proprietary battle. It is not won with principle, or good intentions, but with results. If people want to see OpenGL succeed make it better, and cheaper to develop with than the proprietary offering.
Comments should be like skirts. Short enough to keep your attention, but long enough to cover the subject
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 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...
> 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