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?
Everything in OpenGL is different for different cards. If you code in DirectX, at least it will work on all cards, even if only on Windows (so far). If something doesn't work right with a card in directx, it's the card driver's problem. It's universal in the Windows world.
OpenGL is freaking amazing. I love it. Unfortunately, card makers want to write OpenGL extentions specifically for thier cards so you have to have aset of code to do the same thing for each card.
When will people come together to agree on non-MS-specific standards? Probably never. Maybe we should support
-EvilMonkeyNinja
Mild Mannered Host by Day
Wild Hammered Programmer by Night
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
To be competitive with other upcoming games, a game must be written specifically for one platform anyway. Every decent game that's come out has taken a month or two to port to another platform.
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.You're not going to find many altruistic coders or designers working for companies that put boxed games on the shelves at Egghead or Best Buy (sidenote, that last is most definitely an oxymoron. But I digress.)...game programmers who work for big software houses are in it for the bucks, and the only OS/platform that they see as paying the bills is WinXX. So they write for WinXX, and right now, that means primarily using DX APIs. If there were a bigger demand (read: potential revenue stream) for other platforms and OSs, OpenGL would probably make more sense to them...and I'm willing to bet my lunch that the games that are still OpenGL-capable have also been ported to the Mac platform (not that I've looked, since I don't own a Mac, ergo don't need to examine the offerings for it).
In short...DX makes more economic sense, simplicity of coding notwithstanding.
Just my two cents' worth...save up the change for a root beer float or something.
All the world's an analog stage, and digital circuits play only bit parts.
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.
And what if this is the result of a gap? Well, two-three years ago we would see people running mixed environments and Linux was barely desktop ready. Today there are already thousands of users who use exclusively and solely Linux, BSD and even other *NIX flavours as purely desktop systems. Interesting to note that today the only reason many acquaintances give as a reason to keep Windows, is the number of games that still lives in this OS. But this is not a reason to say "OpenGL suxx". The fact is that many game producers have a vary long DOS/Windows tradition and it is hard and risky to change lines. Let's note Loki's problems and the state of world economy for this...
However, in *NIX, a small game boom is happening. You may look at freshmeat and note that there is a steadly rising of several computer games during this Summer. Truly they cannot be compared with Windows games but, still, they are a markup of changing times. Windows games also started with some quite silly puzzles, card games and small shot'em-ups. Meanwhile, some of these games are made under OpenGl and don't look quite bad. And while some have a Windows port, the core of development is clearly made under the *NIX base.
It seems to me that this is due to the fact that the critical segment of developers, with "mixed interests", has already changed lines and, now,we are seeing Linux/*NIX detaching from its M$ roots. Meanwhile, under Windows, there is a concentration of "purists" who barely need of any OpenGLs or Mesas for work. So, it seems that we are only seeing the appearence of a developer gap.
The question should not be "why aren't game developers using it?" but "why aren't the video card makers supporting it?"
And that, dear friends, is where market power comes into play, and the one with the power in this market is Microsoft.
+1 Insightful, -1 Troll. What can I say, I'm an Insightful Troll.
What are the advantages to using OpenGL? If you're trying to capture about 10% of the remaining market for your product, and having to sacrifice the quality of the product to do it, you're going to lose a proportionally larger customer base from the Windows users than from the Unix/Linux/OSX users.
Porting to other OSes is going to cost time and money. Sure, having OpenGL as your 3D API makes that aspect easy, but what about sound, input devices and such?
I haven't seen a single game that uses only the standard OpenGL API that could match a DirectX game. Who drives the OpenGL spec? Who drives the DirectX spec?
OpenGL is a nice, clean API (except for so-called "extensions" by video card manufacturers). DirectX is hairy to work with (at least when I last looked at it... DX5) but, it _works_ for games. If I'm writing a serious application (visual modeling, CAD/CAE, etc), then I'd choose OpenGL. If I'm writing the newest FPS, then I'm going with DirectX.
Give them an inch and they'll take a foot. Much more than that, you won't have a leg to stand on.
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!
The idea that games programs are 3d therefore the game designers should be flocking to "Open" GL is ridiculous. In the first place OpenGL is still effectively controlled by SGI so the only difference between 'Open'GL and DirectX is that one is developed by a dying company and the other is developed by a highly profitable one.
Giving OpenGL over to a committee is not a solution either. The hardware vendors are not going to wait for a standard to be established before they sell the hardware to expoit it.
Benchmarks of OpenGL vs DirectX are almost certainly meaningless. Even if someone was to implement a large complex application in both the performance is going to be dominated by the performance of the drivers. The idea that the hardware manufacturers are going to spend more time and effort optimizing their OpenGL drivers than the DirectX drivers most of the games will be played on is pretty naive.
There are some MacLoonies out there who believe that their machines are still faster than PCs, it was true five years ago so it must still be true, after all they have these pretty case colors.
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
OpenGL will be only for professional use while DirectX becomes the standard for games and computer scientists.
i like how you don't even attempt to rebut his charges and just resort to ad hominem attacks.
it just makes you look like more of a jackass
Cat meet Kettle. Kettle, cat.
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??
Why do people develop only for Microsoft-specific platforms? Heres your answer right here.
Liberty in your lifetime
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
Games were a major part of Microsoft's rise to power in the first place. While there may be little use for the Itanium in a desktop now, a new game title that took advantage of the power of that chip would shorten the time until the chip hits the desktop mainstream. And while M$ may be planning a realease of Whistler for the new chip, I'm sure DX is nowhere in sight for it. This is an opportunity to take back a major part of M$'s allure. Any takers?
Nvidia even makes their hardware talk to DirectX. That means games programed in DirectX will probably get the most out of that graphics boards, and considering nVidias marketshare that's not a bad idea. It gets even better if other chipset manufacturers do that too. And let's be honest, even most linux-folks out there have a w98 boot option if they want to play games not available for Linux. So marketshare is even less of an argument.
The problem with all this is, that DirectX gives Microsoft yet another lever to dominate multimedia formats and applications, for example formats for animated content (let's see if flash-plugins and shockwave go the way of netscape and realplayer in the near future) and this is big: every advertiseing company wants that, guess what they'd pay for development kits, if the stuff is guaranteed to display properly in IE.
"By the way if anyone here is in advertising or marketing... kill yourself." -- Bill Hicks
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.
If you want an open and portable equivalent of Direct X (not only Direct 3D), go for SDL.
SDL supports 2D graphics, but also 3D (through OpenGL wrappers), CD-Rom operations, sound, network, load/save of bitmap formats, joystick, etc. And it can renders on windows, X11, svgalib, GGI, AA, BeOS, etc.
SDL is very easy to program, and everything is designed in a very consistent way.
{{.sig}}
I'm not a hardware wonk, but it seems to me that there are hardware issues too. I'm typing this on my work system, which has a fancy Intergraphics card. God know why the guy I inherited it from ordered it -- we don't do CAD here. Anyway, the card has no issues with OpenGL software, but I can't run DirectX apps now matter how I fiddle with the drivers. Not a big deal for me -- shouldn't run Age of Empire II at work anyway -- but just a little strange.
Ye gods, that would rock. I've a whole library of games that I love, and only have options for Glide and Software.
Now, obviously it's not going to be a speed up, because the joy of Glide was that it was an abstraction of the card itself.
Vintage computer games and RPG books available. Email me if you're interested.
Since I do not program games but do play them I will throw in my 2 cents. Other people may not agree, good for them. This is only for FPS games. I don't play RPG or RTS so I can't say how it is in those genre's.
It's hard to explain these things without being vague so bear with me.
First, the mouse movement in every d3d game I have played has sucked, at least for me. The only way I can explain it is that it feels sloppy.
Second, d3d games always look glossy or shiny. This is another point that is hard to explain. I really with I could explain this in better detail as this is the problem I have always hated this. It looks like everything has a nice shiny clear coat finish, if thats any better explanation.
Maybe opengl is going away in games and that makes me sad. If my only choice is the sloppy mouse and shiny graphics in d3d then I would probably only play ones that are very heavy on storyline, which narrows it down to 1 or 2. I wouldn't play any mp deathmatch, ctf, etc.
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.
To a certain extent, this is true. MS supplies libraries that handle the really high level stuff, like loading texture maps from external files. With OpenGL, you may have to do this by hand-- although programming a .tga or .rgb texture loading is pretty simple-- just a few hours spent with the "Encyclopedia of Graphics Formats" and good code desgin can produce a good reusable library...
On the other hand, this technique may not appeal to the programmer who uses "/*insert custom code here*/" type libaries (MFC, etc).
GLUT handles lot of stuff, although extending the UI can be painful.
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
OpenGL is used for scientific modeling, film fx, and tons of other things. DX ( D3D ) is only good for one thing and that's *PC games. PC games are nothing, since they can't even compete with consoles. DX on Xbox is also a moot point.
The point then? The point is GL will always be what modelers and the R&D depts will use, because it's a stable and modular API.
As for GL games? If you have a game based on GL, it will support more card features months before DX. However you can't use a cookie cutter engine like lilthtech and the like. There sure are more DX games, but they're mostly swill to be honest.
Would you rather have a dozen lithtech based games or something based on UT, Q3A, or etc?
-------
Please remember when you post the PC gaming market has nothing to do with GL's "life and death".
May the mongoose save your soul!
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
Its true that XBox is giving DirectX a second platform, but OpenGL is doing well, and the preferred 3D API everywhere but WinWhatever (the Mac being a notable example).
There is intensive ongoing work on both APIs, and don't think for a minute that Direct3D would be what it is today without OpenGL driving it.
By the way, Direct3D is precisely nowhere in the higher end 3D marketplace...games are by no means the only 3D application. I doubt they're even the major money maker - I suspect CAD/CAM has that honor.
We'll see how things look going forward...I expect OpenGL to be around for a good, long time.
Just take a look at the Official OpenGL Website to get a feel for how lively the OpenGL world is...the laptop version of the NVIDIA Quadro2 professional GPU looks pretty sweet!
186,282 mi/s...not just a good idea, its the law.
Galileo: "The Earth revolves around the Sun!"
Score: -1 100% Flamebait
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'
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 =)
1. WHQL has compliance tests for D3D implementations too. And OGL compliance tests only cover what's in the standard, which doesn't help much if you are relying a lot on extensions that haven't made it into the standard yet.
3. Querying D3D capabilities bits is fundamentally no different than querying for support of GL extensions.
4. Card manufacturers have offered APIs for using their own special (non-D3D supported) features in D3D, just as they have written their own GL extensions. And basically everything you wrote about vendors extending GL happens in the D3D world too. The only real difference is that MS tries to get the vendors to standardize as much as possible by keeping the extensions unofficial and updating the spec frequently. The OGL ARB moves very slowly, so competing extensions for doing the same thing hang around too long before being reconciled. Developers generally don't consider this to be a good thing.
There's a lot of history in the D3D vs. OGL war. D3D didn't really need to exist in the first place, it was only created to lock game developers into the Windows platform and hurt Mac gaming. And in the earlier versions, it was technically inferior to GL as well. I agree that life would be better if D3D was never created.
But it *was* created, it *has* improved greatly, and right now it's a pretty damn fine API.
This is exactly what John Carmack and Chris Hecker predicted would happen way back when DirectX 3 (the first with Direct3D) came out.
They predicted Microsoft would pay developers to use the crap they put out, and slowly improve it by copying OpenGL. This finally leaves them with a functionaly clone of OpenGL with a propritary interface solely under their control.
And surprise surprise, that is exactly what happened, and us game developers had to suffer through DirectX 3, 5, and 6 before it really stopped sucking, when we could have been using the end product immediately back in 1998!
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...
Half-life is a hack of the Quake2 engine. It uses all of john carmacks old Q2 graphics code.
Carmack is an OpenGL programmer. It is his area of special expertise. DirectX support was added on later. That is why half life runs better in openGL.
Because of M$'s lock on the OEMs, you had to pay "the full price" for OS/2. The price for Windows is not immediatly obvious because it was rolled into the cost of the system. Sadly, those of us who chose OS/2 still had to pay Microsoft for Windows(via system purchase) as well as pay for OS/2. The Microsoft Tax was the driving force behind my learning to build my second(and later) systems. Even then, I still had to pay the M$ Tax when I bought a laptop - rather hard to build one of those from scratch.
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.
Does the the new OpenGL 1.3 spec support pixel and vertex shaders?
If those features are missing from the new OpenGL spec, then we are in trouble and the OpenGL board needs to act to remedy this situation.
To win against Microsoft, we need to have their be NOTHING useful that Microsoft products do that ours CAN'T. We MIGHT be able to get over the market share/monopoly/compatibility lock-in because our product is free (as in free speech and free beer), and does some things better. But if the pro-Microsoft forces can point to a TECHNICAL INFERIORITY of our product we are doomed.
Just because it CAN be done, doesn't mean it should!
Most Game developers won't use OpenGL due to the poor driver support. It just adds up to more tech support calls.
The fact that it won't sell on Linux is hardly an issue. It's just not cost-effective to port to Linux anyway.
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...
Why ask? You know the answers.. Compatiblity with the only OS in the demographic, stable drivers (ever tried Massiah? Driver nightmares thanks to OpenGL)..
Boo hoo, the world doesn't make sense.. Cope and move on..
No, it does not. It uses a faintly similar API, but it is not OpenGL.
OpenGL IS the API for gaming consoles. Its what the PS2, N64, Dreamcast and PSOne use. Its also what the MacOS, Unix, and every Windows CAD program in existence uses.
:)
So yeah, I think its got cross platform down pat.
The big open question at the moment seems to be whether the general-purpose PC is dead as a gaming platform. The royalty-based revenue stream from consoles is more attractive to platform developers, the configuration consistency of consoles is more attractive to software developers and support organizations and publishers, the hardware and software support for intellectual property protection is better on consoles, and the higher volume of game sales on consoles is more attractive to nearly everyone in the supply chain. Then there are the "we want to own everything from the character concepts to the titles to the delivery platform" business strategies from folks like Sony.
It's possible that the PC will remain a delivery platform for traditional scientific/technical/business applications, but not for entertainment applications. In that case OpenGL would continue to play a role for the "professional" apps even though it might not play a role for the "consumer" apps (except possibly on MacOS X and Linux).
I'm also curious to see how D3D evolves if XBox succeeds. Does the PC become the leading-edge development platform, with console designs occasionally spinning off from the current 3D environment on the PC? Or does D3D on the PC stabilize, getting major revisions only when new console hardware justifies a fresh release?
There are many other things to consider. The next couple of years should be interesting.
I think it's only been established that Id didn't do well with the Linux gaming market (Admittedly, that's NOT a good thing) and it's been pointed out repeatedly by myself and others what went down with the sales of Quake III:Arena- and it wasn't because you did a bad game or did bad by us. (On the contrary, you and the great people at Id given us all KINDS of things- including the initial 3D support for the ATI RagePRO, etc.)
When you lag the release of the game by a bit, offer a way for Linux users to buy the Windows version and then "convert" it to the Linux version, and have a situation of mixed quality support of 3D (Some of the blame can be laid at the community's feet for that- some of it can be laid SQUARELY at the feet of the chip vendors...) sales are going to be most certainly in the toilet. One has to wonder how many of the sales for the Windows SKU were really impatient Linux users. You're never going to know- because there's no way for you, or any of the other management there at Id to know for sure because you didn't have a framework for keeping track of the "conversions" in place (Should you have? I'm not so bold as to say you should have- but it would have helped to know for certain that the Linux market was a washout at that time or not. I tried to buy it at the rollout for Linux, to no avail- and in Dallas, one of the larger markets...)
I don't think anybody would blame you for not seeing Q3A on Linux as a success or viable for gaming- I sure wouldn't and I completely understand the position you're taking on this. I just don't see it the way you are because I'm seeing different data points.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
Anyone remember the day SGI sold their soul to M$ if an attempt to ensure the survival of OpenGL with Fahrenheit.
There is folly and foolishness on the one side, and daring and calculation on the other. - Admiral Pellew, Hornblower
I find your reply most amusing, you call me a troll and you post as an anonymous coward. And apparently someone hasn't learnt the fine art of using a mouse or block delete and is stuck with the intelligence of only knowing how to use the backspace key to delete many characters of text. I suggest that next time you want to let the shit out of your mouth you at least have the courage to post as a real user...
And for your information, I was both an OS/2 user and developer. It was a great OS, much better than windows at the time, ran applications faster than windows, and I actually liked to develop for it. It was not horrifically overpriced, and the problem was one of compatibility, not price. It's a true shame what happened to it. But 'tis the way of things I guess...
If God gave us curiosity
For the past few generations Nvidia and MS have colluded to make sure that DX supprots the latest whiz bang featrues of NVidia cards.
At Quakecon a few weeks ago John Carmack took Micrsoft to task for putting thinly disguised Nvidia specific operations in DX8.
Fact of the matter though is that NVidia dominates the game-video car space and MS dominates the OS space, and they work togetehr to reinforce that lock.
It should be pointed out that OpenGL shouldn't be compared directly with DirectX. DirectX is many things besides Direct3D - DirectInput, DirectSound, DirectDraw, DirectPlay (networking)... Direct3D is just one (albeit the most important for many games) component of the whole. John Carmack (to my knowledge) never said DirectX sucked, just Direct3D. Quake used DirectInput and DirectSound (and DirectDraw if you were using software) and I believe the following Quake games do as well.
If you want to talk about the whole package, you sohuld compare DirectX with something like SDL, which does try to supply the other components like input and sound (and does use OpenGL). Of course, as a whole, SDL doesn't have nearly the pedigree and industry support as OpenGL does.
So if you want to take about OpenGL, compare with Direct3D and keep your terms straight.
And all this raises a point - Direct3D is part of an entire games/multimedia programming environment. Most game companies aren't just looking at the 3d but looking at the entire suite for all the ways their game must interact with the operating system, and once you start using some of them (DirectInput, DirectSound), why not make things consistant and easier by using their 3d component as well?
To my knowledge, John Carma
No, the incredibly low number of desktops is why Linux is a small gaming market. D'uh?
Basically, DirectX == Windows == locked in to Microsoft.
DirectX started as a poor copy of OpenGL and was developed into something reasonably fast but still up to the eyebrows in gotchas. Pretty typical Microsoft, really. Make Windows 3 incompatible with DR-DOS instead of better at what it does, make Word incompatible with every known document standard instead of better at what they do, make VMS into a buggy GUI support layer instead of leaving it as a low-bug, secure and efficient OS then layering the GUI onto it, make DirectX incompatible with OpenGL and X (why call it DirectX anyway? X without networking? That's a feature, is it?) instead of adopting OpenGL and driving the standard somewhere better.
Small mercy, in a way, M$ might have enforced 8.3 object names or something. But one reason for being different is to avoid direct comparisons. Plugin card drivers like XFree86v4 uses would clearly show DirectX up for the convoluted dog that it is.
Actually, they'd benefit quite a bit from a good dose of ivory tower purism. As well as being portable, they'd be less buggy. Might be faster, too, if they were designed around good software principles, rather than to take advantage of or avoid specific features and bugs in DirectX.
Got time? Spend some of it coding or testing
DirectX is so hard to program in, so clunky to use...
Although I'm a fan of OpenGL, it's way to harsh to say that DirectX is clunky. It's actually quite brilliant (albeit some quirks), hence why so many predict that a lot of developers will LOVE developing for the X-BOX. One other thing to consider about DirectX, is that it's an all encompassing API which handles not only 3D accelorators, but 2D display, input devices, 3D and standard sound, and so on.
There is no longer anything that can be done with computers that is nontrivial and clearly legal. -- Paul Phillips
...it's gunna be cool. In fact, it already is cool - just not stable enough yet.
Microsoft are to real-time graphics what Macdonalds are to food. If instead of doing their own thing they'd got behind OpenGL and pushed instead of telling lies about its performance, OpenML would have been here many years ago.
Got time? Spend some of it coding or testing
What book did you get this OpenGL example from ?
A book/article about DirectX perhaps..
OpenGL is pretty clean IMHO. If you want something simpler, or scene-graph based, use OpenInventor.
http://rareformnewmedia.com/
Early versions of D3D (pre DX8) integrated better with DD then OpenGL did.
;-(
A lot of game developers dropped the ball on this. And it didn't help that M$ shoved D3D down us game programmers throats whether we wanted it or not (shoddy OpenGL MCD support, very bad DD integration, etc)
That's the REAL reason -- commonplacy with developers. Too many didn't care enough about OpenGL.
Just a thought.
RFC2119
When all of the hooplah about DirectX vs. OpenGL was a hot topic back around 1997, DirectX was a much different beast. It has gone through three major revisions since then (versions 6, 7, and 8). I'm still dumbfounded that a simple SDK can be a hundred megabyte download, but, that aside, DirectX is much simpler to use than it was even a few years ago. The big issue in 1997--execute buffers--haven't been necessary since 1998. The other big issue--horribly complex initialization code--was addressed in DirectX 8.
Hello, for everyone saying "The problem with OpenGL is that it doesn't include a cross platform abstraction for sound and input", you NEED to go check out The Simple DirectMedia Layer. SDL integrates with OpenGL and provides cross-platform (essentially it wraps DirectX on Win32 and Xlib/XDGA on *nix) access to mouse, joystick, sound, etc.
And where was Direct3D at this time? Was Direct3D even usable? Again, why re-invent the wheel with Direct3D when OpenGL was available?
>>>>
I think you're relying too much on hindsight. I don't think that OpenGL was even an option at the time. GL was a heavyweight API that ran on heavyweight hardware and required complex drivers. It just wasn't suited for gaming in the days of Virge. Also, OpenGL drivers were (and still are) very complex to develop. Even today, many vendors don't have stable OpenGL drivers. Thus, the chances of the consumer hardware market accepting GL were pretty small.
Ok, with this reasoning we can re-invent many APIs, and then when our new API after several years doesn't suck any longer compared to what was already available before, we can conclude that the effort was worth it because the older API "was" better...
What do we gain here?
>>>>>>>>>>>>
D3D and OpenGL, though they both do 3D, have two different paradigms. OpenGL is clean and abstract, while D3D is down and dirty. D3D was suited to the consumer level hardware of the time, and OpenGL was suited to the pro level hardware of the time. While it could be argued that both APIs have moved closer together (D3D has become more abstract because new hardware accelerates more parts of the pipeline, and OpenGL has started to expose more low-level functionality through extensions), there was no way anyone could have predicted how hardware would evolve.
I believe the conclusion was that it may have been a good choice for Sweeney, short term. But bad for the gaming community as a whole in the long run, due to fragmentation.
>>>>>
What fragmentation? Most people use Windows and most games use D3D! Where's this fragmentation you speak of? If some developers chose to use OpenGL, that's their option. It doesn't really hurt the consumer any. The underlying API is more or less invisible, unlike the disparity between, say, GNOME and KDE...
But that goes for all developers that chose Direct3D at the time. Besides, Unreal's Direct3D performance hasn't exactly been stellar throughout the history. Had more developers gone with OpenGL, hardware manufacturers would have focused on OpenGL instead of Direct3D. I believe it was an important breakpoint for the success of Direct3D when Epic chose it.
>>>>>>>>>..
While that is true to a certain extent, I belive that can't explain all of why D3D has been successful. Remember, Carmack's engine powers many of the 'A' titles out there, and that keeps OpenGL a force. I think hardware manufacturers just chose to go with D3D because it is easier for them to implement, and developers chose it because it had more stable (consumer-level) drivers and MS is more responsive to the needs of game developers than is the ARB.
Yes, gamers mostly run Windows/D3D, but I believe that fact was the issue up for debate and questioning? Windows users could run OpenGL without sacrificing any gaming experience.
>>>>>>>
Again, for the above reasons, this is not the case. When D3D was created, using OpenGL would have been a major sacrifice for gamers.
The OS market may be another issue, but the fact that Direct3D limits the choice of platform (and freedom of people), is highly related to this issue.
>>>>>>
Gamer's really don't care about freedom. They want their OS running stably (Win2K does this to a large degree) and their games running smoothly. Like communists, the OSS community doesn't always understand that politics is not the sole factor in everything.
Define compatible? I believe being cross-platform and being used for other stuff than gaming is being compatible....
>>>>>>>
Compatible in the practical sense. There are more gamers who own Matrox cards than gamers who run Linux. Being more comptible with Matrox's crappy GL drivers (ie. using their D3D drivers instead) is more important than being cross-platform.
How many vendors are there today...? I bet most people use Nvidia hardware and they have great OpenGL-drivers.
>>>>>>
And you'd be wrong. Although NVIDIA is #1 in sales, its going to take a lot before ATI's 22 million chips go out of circulation. Even S3, Matrox, and PowerVR are still a factor. These cards don't have good OpenGL drivers, but they are still a large part of the gaming market.
And I haven't heard that Direct3D has more features, taking OpenGL's modularity into account. Stick to the facts!
>>>>>>>>>
Take a look at an OpenGL 1.2 book, then take a look at a D3D book. There are tons of features in D3D that (if they appear at all) only appear as extensions to OpenGL. Since these extensions are often propriatory to particular vendors, it causes headaches to developers who have to deal with a fragmented API. MS thought of making a D3D extension mechanism to relive themselves of the burden of haivng to release new versions of D3D so often. Game developers were not keen on the idea, and blocked it from happening. Extensions are great for OpenGL's original market (slow evolving pro hardware), but aren't the right solution for a quickly changing consumer hadware market.
And read John Carmack's posting for his view on DirectX-releases if you believe OpenGL extensions are so bad...
>>>>>>
Actually, he points out that ATI and NVIDIA have diverged on the extensions point. Unless ATI and NVIDIA suddenly become the only forces in the graphics industry (a plausible, but undesirable scenario) this divergance will become worse. I don't really trust the good natures of the hardware developers to work together and adopt one another's extensions. The days of Glide, MeTaL, PowerSGL, and other propriatory APIs are still to fresh in my mind...
A deep unwavering belief is a sure sign you're missing something...