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.'"
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.
The continued success of OpenGL is vital for the survival of Linux on the desktop.
Remember that Apple and the Mac OS rely on OpenGL for graphics. That combined with continued interest in OpenGL on the PC side for CAD and the like -- not mention Carmack and Co. -- should keep OpenGL around as a viable alternative.
Ooh, a sarcasm detector. Oh, that's a real useful invention.
The cross-platform one is interesting if you're in the games business, since of the commercially viable platforms (i.e. Windows PC and the consoles - even if both of the Mac owners buy your game you'll never recover your costs), OpenGL is supported on precisely one of them, whereas Direct3D is supported on two (PC and Xbox).
FYI - WineX uses OpenGL to emulate DirectX! OpenGL is indeed critical.
The Raven
The Raven
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...
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.