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.'"
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.
OpenGL..I think that says it all. DirectX is a great platform, don't get me wrong. It does its job. But what happens when DirectX doesn't do what the programmer wants/needs it to do? Too bad, gotta wait for DirectX (current version + 1.0). What happens when you want to release your software for more than one platform? Out of luck here. I think there are quite clear advantages.
OpenGL is similar to a PORTION of DirectX (Direct3d)...
OpenGL does not provide any other of DirectX's functionality...
With the long history of slow moving approavals for the OpenGL community, I hope that politics doesn't take over and bring the approval system back to a crawl after Version 2 is released.
Nah, I just got the impression that MJ just cut'n'pasted directly from HardOCP. Word for word. I kid ye not.
MS will of course continue to press DirectX, but, the more Linux, and FreeBSD, and "alternative" platforms become used, and viable, (Thanks to NVIDIA for their drivers for FreeBSD AND Linux) the more appealing it is for developers to create cross-platform games. This is why it is essential for OpenGL to progress, and why I am so excited for version 2.0.
BTW: what is the status on the MS patent issues? Anyone know?
Guess what? I got a fever! And the only prescription.. is more cowbell!
Yeah, ever since DirectX was integrated into the Linux kernel OpenGL has been dead. ...Huh?
Someone set us up the bomb, so shine we are!
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
I'm vehemently anti-Microsoft, but for a long time, I've loved DirectX. Of course, the DirectX team has always been something of a rebel element within Microsoft, so I don't feel too bad :) Hungarian notation aside, it's a wonderful API to use. I didn't start using it until it was around 6.0, which explains why I didn't get put off by the stinky earlier versions. From what I've seen of OpenGL 2.0, it's a worthy competitor to Direct 3D. It's comparable in terms of features, and has a nice clean design that's much more straightforward than Direct3D, which is admitedly complex. However, OpenGL is a replacement for D3D only. OpenAL is probably comparable to DirectSound, but there is nothing comparable to DirectShow, DirectPlay, or DirectMusic on Linux. A breakdown:
DirectShow - Gives you a unified media framework. Allows plugins to be written independent of program, and allows programs to use any installed plugins. The code for something like this exists (or soon will) in the Linux world, in the form of gstreamer, aRts, mplayer, and xine, but unfortunately, the latter are not one framework, but several. In particular, it infuriates me that there are codecs that mplayer has support for that xine doesn't, since Xine has KDE interface and mplayer doesn't.
DirectPlay - A high level networking API. DirectPlay is independent of the underlying protocol, and encapsulates high level networking concepts like meeting places and session management.
DirectMusic - This is something that Linux really doesn't have, to my knowledge. DirectMusic allows the composition of dynamic soundtracks using a powerful MIDI engine. I know MIDI sounds like a throwback to the past, but several modern console games have taken to using it to allow in game music to reflect in game events.
A deep unwavering belief is a sure sign you're missing something...
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.
Where are the new 'Pro' features.
To me, OpenGL lacks really good object-picking algorithms, has problems with coplanar geometry (lines on top of polygons, for example), and poor typography support.
Personally, i would like to see OpenGL move towards being more suitable for general purpose displays, which would allow easier implementation of things like Apple's OpenGL accelerated windowing system.
I know that programmable pixel shaders etc. are useful, but why does OpenGL not specify things like raytraced and radiosity lighting models, along with voxel primitives, and features for window and page oriented output of arbitary geometry (including support for true curves/surfaces etc.) ala Postscript
Many of these things can be implemented at a low level by pixelshaders, but whats the point of a high-level API that simply exposes a lower-level API?
Even though these things can't easily be accelerated by current consumer hardware, neither could gouraud-shaded polygons a few years back.
OpenGL does not seem to be moving forward in defining new and easy ways to define computer imagery, and is chasing the tail of DirectX, seemingly to avoid losing relevance as a gaming platform.
This, to me, is not the right approach - I don't want to see OpenGL discarded by games programmers, but I also want to see OpenGL become a more powerful API across-the-board that makes my life as graphics programmer easier, not harder.
I gots ta ding a ding dang my dang a long ling long
Shader's are just the logical next step in the progression of the 3D pipeline from fully fixed function to totally programmable. In a fixed function pipeline, you've got specific steps that the data goes through. Ie:
e 4. asp
- App send OpenGL vertex data.
- Vertex data gets rotated, translated, and scaled according to the modelview matrix.
- The scene is project onto the screen using projection matrix.
- Triangles are constructed from projected vertex data.
- Triangles are broken down into scanlines, and color values are stored in the framebuffer based on a specific combination of material color, lighting, and texture information.
The OpenGL 2.0 programmable pipeline is different. In addition to the features of the fixed function pipeline you have additional steps.
- Verticies, instead of going through a fixed set of transformations, instead go through a shader program. The shader program manipulates the position of the vertex much more flexibly than a fixed transformation. For example, a vertex program could make the verticies of a flag move to simulate the waving of the flag in the wind. It can also do similar things for water or cloth.
- Pixels, instead of being colored according to a fixed formula involving material, lighting, and textured, are also run through a mini program. The pixel shader (also called fragment shader) is presented with a set of inputs (texture data, lighting information, material color) but has the freedom to access other data as well as do its own computations. This allows advanced effects like more realistic lighting, bump-mapping, basically anything you can program.
- Instead of having fixed conversions between different data formats, you have what are called pack/unpack processors. You can run mini programs on the pack unpack processors to flexibly translate between data formats without losing the benifet of hardware acceleration.
All of thse features allow far more advanced effects than what is possible with a fixed pipeline. For a look at exactly what effects are possible:
http://firingsquad.gamers.com/hardware/r300/pag
NVIDIA has a pixel shader design program you can check out.
Doom III uses pixel shaders for dynamic shadows, among other things.
A game called AquaNox uses pixel shaders extensively for water effects.
Unreal Tournament 2003 uses pixel shader as well.
A deep unwavering belief is a sure sign you're missing something...
By version 20, it should be good enough to simulate virtual 3D porn environments - thus justifying the name DirectXXX.
example.org - powered by Linux!
Right... Either you've never used DX8/9, you've never used OpenGL without glut, or both. Both API's have their good points and bad points in ease-of-use. But as of today (and especially with DX9), I would give the nod to D3D here. There are too many things that are vendor specific in OpenGL that are required for fast operation. This turns into a big pain in the ass. Also, anyone who's written wrapper code to dynamically load DX or OpenGL libraries at run time knows that the C++ interface of DX is a godsend.
Cross platform. Direct3D doesn't run on other platforms (yeah, there's probably a project or two on sourceforge to prove me otherwise), but in general, you don't have to install any fancy things to get OpenGL working on multiple computers. In fact, if you use the GLUT (although deprecated, it has its uses) library, then theorhetically, you should only have to recompile the application to have it run on a specific platform.
Cross platform is right, easy to port, not-so-right. Even when using glut, extensions that exist on the PC's are usually different than apple's extionsions that do the same damn thing. Apple's policy towards OpenGL is similar to the way MS treats DX. The only time the API is updated is when Apple approves of new GL_APPLE extensions. There is no aglGetProcAddress, so vendors are not at liberty to add new extensions when they please. I'll admit that this could be viewed as a good thing, but it does make developing at the bleeding edge more than a little difficult.
John Carmack. Face it, the mans incredible. He's literally changed the face of graphics, but I'm sure everyone already knew that ;).
Unfortunately, only John Carmack can tell the IHV's what to do and what extensions to support in OpenGL. Yes, he's helped OpenGL, but what does Carmack have to do with you choosing to use OpenGL vs. DX?
The general API is nicer looking. To me, and I'm sure a lot of other people, code aesthetics is very important. OpenGL uses simple, yet intuitive function names. I want my object to be 100% red, and 50% blue, and 0% green, simple, I must use the glColor3f(1.0f, 0.5f, 0.0f); function (gl - the library, Color - main identifier, 3f - takes 3 floats as arguments). I'm not sure of the function in Direct3D, but I'm sure its not as nice looking.
Write back when you've tried using programmable shaders under OpenGL (especially fragment/pixel shaders). Personally (and I know I don't speak for everyone), I perfer the DX api to GL's. I also prefer DX's standard vertex lighting model to GL's (the spot light formulae (sp?) are different). The DX fixed function pixel pipeline is more flexible than GL's standard (GL_ARB_texture_env_combine) pixel pipeline.
In my summary: OpenGL and DX are very equivalent in functionality. OpenGL tends to have MORE function calls into the library, but DX has more EXPENSIVE function calls into the library - so this is a wash. I do hope OpenGL 2.0 will kick ass, but I'm also hoping it's a step towards the day when DX and OpenGL have easily translatable shading languages and features for everything. It's not there yet.
Dan
I don't normally post to slashdot but having read some of the comments I just had to say something.
First thing: there's is a common misconception that DirectX is "light years" ahead of OpenGL. That couldn't be more false. There are quite a few things that you can do in OpenGL that you wouldn't be able to in DirectX. Here's a good example: GeForce register combiners.
On the other hand there is nothing DirectX (or more correctly Direct3D) can do that OpenGL can't. All of the functionality is present through extensions.
Main problem with OpenGL is not functionality - it's the extensions. Different graphics cards support different extensions that provide the same functionality but to get your code to run on both cards correctly you have to support both extensions.
The whole extensions mechanism is a mess really - it was a good idea while the number of extensions was small but these days there are way too many of them.
Another misconception (and I just can't see where exactly is this coming from) is that DirectX is faster than OpenGL. On nVidia cards at least DirectX is most definitley not faster than OpenGL. Run any game that supports both APIs and OpenGL is almost always faster. This is not noticable on really powerful systems but on slower ones OpenGL runs slightly faster. For that matter just look at all the abstraction present in DirectX - abstraction does not come for free, there is a performance cost - it's small but it's there. OpenGL on the other hand is nice and clean.
Not to mention that DirectX uses a lot more memory than OpenGL.
I also noticed someone saying that DirectX drivers are easier to implement. That is most certainly not true. I find it puzzling that there are so many graphics cards with bad OpenGL drivers because OpenGL drivers are relatively simple compared to DirectX ones. I'm guessing the main reason is that DirectX is more popular and hence better supported.
And to the guy who mentioned hardware independence, sorry to disappoint you but OpenGL 2 will not be any more or less hardware independent than OpenGL 1.x.
OpenGL is a standard just like DirectX, not a driver. That means that graphics card companies will still have to write OpenGL 2 drivers - there won't be one driver for all OpenGL 2 cards. Before you post something incredibly stupid again use your brain for a minute and think about it.