What is Happening with OpenGL? 576
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?
the reason is... (Score:2, Insightful)
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
Re:the reason is... (Score:4, Informative)
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.
Re:the reason is... (Score:2, Interesting)
You're a twit, and still a worm compared to the guys who signed this [d6.com].
My graphics background is stale and academic, so I'm not too familiar with the differences between the new cards or the current state of OpenGL vs. Direct3d. If you may humble yourself I have a question.
Riddle me this: Why would anyone write a game dependant on the features of a particular card? Even if Direct3d can emulate them in software, woudln't that kill the performance of the game?
I suspect the popularity of Direct3d has little to do with advanced features and everything to do with the fact that it is a de facto Microsoft standard. Why bother learning OpenGL when you're going to be stuck using Direct3d anyway. It will only raise your support costs to use a non-native API that is decidely hostile to Microsoft's agenda.
Re:the reason is... (Score:3, Interesting)
Erm, Alice uses the Quake 3 engine, which is certainly using OpenGL.
Re:the reason is... (Score:4, Informative)
-Gav
--
Gavriel State, CEO
TransGaming Technologies Inc.
gav@transgaming.com
Re:the reason is... (Score:2, Insightful)
To use your own words, nice with the almost-come-backs.
-swc
Re:the reason is... (Score:2, Informative)
Please do not refer to the library as MesaGL (for legal reasons). It's just
Mesa or The Mesa 3-D graphics library.
OpenGL and DirectX in simulation apps (Score:3, Interesting)
Re:OpenGL and DirectX in simulation apps (Score:3, Insightful)
a co-worker of mine has a buddy that does simulations of large ceramic ovens. They used OpenGL for visualization on SGI machines for over 15 years. When they realised they needed to upgrade thier system they were faced with 2 choises: a linux cluster with OpenGL (MesaGL) or a Windows cluster with DirectX. After a demo on of each on identical hardware, they got 2x the performance on the Linux cluster. They went from starting a simulation in the morning and getting the results the next morning to starting one before lunch and having it ready before they got back
If OpenGL will do what you expect it to be needed to do, use it on Linux. It's awsome. It will rock your world (especially on 2.4 linux SMP machines)
Re:OpenGL and DirectX in simulation apps (Score:3, Informative)
Direct3D means you basically have to use MS VC++ and COM on windows. I know that, in theory, you can use the COM objects from other languages with COM bindings, but that's painful.
Re:OpenGL and DirectX in simulation apps (Score:2, Informative)
Actually, you can use CodeWarrior to write DX code. I know a bunch of people who do.
As for the whole DX OpenGL thing, After watching my co-worker play Max Payne for 4 hours, Direct3D has actually become a very good looking way of presenting 3d graphics. And at points, i find it to be better than OpenGL, much cooler effects, and much smoother, but that's just me. Anyway, most probably won't read this. Yay moderation!!
Re:OpenGL and DirectX in simulation apps (Score:2, Informative)
Was it by any chance this company: http://www.5dt.com/ [5dt.com]? Chances are it was .. there aren't more than a small handful of companies here doing this line of work. Anyway, I work for 5DT, so perhaps I could offer a little more background. We do mostly use DirectX, but we have developed a Software Development Kit for our own use that provides an abstraction of a generic 3D renderer. Behind this abstraction we have both Direct3D and OpenGL implementations. This allows our software to run using both OpenGL and Direct3D. The main reasons we have done this is (a) possible portability in future, should we need to sell systems using OpenGL, (b) Direct3D programming is clunky and difficult, and it is counter-productive if most of our programmers have to learn it, and lastly (c) by supporting both, we ensure the process has resulted in a "good abstraction". Using such an abstraction provides for easier/faster learning curves and more stable, robust software. So we now only really need one programmer dedicated to knowing all the ins and outs of Direct3D, the other programmers can focus more on the important stuff - the application development. Creating this SDK has allowed us to have much faster application development times, as well as having more robust software.
In the past, our OpenGL support lagged a little behind the Direct3D support - previous iterations of our software were Direct3D only, and the main reason in the beginning for this was a decision to try stick to Microsoft standards wherever possible (trust me, this was not my decision :) (See my website for my own opinion of DirectX) Anyway, our OpenGL support is now on about the same level as the Direct3D support, so all of our new applications work interchangable with both.
From the perspective of our clients, most of them couldn't be bothered if the software uses OpenGL or Direct3D - they just want the software to work. From a performance perspective, we've found that both OpenGL and Direct3D are extremely similar, there is no real advantage for clients to use any particular one. Interestingly enough though, when using dynamic texture techniques (procedural textures / texture caching), we've found that on Windows2000, Direct3D has some horrible performance problems (becomes very jerky), while OpenGL remains smooth. We've never had clients that insisted on one over the other (OpenGL/D3D) though.
We also use other components of DirectX for input and sound. For networking we use sockets (DirectPlay is a waste of time, tried it), although for that too we have our own abstraction layers, thus allowing our software to be more potentially cross-platform, should a client require a different platform. Pretty much all our clients up until now have used Windows.
D3D is technically in the lead, but using GL extensions makes up for this.
Its true, DirectX will be run reliably on cheap Windows boxes. But so will OpenGL. We primarily use nVidia cards, on which both are supported. However, this wasn't the case when we first made the decisions - when we first made the decisions to go with Direct3D, mainstream 3D acceleration had only just started to take off, and the future of OpenGL looked a little wobbly at that stage - acceleration support for OpenGL on mainstream cards was almost non-existent in the beginning, while most card manufacturers *were* getting D3D support. This was the main reason for the decision back then. This reasoning is no longer true, generally support for GL and D3D are very similar, but our software is anyway now structured such that both are as easy to use. One other main reason to focus on D3D? Its "safer" - Microsoft is most likely to be around ten years from now. The future of OpenGL (and of SGI itself) has looked a little wobbly in the past, and although better now, still isn't as assured).
Re:the reason is... (Score:3, Interesting)
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.)
Re:the reason is... (Score:3, Informative)
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)
Nice FUD of your own (Score:2, Interesting)
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.
Re:the reason is... uh-uh (Score:5, Interesting)
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 =)
Isn't it obvious? (Score:5, Insightful)
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).
Re:Isn't it obvious? (Score:2, Insightful)
But those who make the decisions don't do the programming, in general?
Re:Isn't it obvious? (Score:2, Informative)
DirectX's networking protocol is pure crap. It is not client/server so both machines must be able to accept incoming connections. If you're behind a firewall you have to open about a hundred ports to get it to work and if you have any kind of NAT/sharing device you can only have ONE machine able to play games over the net.
Fortunately most developers have realized this and code their own networking code.
Re:Isn't it obvious? (Score:3, Informative)
Um....yeah, volum also brought us x86 (Score:3, Insightful)
If we go by sheer volume, x86 must be a freaking dream to write software for, and it must be some heavenly architecture!
Re:Um....yeah, volum also brought us x86 (Score:2)
The point of the post I responded to tried to claim that volume implied great quality, which it does not. If it did, then betamax would VHS is superior.
Of course, in cases of x86, and VHS, they won out to strong user bases, and marketing (and in the case of x86, very strong engineering to get around some of the issues). I'm not saying DX is crap. I was saying that the post that got a high moderating did nothing to prove the claim.
Actually, VHS didn't win because of marketing. They won because the recording length of the tapes was longer, while sacrificing image quality. Ends up that people wanted to be able to record more data, over losing 1/2 of the resolution of the signal, and this is why Betamax died.
Simon
Re:Um....yeah, volum also brought us x86 (Score:2)
Re:Um....yeah, volum also brought us x86 (Score:2)
Then there's the fact the Microsoft almost never redoes anything from scratch, which also leads me to believe that nothing has really changed.
Re:Isn't it obvious? (Score:2, Insightful)
This is slashdot, nothing's ever obvious (look back at some of the past "ask slashdot"'s).
This is slashdot, everything is an anti-linux conspiracy.
Best tool for the best job, that's directX on windows for gaming. Period. Maybe someday that will change, but not any time soon.
Compatibility (Score:2)
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.
For OpenGL to succeed... (Score:4, Insightful)
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.
Re:Not that klunky any more with DX8 (Score:2, Insightful)
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!
Re:Isn't it obvious? (Score:3, Interesting)
There are lots of things that Linux absolutely blows Windows away at. Gaming isn't one of them.
Re:Isn't it obvious? (Score:2)
No, it's because you can guarantee that someone has a DirectX-supporting graphics card. You can't guarantee that someone has an OpenGL-supporting graphics card. Also, Direct3D is easier to program on Windows than OpenGL. (IMHO)
Simon
Re:Isn't it obvious? (Score:2)
No, they stopped providing a software-rendered version of OpenGL. Graphics card vendors currently *do* support OpenGL, regardless of Microsoft's stance on it, so I'd love to know where you get the idea that they were 'forced'.
ATI provide OpenGL drivers.
nVidia provide OpenGL drivers.
However, there's lots of cheap cards that don't.
Simon
Drivers and improving releases (Score:4, Interesting)
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).
Re:Drivers and improving releases (Score:2, Interesting)
It's not anti-MS FUD, the guy just wants to know why everybody limits the portability, and therefore possible marketshare, of their games by using platform-limiting products like DirectX. If you have a choice between something portable and forward-thinking, or something tied strongly to one system (even a very widely-used system), the intelligent thing would be to leave all possibilities open and not get tied down yourselves, since it doesn't affect your sales to the larger group and serves the smaller group better as well.
And what's wrong with wanting games on Linux? Developers could be a lot more Linux-friendly simply by using tools which *include*, rather than *exclude*, this rapidly growing market. In my mind, game developers should start using cross-platform tools now, to position themselves for the day when Linux is a major player in the gaming market, even if it's only on the Sony Playstation with the Linux HD addon. Otherwise, we'll have coders who don't know anything but DirectX, and therefore prefer DirectX, because it's what they've been fed for so long, and thus can't get off Windows. Just like how my friend's mom only knows IE because it's what she's been fed by Microsoft, and fearfully refuses to even look at other browsers. If she'd learned Netscape first, she'd be more flexible and ready for change, as Netscape is more cross-platform, and she could take her familiarity with Netscape on Windows to her son's Linux box, for example.
Re:Drivers and improving releases (Score:2)
That's very long term thinking. Which is great if you can afford to do that. But typically, developing for portability will increase your development time by 25%-33% - sometimes more. Which means that it costs that much more... and makes it much LESS likely to do it. If marketing can't see a reason to release on X Y and Z platforms, then they'll recommend only releasing it for platform X and keeping the rest of the money for yachts and booze.
(Ultimately, in today's climate, portability is not a compelling argument for development teams to take to upper management - the profit margin's too low - remember; dev time is the most expensive part of making a game)
Simon
Because... (Score:5, Informative)
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!
OpenGL for gaming consoles? (Score:2)
So yeah, I think its got cross platform down pat.
Re:OpenGL for gaming consoles? (Score:2)
The N64 has an OpenGL-like API, but it's not OpenGL. The PSOne and PS2 don't really have graphics APIs, there are a few calls to tweak the video hardware, but you basically have to generate your own hardware display lists.
The Dreamcast's native API is called KAMUI, which is nothing like OpenGL (the PowerVR chipset never was very OpenGL friendly). It also runs DirectX 6 if you go with the WindowsCE option.
3D Studio MAX can also use Direct3D.
Re:Because... (Score:2, Interesting)
Companies like Sony and Microsoft and Nintendo all try to arrange contracts with the game companies that are exclusive... the contracts are worth more to the game companies if the developers then write for one platform exclusively. Some sort of Microsoft like corporate agreements, except there isn't a total monopoly. I don't think hardware manf. want an open framework, then they would loose that barganing ability.
Re:Because... (Score:2)
Counter Rant (Score:2)
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.
Re:OS/2 rant (Score:2)
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...
Re:N64 (Score:2)
Re:Because... (Score:2)
Hmm, I've never tried this "No Score +1 Bonus" thing, wonder how it works?
Already limited to one OS (Score:2)
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.
Re:Already limited to one OS (Score:2, Informative)
Re:Already limited to one OS (Score:2)
Well, I guess we know how you feel about Quake III then, since it was a simultaneous release (even if the retailers and distributors, understandably, worked harder to get the Windows version on the shelves than either of the other two).
Re:Already limited to one OS (Score:2)
How well is it supported by the video cards? (Score:3, Interesting)
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.
Actually, Nvidia releasing new OpenGL in days (Score:5, Informative)
Cube map texturing -- for higher quality environment mapping and lighting support
Multisampling -- for order-independent anti-aliased rendering of points, lines and polygons
New texture modes that provide more powerful ways of applying textures to rendered objects:
Texture Add Environment mode
Texture Combine Environment mode
Texture Dot3 Environment mode
Texture Border Filtering mode
Compressed texture framework -- to allow higher quality textures in less memory regardless of file format
OpenGL on the Mac (Score:5, Informative)
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.
Because of two things... (Score:3, Insightful)
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>
DirectX doesn't suck anymore (Score:4, Interesting)
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.Show 'em the money (Score:2, Insightful)
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.
XBox (Score:4, Insightful)
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.
And that's not the only piece of Hardware (Score:2)
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.
Re:suggestion (Score:2)
it just makes you look like more of a jackass
Cat meet Kettle. Kettle, cat.
there is hope. (Score:4, Interesting)
Another wrapping (Score:5, Insightful)
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.
Re:Another wrapping (Score:2, Informative)
Since DirectX is really a set of APIs (DirectDraw, DirectInput, etc.) I'm not sure this is a fair comparison. When we talk about OpenGL, of course we're only talking about a graphics API. Haven't you heard of OpenAL [openal.org]? It's a complementary open audio API. There's even an input API called OpenIL [slashdot.org], and more [mediaone.net]? My point is, if you aren't going to compare MS's set of APIs to another complete set of APIs, like SDL, then at least compare it to the entire set of Open*L APIs. As new as some of them are, they do exist!
OpenGL has one real problem - lack of games. (Score:3, Insightful)
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.
Developer gap? (Score:2)
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.
Producing Games (Score:2, Insightful)
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.
The law of diminishing returns... (Score:2, Interesting)
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.
Neverwinter Nights will use OpenGL (Score:4, Interesting)
Its called market forces (Score:2)
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.
OpenGL is for professional users (Score:2)
Who wants to game on anything other than windows?? (Score:3, Insightful)
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??
Windows? (Score:2)
Comparing Direct3D 8 to OpenGL (Score:5, Insightful)
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
Re:Comparing Direct3D 8 to OpenGL (Score:4, Insightful)
I'm a professional PC videogame developer. I used to use OpenGL, about 4 or 5 years ago: At that point, Direct3D was the clunky, awkward, slow, difficult thing that people have labelled it as elsewhere in this thread, and OpenGL was a lovely, simple, pure thing. And so I used OpenGL instead of Direct3D, and lots of other people did too. The most famous examples in gaming are QuakeGL/Quake2/Quake3 (Quake1 at retail was software-only).
But OpenGL stood still, and Direct3D moved on. Sure, it took then about 4 or 5 revisions (I think they were on D3D version 3 at the time, now they're on version 8.1, but there was no version 4*), screwed up quite a few things along the way, but they got there in the end. Over the years we've either used OpenGL or suffered the vagaries of Microsoft's repeatedly-changing API. But it's settled down now, matured, and become not only usable, but actually much much better than OpenGL. Sorry, but it's true.
Part of this reason might be "The Farenheit Misdirection" -- basically Microsoft said, "Yes, let's work together on a new API, neither DirectX nor OpenGL, called Farenheit, with the best parts of both, and it'll be great!". And SGI, it seemed, believed them, having not learnt the lesson from IBM and OS/2.
Course, you don't hear much about it now. :P
Another reason is the OpenGL review board, which (as I understand it from the outside only, perhaps someone else could fill in more detail and/or correct me) is not making much progress on new spec due to infighting between rival board manufacturers who obviously want the spec to match up closely with their hardware, and for preference, match up as badly as possible with their rival's hardware.
A few people have mentioned the X-Box thing. Certainly, I doubt anyone will use OpenGL on the X-Box, and any game with both X-Box and PC SKUs will use DirectX too, but I think that's a bridge which is only now being crossed; whereas OpenGL has slacked off for about 2 or 3 years now.
* which is a different Ask Slashdot: why is there no version 4 of so many things? No DX4, No Palm 4, no Voodoo 4, no Borland C++ Builder 4 ... all skipped straight to 5... go figure
Pixel/Vertex shaders with the new OpenGL 1.3? (Score:2)
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.
OpenGL vs. DirectX (Score:3, Redundant)
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.
SDL ! (Score:2)
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.
Gamers perspective (Score:2, Insightful)
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.
Documentation (Score:3, Informative)
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.
We don't need no stinking games... (Score:2, Insightful)
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!
The present and the future (Score:5, Informative)
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
c good model for high level graphics programming? (Score:2, Informative)
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 [oreilly.com] are already using [alice.org] it as a high-level graphics language.
Re:The present and the future (Score:5, Funny)
The whole tone of your comment has this ridiculous tone of authority like you and only you among slashdot's readership is qualified to make intelligent points about the topic. Well guess what? Slashdot is a democracy, and you are no better positioned to trash Linux gaming than the rest of us. As a matter of fact, I bet you are some lame Wind0ze user who doesn't know the first thing about Linux! There are lots of Linux games and they totally rock. It is just stupid for the majority of game developers to ignore the best OS out there just because Bill Gates has a total monopoly and all the stupid people use his product.
All you moderators who voted this up to +5 just prove that you are total suckers for some shill from Micros~1 who can write with a fake semblence of authority. You are hurting Linux by giving credence to someone who obviously has ulterior motives. Stop rewarding people who just write 15 paragraphs and start realizing that what makes Slashdot so great is that we can all offer our professional opinions about stuff. We don't need to rely on some long winded, self-important person to tell us what's going on, because we know best!
The one thing that really makes the internet a great place is that we have ripped down the barriers to publishing, and by doing so we have proven that we don't need self-described "experts" to tell us what to think.
Re:The present and the future (Score:3, Funny)
I don't know which is funnier... this post, or the replies of those who didn't "get it".
I don't think it's really been established... (Score:2)
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.
Re:I don't think it's really been established... (Score:5, Insightful)
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
Re:I don't think it's really been established... (Score:2)
Plus, I had the question on why the Q3A for mac was somewhere like $20 higher than the windows version when I bought it 3 weeks after it came out for mac?
Re:I don't think it's really been established... (Score:2, Interesting)
I run a website about The Sims ( http://www.thewageofsim.com/ ) and I was one of the first (if not the first) established The Sims websites to embrace the Mac community and convert all of my content to Mac compatible when the Mac version of The Sims was released.
My traffic is 95% Windows users. 95%.
Re:I don't think it's really been established... (Score:2, Insightful)
Forget all of those. Consoles are where's it at now. I say this as an avid gamer of 10+ years who used to play the hardware rat race with all the others. Every year a new $300 video card, constantly upgrading processors, memory, sounds cards. Who needs it.
I'm totally sold on consoles now, and I'm addicted to my PS2. The only thing that PC games really shine at these days is better video resolution, but at what cost? (Used to be networking, but the consoles are catching up there.)
Judging by all the dying PC game companies, the slowdown in PC-only titles, and the lack of innovation there, I think the PC gaming market is becoming irrelevant.
So I don't really care if I can't play games on my Mac or Linux box. I don't play them any more on my Windows box, either.
Re:I don't think it's really been established... (Score:2)
No OpenGL games?!? (Score:2, Insightful)
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 [opengl.org] 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.
OpenGL on Playstation II (Score:2, Informative)
The Playstation II game "Star Wars Starfighter" was developed using a Playstation II version of OpenGL. It looks, from reading the 'postmortem' on Gamasutra [gamasutra.com] 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?
Real problem: OpenGL ARB doesn't care about games. (Score:5, Insightful)
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...
Driver Support (Score:2)
The fact that it won't sell on Linux is hardly an issue. It's just not cost-effective to port to Linux anyway.
Be cause the world doesn't run on logic. (Score:2)
Boo hoo, the world doesn't make sense.. Cope and move on..
Business model questions trump the API question (Score:2, Interesting)
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.
Anyone remember Fahrenheit??? (Score:2, Interesting)
The real reason (probably been said) (Score:2)
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.
Apples and Oranges (Score:2)
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
Re:So, write for the Itanium. No M$ there. (Score:2, Interesting)
Re:Fuck D3D and OpenGL, what about Glide (Score:2)
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.
Re:Tried? (Score:2)
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.
Re:Are you sure there's no OpenGL games? (Score:2)
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.
Re:The real issue... (Score:3, Informative)
>>>>>>>
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.