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.'"

Comments

Goobers

[Anonymous Coward]

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?

Does anybody else get the impression that "MJ" works for "XtremePcCentral"? I'm seeing a lot of this astroturfing on Slashdot lately, and it's lame. If you want to drive traffic to your site, buy an ad.

OpenGL is vital for Linux

[bsharitt]

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.

Re:OpenGL is vital for Linux

[jorleif]

Not many games keep up with the features of new cards, so OpenGL doesn't have to be bleeding edge to run them.

You should take into account that it takes a significant amount of time to develop a game.
One of the reasons games lag behind the cards is that people rarely like to code purely to the specs of some hypothetical next-generation card, and therefore wait until a card is released. Now if the 3D API is developed with a similar philosophy it will lag behind as well, and this will be a big deal to developers:
Should I develop using the

1.OpenGL drivers which support current generation chips, which will be low-range or obsolete cards at the time of the game release

2.DirectX which supports current bleeding edge chips, which will be mid-range cards when the game is released

All in the name

[prisen]

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.

Re:All in the name

[CoolVibe]

John Carmack hates Direct3D with a passion. He once posted a comparison in his .plan file where he tried to compare the two by trying to build functionally the same.

The thing is that JC thought that DirectX was severely over-complex to do anything worthwhile. In OpenGL he got the exact same thing done as DirectX, but with less code, and less stuff that got in the way. He summed it up nicely. DirectX is crap because it is too complex. OpenGL is quite simple and it'll help you get stuff done.

Also, OpenGL is a real industry standard, as where DirectX isn't. OpenGL is cross-platform, as DirectX isn't.

Re:All in the name

[CoolVibe]

I wouldn't put down the Mac as of yet, since they are picking up pace at the moment. Same goes for the free *nixes. If those platforms weren't ebcoming interesting, companies like Nvidea wouldn't have made accelerated drivers for FreeBSD and Linux.

I realize that Direct3D has gotten better, but still, it's going to be a tough job for MS to totally finish off OpenGL. It's well rooted into spaces other than gaming, like CAD/CAM and VR research. And if MS tries to patent it away, that will never work, because of prior art.

I think MS's stance toward OpenGL is neutral. I'd say that if somehow Direct3D would die off, MS would embrace (and probably extend) the OpenGL standard.

What 3D library does, say the PS2 and the Nintendo console use? Their own in-house one? I'd guess OpenGL, because it's available on many platforms, and it's portable. And don't forget the wealth of documentation and example code that's out there for OpenGL. It'd save a lot of time training-wise. It's a wise choice if you do console development on a workstation and if you can just cross-compile so it'll work on the console. Other than the X-box (which is just a IA32 machine on funny hardware), DirectX is indeed only available on 2 platforms.

I'm not a console-developer though, maybe someone who develops 3D-action games for consoles that are not X-boxes could comment?

Re:All in the name

[tc]

Sure. I was obviously being flippant about the Mac, but the point remains that it's not really a commercially viable games platform right now. I was mainly wanted to repond to the dredging up of a 5 year old .plan file which is no longer an accurate representation of the state of things.

AFAIK the PS2 and GC both have proprietary graphics libraries (and in the PS2 case, not much of a library at all).

There's certainly a lot of sample GL code out there, but the bulk of it is on the basics, which is really pretty simple in either API. The complex stuff often revolves around vendor-specific extensions in GL, about which there is considerably less material widely available, certainly not significantly more than for Direct3D.

Re:All in the name

[jason_watkins]

Indeed, as an IHV, you can add whatever extension to the API you fancy, and software developers are given the option of using it. It is a little frustrating in that you, as a software developer, can't depend on the feature being there, but in practice it works well. For example, ATI and nVidia often update to transparently support eachothers extensions.

Periodicly, the ARB goes through and blesses some extensions, making them official. They're still optional in terms of compliance to the standard, but the ARB blessing catalizes a commonly supported API for each feature.

Eventually a new version of the spec is rolled, and usually the majority of changes were already seen as ARB extensions before.

So, OpenGL has managed a steady evolution. Where it has been slower in reguards to directx is in iterations of revolution. In five years DX went from being bizarre to being very similar to OpenGL, changeing the fundamental philosophy of the API design in the process. Dictatorships allow rapid broad changes like this. OpenGL has not done that so well, which is what the OpenGL 2.0 initiative is a response to.

Re:All in the name

[Chris Burke]

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.

Ah, but what if you can add new functionality to the hardware, because you are the manufacturer? With DirectX, nothing changes -- if the API doesn't support what you want, it won't until MS says so. With OpenGL, you can expose new hardware functionality through an extension. Programmers can use your hardware's new features immediately, unlike with DirectX.

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.

This is the exact opposite of what actually happens. In reality, manufacturers build cards with new features and expose them through extensions. Then, in the next revision, the new functionality may be folded into the standard API. The hardware leads the API, rather than trails, without sacrificing the ability to use the hardware immediately.

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.

OpenGL gets an improvement whenever a vendor has an idea for what new trick they'd like their hardware to pull. Yes, it takes them some time to agree on what the next official version of the API should look like, but that doesn't slow the development and acceptance of new features a bit. Vendors can innovate as much as they want, without waiting for a central body to approve and support their innovation -- that is a big advantage.

As opposed to DirectX... I just can't see how being dependent on a single outside vendor to support your hardware's features is an advantage.

Four years is a long time in the world of 3D graphics.

Yes, and in those four years we've seen the development of hardware T&L, texture compression, pixel and vertex shaders... And OpenGL has not wanted for one of them.

GL/DX or C/C++?

[alphapartic1e]

I'm a CS student with very limited experience with both OpenGL/DirectX, but does the fact that OpenGL's association with C and DirectX's with C++ affect some developers' support for that library?

problem with opengl

[SystematicPsycho]

The problem with opengl is that vendors decide to add there own extension to it, and too many vendors do such a thing. If opengl is going to outperform the rest cooperation between vendors and the opengl commitee needs to take place more often.

vs. DirectX

[wray]

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?

Re:Too little too late?

[CoolVibe]

DirectX is no industry standard. OpenGL is. Killing off OpenGL is VERY hard to do. Especially since OpenGL runs on more platforms than just win32 only. And since MS won't have DirectX on anything else other than IA32, it will NEVER be an industry standard. Period.

So it'll disappear from the desktop, only to stay alive where it matters, on the workstations of people using serious applications, like CAD/CAM to name just an example. (And no, not all CAD/CAM happens on intel boxes, actually SGI has this market cornered, guess where OpenGL comes from?)

Yeah yeah, I know the parent is a troll, but I decided to bite. *shrug*

Plagiarism!

[Anonymous Coward]

I got the impression that MJ just cut'n'pasted directly from HardOCP. Word for word. I kid ye not.

DirectX

[be-fan]

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.

Re:DirectX

[Graff]

OpenGL is a replacement for D3D only. OpenAL is probably comparable to DirectSound, but there is nothing comparable to DirectShow, DirectPlay, or DirectMusic

I'm not sure about some of those, but I do know that there is OpenPlay, an alternative networking API. Here's a quote from the site:

What is OpenPlay? OpenPlay is a cross-platform network abstraction layer designed to simplify the task of creating programs which communicate across multiple computers.

While originally designed for multiplayer games, it is useful for any developer who wants an easy, platform-independent way to send messages to programs running on other machines. It completely abstracts both OpenTransport and Winsock, and its plug-in architecture makes it easy for you to support new transport protocols.

Re:OpenGL 2.0

[runderwo]

OpenGL and DirectX are not comparable. Perhaps you mean Direct3D. Comparing SDL or Allegro to DirectX would be more appropriate.

Games are good but...

[ikekrull]

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.

Re:Are you drunk?

[tc]

You misread the quote, of course. He's saying that there is this feature that is exposed on both on the Xbox, and via OpenGL.

As an Xbox games developer, I can assure you that there is no OpenGL support on Xbox. I can also assure you that I'm happily using the feature he talks about via Direct3D.

Why Direct3D Is more predominent

[StreetMerc]

Direct3D is more popular for primarily one reason: It is more widly suppported by hardware manufactures. And the reason is because D3D drivers are easier to write and are supported by Microsoft. Direct 3D drivers are easier to write because there are fewer rendering options to support like in OpenGL (bezier curves/patches, pixel operations, display lists, ect..), Direct3D is hardware centric and forces programmers to write with maximum efficiency to the hardware. With the drawback of less convenience to the programmer. Managing RenderStates and DirectX resources are a pain, drawing geometry requires allocating vertex arrays, setting vertex formats and sending the entire matrix tranform to position it. OpenGL requires less code that makes more sense to do something simple with a lot more convenience. Trying searching the web for Direct3D demos and then do the same for OpenGL. Graphics programming Hobbiests don't care for Direct3D. Direct3D documentation is sparse, even Nvidia has more OpenGL samples than D3D ones in their graphics code samples. But making games takes money, and to maximize profit you bite the bullet and you program in direct3D to maximize your target audience and have a chance at possibly making a profit. Direct3D is not a better API than OpenGL, and there is not a single thing in direct3D that can't be done in OpenGL. It's just finding the hardware that supports it completely, and up until a few years ago only Nvidia had a descent implementation. ID software(quake3,Doom3!) and Bioware(Neverwinter Nights, MDK2) use it almost exclusivly. The issue of Direct3D being a better API than OpenGL was never an issue, it simply had a larger target audience and that is why it is so predominent. Hopefully with the emergence of only 2 key players in consumer grahics hardware the tides will shift.

Re:Are you drunk?

[pixel_bc]

Being a PS2 programmer myself -- I defy you to find even more then a "B title" that actually shipped using an OpenGl layer on the PS2.

It just doesn't map onto the architecture... and you pay the penalties.

Where can I find OpenGL 1.3 and 1.4 test clients?

[shinybeast]

I'm testing an X server and I need to get my hands on a wide range of OpenGL 1.3 and 1.4 test clients. From what I can tell, the OpenGL conformance tests (conform, covgl, primtest, etc...) haven't been updated since 1.2 and are only available to a select group of people.

Can anybody point me to a stash of 1.3 and 1.4 clients? Thanks.

Solid support for Linux would make a difference

[forgoil]

For Windows OpenGL 2.0 will certainly have less impact by now. DirectX 9 is far from bad and will most certainly be used by a large number of developers. But the story for Linux surely is very different.

I certainl will just dream about the next part, but here goes...

I would like to see a standard OpenGL 2.0 implementation for Linux, with implementations for all new cards, that is not tied to X (whether or not it should be somehow connected to the kernel, well, is a decision for the implementors). I want it to be stable, fast, and state of the art.

This would:

1. Give me as a developer one API that I know will always be there, and I won't have to care about what card might be in the computer.
2. Give game developers the same as in 1
3. Make it feasable to port X to OpenGL 2.0 to improve the horrible performace
4. Write a new windowing system based on OpenGL 2.0 and put KDE/QT on top of it to make the Linux desktop experience more up to par with MacOS X for example (i.e. not make a copy of MacOS X, but start using more of your hardware for a smoother ride). (If you prefer gnome, the same goes for it ;))

One of the reasons OpenGL kind of stood still...

[podperson]

Was that SGI went into a partnership with MS called Farenheit, which was to succeed OpenGL. (This was as good a move as SGI's attempts to sell NT boxes and its earlier bid to compete with high-end Macs.)

Farenheit was going to be the "high-end" graphics API, while DirectX would serve for "low-end". Well, you can attribute it to malice aforethought or simply reading the times, but MS withdrew leaving Farenheit dead in the water. Meanwhile OpenGL had pretty much stayed still.

Four years is a long time in 3D graphics. It's pretty sad that DirectX hasn't been able to open up MORE of a lead...

An overlooked feature of GL2

[Temporal]

I do 3D coding in my spare time, and I can't wait for GL2, for all the same reasons everyone else, plus one: asynchronous operation.

Working with a 3D graphics card is sort of like working with a second processor. Ideally, you would send the hardware a bunch of stuff to draw, and then you would do something else with the CPU (i.e. physics calculations) while you wait for the card to draw it. However, with GL 1.x, there isn't any really good way to do this (as far as I know). Once you queue up everything you want the card to draw for a particular frame of animation, you call your swap buffer function and your program just waits for everything to complete. The CPU just sits and does nothing. The only way to take advantage of the situation would be to use multiple threads, but then you run into thread synchronization issues, race conditions, and other crap you might not want to deal with.

With GL2, you can actually have the graphics card signal you when it's done. This signalling is done through low-level OS events, which are OS-dependent (unfortunately), but this means that you can wait on non-graphics-related events at the same time (networking, input, etc.) and handle them all as they happen. No more polling! This is good! Also, instead of queuing up an entire frame at once and then waiting for that, you can queue up bits and pieces and say "tell me when this piece has been drawn".

I guess this excites me more than most people because I am an extreme supporter of event-driven programming. Threads are inefficient and overrated, IMO; a program should never use more threads than its host has processors. Any operation which forces a thread to wait for something cannot be used in such programming models, which means I have a very hard time using GL 1.x effectively. 2.0 will fix that. :)