Slashdot Mirror
OpenGL 2.0: Chasing DirectX
MJ writes "Is
OpenGL 2.0 All That? Hopefully you will be able to answer that yourself after reading this article from XtremePcCentral. They have cool looking leap frog graphics with lots of arrows and a quote from John Carmack, what else could
you ask for? Robert Richmond does a great job of delving into this
subject. Carmack says, 'The implementation went very smoothly, but I did run into the limits of
their current prototype compiler before the full feature set could be
implemented. I like it a lot. I am really looking forward to doing research work
with this programming model after the compiler matures a bit. While the shading
languages are the most critical aspects, and can be broken out as extensions to
current OpenGL, there are a lot of other subtle-but-important things that are
addressed in the full OpenGL 2.0 proposal.'"
Understandable, but when was the last time Joe home-user could download Direct3D by itself?
OpenGL is "good enough" and its Cross platform. End of Story. That alone makes it worth the extra effort.
It's short sighted thinking that got us into the situation that were in now, where one nasty law-breaking company wields its power with an iron fist and wants to crush any potential innovators before they even have a chance to compete.
Who knows what other grahpics programming languages have been or will be quashed because of Microsoft? The only reason OpenGL even survived is that it was mature to enough not to be blown away be those crappy early versions of DirectX.
If you wanna get rich, you know that payback is a bitch
But what happens when DirectX doesn't do what the programmer wants/needs it to do?
:)
This won't happen too often. DirectX is crazy feature rich. In fact, overly so for some
You need to realize the OpenGL isn't an open source project. You can't add more stuff to the API if you find that it's lacking. The reason is that you can't add your new functionality to the hardware, which is the whole point in using OpenGL in the first place. So, you still have to wait for the next version of OpenGL to come out, and graphics-cards manufacturers to build cards with it in mind.
Whether coding in GL or DirectX, if the library doesn't do something you want, you have the exact same options: wait for the next version, or hand-code your functionality from fundamental functions.
This is one spot were DirectX has a big advantage over OpenGL. DirectX is designed by only one party, rather than a big committee of different companies who want different features. As such, DirectX has a much faster development cycle, and gets improvements quite often. The last big improvement to OpenGL was released in 1998, version 1.2. Four years is a long time in the world of 3D graphics.
Understandable, but when was the last time Joe home-user could download Direct3D by itself?
When was the last time Joe Home-User *needed* to download DirectX?
These days, when Joe wants to play a computer game, it'll install DirectX for him if he doesn't have the required version.
What I always thought that was cool about the idea of DirectX was where you could in theory make certain calls (API or direct) that would stay the same while the actual logic behind the action could be updated and upgraded. Of course this is really the promise behind COM, but was advertised as being the main thing to shout about for DirectX.
However, in reality each release pretty much rewrites the entire system. And since you cannot mix versions then you are forced to either rewrite your entire calling routines or just suck it up and go with the older version (and be hammered by kiddie/poser reviewers).
If OpenGL would apply the lessons from this and build a multilayered (or rather multilayer-abstracted) interface system so that components can be enhanced or changed without requiring a rewrite of code (or at least a major one). What is the point of API's during times in which capabilities change so much if they are outdated in 6 months? I guess what really confuses me are the trollish kiddies that will parrot things on the order of, "why do you need API's, shouldn't you do real programming and blah blah blah?" Well the typical and rightful response to this is "and I suppose that not only are you programming in binary, but more importantly you are not using a text display but are in fact using a dial or manual switch system..."
Basically I see little difference between the number and variety of cards that are released on one day (lateral) as ones released over time (vertical). Yet what happens is that some new card enables a new rendering toy _OR_ some better method of implementing an existing method is released and we break the system. Don't get me wrong, a system like this is not easy to implement... at least not from scratch. However, based on the history and patterns (lessons learned if you will) from attempts up to this point, there should be a good place to start. There are definitely differences between changes like mono sound to multi-channel suround 3d sound with cherries on top, and that of different methods of shading for 3d rendering. After all, anyone who can fly an aircraft can fly any aircraft that follows the common interface, regardless of using prop or jet or whatever. Sure, there are differences in various controls but anyone who has flown very much knows the similarities are more than the differences in terms of operations. This even includes changes from dials to digital, etc.
This makes it harder to build reusable libraries and engines. That equates to two things: higher prices for your games, longer times to release (and flakier games because of the non-learning aspect of marketers and publishers) and of course underutilization of available hardware and technology. Three reasons? NOBODY EXPECTS THE SPANISH INQUISITION!
Maybe the day will come where there can be very generalized, abstracted toolsets/API's that are common to all major functionalities (sound, 3d graphics, 2d graphics, etc) that can be safely drilled-down as low as the programmer wants to go. Pipe dream at this point, but then again so were most of the things we use today at one time.
"The contiued success of OpenGL is vital for the survival of Linux on the desktop. Without it, making games for Linux is impractical. I don't think WineX can be counted on to keep up."
I think you make a good point. For the most part I agree with you, but I'd make one little change: Linux needs something like DirectX to succeed. Whether or not it is OpenGL is not crucial. The problem with OpenGL is it doesn't keep up with the features of new cards the way DirectX does.
Linux needs a developer who's on top of the game like MS is. The smart thing to do would be to mimick DirectX as much as possible, make it easier for a PC game developer using DirectX to port their game over to Linux. Let's be frank: With as few gamers running Linux as there are today, ports of existing games is all they're gonna get. Might as well work to make that transition easier.
Come again? I think you misunderstand the details of the situation. The IHV's do not live at MS's pleasure. For example, nvidia's cg is an assult on MS, trying to leverage away their control of the API. Each IHV wants to be able to control the API, so that they can codevelop it with their hardware, producing complimentry strenghts. The relationship is already openly adversarial, and they only co-operate in situations of mutual self benifit.
Your sentance above is unclear, but I understand you're saying that Apple's OpenGL has better hardware support than x86? You do realize that Apple's video chips come from the same IHV's?
That's what always happens to the elitist computing types.
It's like the rabbit and the turtle fable or whatever...
The PDP-11 people used to do it, and now the unix people do it too.
Everyone was so busy laughing at direct X when it first was released they never bother to work on openGL. Until one day DirectX was actually more powerful than OpenGL and more widely used. Now the elitest types are trying to play catch up when they used to have a huge lead.
The same thing happened with browsers. Everyone used to laugh at Internet Explorer 1. And with good reason. It sucked, badly. But then things heated up but people still thought they could just keep ridiculing the old IE and not noticing it improving. Then netscape basically stopped all development essentially no progress was made, much reinvention of the wheel (Mozilla) is not progress and now IE is the browser of choice. Sorry but actually shady business practices had less to do with the fact that IE 5.5 was actually good while netscape 4.762342344..... was stuck on 1996.
Anyways don't get so cocky laughing at Microsoft that you don't stay vigilante or they will blow past you. Sorry but it is true.
I know some hardened old unix guy will say "bah microsoft still sux0rz" well have you really used any of it lately or are you still making fun of windows 95?
Hey the PDP-11 people did it too..."PCs are crap, no one will use those peices of shit for anything important" Haha, now it's just big racks and racks of PCs and no big "Professional" system in sight.
The unix world had a long head start on windows on so many fronts but squandered laughing at microsoft and strutting about. Microsoft kept developing and fighting for market share while the unix world sat on it's laurels.
Now to really sinch the negative moderation let me also mention this turn of events in computing. The BSD people do the same thing. Bashing Linux as a "toy" os just becuase BSD had been in development for several more years. Now which is the more featureful OS? Despite the empire has no clothes attitudes of the BSD population those OSes are playing catch up to Linux on several fronts and on close examination many of their claims to fame are really no so great when faced with an honest comparison of Linux.
Oh well the moral of this story is the same as the Hare and the Tortoise or whatever it was called...
I'll repose the original question:
But what happens when DirectX doesn't do what the programmer wants/needs it to do?
The programmer is screwed with either API. Sure the hardware company can extend either API to its heart's content, but that doesn't help a programmer who needs a feature right now.
The development process isn't too different with DirectX--Nvidia had some whiz-band ideas so they talked to Microsoft. DX 8.0 was released. ATI had similar functionality for their hardware, but didn't agree with Nvidia. They went to MS and DX 8.1 was released. Microsoft talked to them both and is going to release 9, itegrating 8.0 and 8.1 features. The architechture review board for OpenGL does the same thing.
Microsoft doesn't make all the decisions for the industry and cram it down the industry's throat. MS talks to all the relevant companies (hardware and software) as part of the feedback loop for DX. Microsoft/Nvidia's Cg language that was in the news a while back is an example of that. The advantage is that Microsoft has tightened the feedback loop so its turnaround time is less.
1. Vertex/Index Buffers
The only way to store geometry data on the video card is by using extensions. To make matters worse, you passs nvidia's extension a couple floating point numbers and it magically gives you a block of memory if it feels like it, or not. Then this is the only block you get. Its up to you to write a memory manager on top of it
2. Documentation / Extension system
First, there hasn't been any HTML or even plaintext specs of the newer APIS. The PDFs look like ASS because of the pdf fonts. Second the extensions are made so that they are incremental updates to the manual "insert these lines into section 4.3.10" This helps no one use the extension. Why can't they just be explained in full. Plus, the least important fields such as the "issues" should go towards the bottom of the spec.
3. Arcane extensions with arcane (or no) docs
i'm talking about stuff like the nvidia register combiners, fence, vertex array range. And a powerpoint outline doesn't do the job explaining these.
Joking aside, I hope, and know that OpenGL will never die. Several reasons:
To summarize:
I love OpenGL and everything about it. I know it will never die. Its an incredible API, and although its slow to update, I'm sure OpenGL2.0 will kick ass.
-Vic
Linux needs something like DirectX to succeed. Whether or not it is OpenGL is not crucial. The problem with OpenGL is it doesn't keep up with the features of new cards the way DirectX does.
Not many games keep up with the features of new cards, so OpenGL doesn't have to be bleeding edge to run them. The reason there aren't that many games for linux isn't that OpenGL is dated.
Besides, most good games offer both OpenGL and Direct3D renderers. The rendering is only a small part of a 3D game and it is not that difficult to provide alternative renderers.
And frankly, who cares if "Sunny Garcias Pro Surfing" runs on linux or not.
The smart thing to do would be to mimick DirectX as much as possible, make it easier for a PC game developer using DirectX to port their game over to Linux.
Dear god please no. The goal of OpenGL should be to provide an excellent api for realtime 3d programming, not to mimic Direct3d. If any Direct3d programmer understands 3d concepts well enough, porting to OpenGL should present no difficulty whatsoever. And vice versa.
:wq
Let people worry a few more years about DirectX and OpenGL 2 features and see how things shake out; then, those things may be mature enough to be widely used and built on. Until then, a good OpenGL 1.x implementation is all I want.
You are comparing OpenGL to DirectX, which is a no-no. Perhaps you meant to compare it to Direct3D, a component of DirectX. OpenGL is crucial to the development of 3D on all platforms except for Windows. It provides a standard, platform independant 3D API for people to develop software. What else is there that is so widespread? What do you propose?
Linux already has its own DirectX-like wrapper system. It is called SDL and it is multi-platform, unlike DirectX. It allows you have "low level access to a video framebuffer, audio output, mouse, keyboard, and joysticks across a wide variety of operating systems." (from the libSDL page). With that, it supports plugins and addons, and a full rewrite is going into SDL 2.0 to make it much more robust and flexible. It is a proven and powerful method of producing games on Linux, and is nowadays seen in most commercial apps.
Honestly.. I hate to say it, but you seem to be doing nothing more than talking in circles. I honestly wonder how some of you people on Slashdot make these things up. While I agree that there aren't nearly as many gamers that use Linux, there is still a userbase- and a growing one. As for your suggestion of mimicing DirectX- that's already been attempted. It's called WINEX. It's a layer between a layer between a device. Work is being done on attempting to create an Open DirectX-like library and API, but don't count on it working out. It only provides a wrapper for existing OpenGL devices right now. There is a reason that Microsoft changes DirectX every year. It isn't just about adding new features. Backwards compatibility is shady at best.
The programmer is screwed with either API. Sure the hardware company can extend either API to its heart's content, but that doesn't help a programmer who needs a feature right now.
Yes it does. Assuming we agree that by "feature" we mean "something the hardware can do, which can be exposed by the API". Then as long as you have the driver with the extension, you can use it in your OpenGL code. Meaning with OpenGL, as soon as the feature is there, you can use it.
The development process isn't too different with DirectX--Nvidia had some whiz-band ideas so they talked to Microsoft. DX 8.0 was released. ATI had similar functionality for their hardware, but didn't agree with Nvidia. They went to MS and DX 8.1 was released. Microsoft talked to them both and is going to release 9, itegrating 8.0 and 8.1 features. The architechture review board for OpenGL does the same thing.
Yes, but the difference -- and maybe you didn't catch this -- is that before the ARB approves either one of NVidia's or ATI's changes, programmers out in the field can use those features through extensions.
Microsoft doesn't make all the decisions for the industry and cram it down the industry's throat. MS talks to all the relevant companies (hardware and software) as part of the feedback loop for DX. Microsoft/Nvidia's Cg language that was in the news a while back is an example of that. The advantage is that Microsoft has tightened the feedback loop so its turnaround time is less.
You didn't catch it. The point is that with the OpenGL extension mechanism, you don't need to wait for the feedback loop. The turnaround time for the ARB to approve a feature for inclusion in the spec may be X, and MS's inclusion of the feature in DirectX may be X/2, but the turnaround time for your being able to use the feature in OpenGL is zero.
That's the advantage. An API that includes a standard mechanism for detecting and using unofficial extensions to the API is going to let you use new features faster than the fastest of official approval boards.
"The goal of OpenGL should be to provide an excellent api for realtime 3d programming, not to mimic Direct3d. If any Direct3d programmer understands 3d concepts well enough, porting to OpenGL should present no difficulty whatsoever. And vice versa."
:)
From what I understand the non-"immediate" mode of Direct3D is much higher level than what OpenGL provides in its current form. This IS important because not all game developers have the time or brains to hand craft an entire engine technology for each game like Carmack does. They have to rely on a prebuilt and high level library that makes their job easier (and rightly so). So OpenGL has to step up to the plate and also provide some high level functionality. This also has the upside of becoming hardware independent and more easily customizing the backend to the hardware (these shading languages, etc.).
Any way that was the perception I got last time I looked at Direct3D...which was a LONG time ago
It's 10 PM. Do you know if you're un-American?