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

OpenGL 2.0

[MisterFancypants]

That's better than 1.2! But worse than DirectX 9.0!

You can tell by the numbers!!

Re:OpenGL 2.0

[the way, what're you]

I heard that they were going to start using Roman Numerals when DX 10 comes out. They'll call it DirectX X.

By version 20, it should be good enough to simulate virtual 3D porn environments - thus justifying the name DirectXXX.

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

[Eccles]

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.

Re:OpenGL is vital for Linux

[jason_watkins]

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?

Re:OpenGL is vital for Linux

[vlad_petric]

I don't think WineX can be counted on to keep up.

FYI - WineX uses OpenGL to emulate DirectX! OpenGL is indeed critical.

The Raven

Re:OpenGL is vital for Linux

[nihilogos]

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.

Re:OpenGL is vital for Linux

[13Echo]

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.

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

[tc]

He posted that (now infamous) .plan file I think 5 years ago. At the time, Direct3D was indeed a steaming pile to work with. The most recent versions are vastly easier to use. John Carmack still likes to use OpenGL (and why wouldn't he, since he has every hardware vendor in the industry willing to fine tune their GL drivers to his whims), but he has I believe gone on record as saying that Direct3D has improved significantly, and that many of the criticisms in that old .plan file are no longer valid.

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).

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

[LordSah]

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.

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.

Re:All in the name

[(startx)]

IIRC, nvidia originally ported their drivers to linux for the high end cards that graphic designers use since a lot of movie rendering and CAD things are moving to Linux, and that's a VERY lucrative market. And from what I've heard, the FreeBSD port was a whim of a few employees, and wasn't THAT much work since they allready had the linux port, they just needed to tweak the kernel hooks.

Re:All in the name

[LordSah]

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.

When are people going to understand...

[Anonymous Coward]

OpenGL is similar to a PORTION of DirectX (Direct3d)...

OpenGL does not provide any other of DirectX's functionality...

Re:When are people going to understand...

[Trogre]

That's what we have SDL for.

Re:When are people going to understand...

[Some Dumbass...]

OpenGL does not provide any other of DirectX's functionality...

Sure, but that why there's OpenAL, not to mention OpenNL (now called HawkNL) and its extensions, and OpenIL (now called DevIL). Wasn't there an open input layer too? They've gotten hard to find now that so many of them changed their names (due to pressure from SGI? See the OpenIL site!)

Anyway, there's also SDL, and for that matter OpenML. Both are far more functional than OpenGL alone.

In summary, if you want a cross-platform DirectX alternative, there are options. You just have to know about them or search them out.

Conection is Dragging

[Surye]

Here's the article so we can ease up on the server:

Future Look: OpenGL 2.0 Preview by: Robert Richmond Preview Date: November 11, 2002

OpenGL has been a primary component of three dimensional rendering technology since its inception in 1991. OpenGL is implemented in a wide variety of applications, ranging from professional design software to multimedia presentations to interactive games. Currently available as version 1.4, OpenGL has proven to adapt with the evolution of graphics hardware, though it's age is becoming starkly apparent as compared to Microsoft's latest DirectX D3D technology. In hopes of revitalizing the decade old standard, 3Dlabs recently offers a new approach outlining the features of a possible OpenGL 2.0 revision. The concept of a proposal as compared to a standard needs to be clearly defined for the purposes of this preview article. The OpenGL 2.0 topicalities presented here are based upon a discussion text and early developmental engineering from 3Dlabs. Many vendors usually submit discussion texts and/or proposals during the OpenGL ratification process, then an appointed governing committee will analyze the various aspects of the given information before reaching an agreement about the final published standard. Since the OpenGL 2.0 development process is still in finalization stages, the information presented within this text will likely undergo multiple changes before a final OpenGL 2.0 specification is adopted for widespread industry use.

About 3Dlabs

3Dlabs has been a long-time contributor to the OpenGL community by providing advanced 3D hardware solutions to the professional marketplace. 3Dlabs graphics accelerators are commonly utilized for computer-aided design, multimedia development, and special effects rendering. 3Dlabs technology can also be found in many non-PC devices like military aircraft and personal cell phones. 3Dlabs is a wide market corporation with operations currently in Alabama, California, Massachusetts, Texas, Washington, Germany, Japan, and the United Kingdom.

OpenGL 1.x Limitations

The bulk of graphics development was centered on 2D rendering until 1997. The only areas of computing utilizing 3D technologies before this time were generally in the extremely high-end professional markets, such as CAD or virtual reality. The mid-90's release of desktop-oriented 3D accelerators like 3dfx's Voodoo or Rendition's Verite ushered in the concept of affordable 3D graphics for most mainstream PC users. Nearly a half decade later, desktop 3D video cards now include options like cube mapping, hardware transform/lighting, and programmable vertex/pixel shading. The OpenGL interface has evolved along with these new rendering features, but today's OGL 1.x does have substantial room for improvement as the next generation of video chipsets could finally outpace the capabilities of this venerable standard.

For example, the popular OpenGL 1.3 API suffers from several major limitations, especially in regards to extending the base programming interface to include additional rendering options. The base OGL 1.3 specification documentation is approximately 284 pages of programming conventions and theory, while nVidia's extension documentation needed to implement options like per-pixel shading is well over 500 pages in length. The concern over efficient programming is clearly apparent once one factors in proprietary extensions from other corporations like ATI, Matrox, STMicro, and the vast number of other companies currently offering OpenGL compliant drivers.

The age of OpenGL 1.x is the primary contributor to these limitations, as hardware has evolved at such a rapid pace over the past few years. System that were once considered to offer high performance only a couple of years ago are now entry-level configurations at best. The rapid development of hardware plays a significant role, as many manufacturers are adding OpenGL extensions without any real inter-corporate centralization in order to release products by usually grossly misrepresented retail availability deadlines.

Worst yet, it appears OpenGL is following nearly the same development paradigm as DirectX. DX7 was the last fixed-function D3D interface, with the current DX8 standard being devised around poorly coordinated implementations of programmable rendering options. DX8 offers v1.2 programmable options, while DX8.1 offers a slightly improved v1.4 programmable feature set. This development schedule can wreak havoc on developers and hardware engineers. For example, the GeForce-3 supports v1.2, but the Radeon 8500 supports v1.4. In can be expected that programmers will likely opt for the lowest common denominator when coding, thus it is suspect whether some of these staggered options will ever be included in software released in the near future. Only with the release of DirectX 9 does Microsoft plan to offer a hardware independent programmable interface.

Some developers have proposed extensions to OpenGL 1.x to add programmable rendering options including various extensions which may not be compatible with hardware from another manufacturer. Efforts are also being established to institute a generalized extension set for programmable shading, though these are still largely hardware dependant, thus they will not work with all OpenGL implementations. The goal of 3Dlabs' OpenGL 2.0 initiative is to create an uniform standard with a hardware independent shading language that functions with nearly all OpenGL compliant graphics accelerators.

OpenGL 2.0 Envisioned

3Dlabs hopes to address several key issues with its OpenGL 2.0 approach. OpenGL needs to evolve into an easier to code interface format with optimizations for memory management and timing control for increased performance potential. Another issue to be addressed is how to deploy generalized programmable shading routines which are hardware independent. The overall predominate concern is maintaining complete backwards compatibility with OGL 1.x standards while retaining the functionality of the new standard's advanced rendering options.

3Dlabs has received positive support from many facets of the graphics engineering community. Universities like Stanford are already hard at work on extended OpenGL rendering routines which support some of the v2.0 conventions. Most hardware manufacturers and software vendors are also expressing overwhelming support, as an improved OpenGL standard could lead to better graphics and performance with less development overheard and greater product turnaround times. Regardless of those involved, 3Dlabs is working towards a future OpenGL 2 interface without any imposed royalties or operating system limitations in hopes of establishing a wider market base.

OpenGL 2.0 Explained

The 3DLabs approach is to first extend software through utilization and public promotion of certain OpenGL 2 standards, then gradually move code towards a "pure" OpenGL 2.0 environment. However, unlike DirectX 8, all OpenGL rendering conventions should be available for those seeking a pure OGL implementation at release, instead of staggering the releases in various subset revisions. As stressed earlier, the ultimate final goal is to reach a streamlined programming interface which offers hardware independency.

Each of the programmable processor pipelines (software and/or hardware) essentially eliminate and/or replace a significant portion of current OpenGL conventions. The programmable vertex processor replaces the current options for transform, lighting, normalization, texture coordinate generation, and fog rendering. The fragment processor replaces the current operations for smooth shading, texture access, texture application, alpha testing, and pixel transfers. The pack/unpack processor included capabilities for flexible pixel formatting during memory move operations to create a coherent and consistent stream of pixel data to the rendering pipeline. The clear benefits of these programmable options are increased performance and image quality by removing the dependence upon fixed functions of static T&L pipeline routines. The associated rendering conventions for each of these advanced routines are unified through a comprehensive C-based programming language with special detail added for vector and matrix processing operations.

3Dlabs also implements a new data buffer mechanism to be utilized for enhancement of the programmable rendering interface. The buffer is used to enable multiple-pass fragment programs with full stream processing support. Usage examples include multiple outputs from a single fragment routine, intermediate result storage, multi-spectral imaging, and acceleration of back-end rendering by reducing the time needed for read-back of floating-point images by the host bus. Additionally, the buffer space is accessible through either spatial or FIFO memory operations.

Today's OpenGL 1.x provides no real direct control over when or where objects are stored or deleted within the memory address range. OGL 1.x also provides no direct control over memory copies or address fragmentation. 3Dlabs plans to implement a new management routine to allow for improved timing control over memory operations. The OGL 2.0 proposal sets policies and priorities for all datasets with timing estimates provided for each task. Additionally, all pinned policy operations allow the application to control memory store/delete and packing operations.
John Carmac's Opinion

"Given the good first impression, I was willing to go ahead and write a new back end that would let the card do the entire Doom interaction rendering in a single pass. The most expedient sounding option was to just use the Nvidia extensions that they implement, NV_vertex_program and NV_register_combiners, with seven texture units instead of the four available on GF3/GF4. Instead, I decided to try using the prototype OpenGL 2.0 extensions they provide.

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.

I am now committed to supporting an OpenGL 2.0 renderer for Doom through all the spec evolutions. If anything, I have been somewhat remiss in not pushing the issues as hard as I could with all the vendors. Now really is the critical time to start nailing things down, and the decisions may stay with us for ten years.

A GL2 driver won't give any theoretical advantage over the current back ends optimized for cards with 7+ texture capability, but future research work will almost certainly be moving away from the lower level coding practices, and if some new vendor pops up (say, Rendition back from the dead) with a next-gen card, I would strongly urge them to implement GL2 instead of proprietary extensions."

John Carmac Lead Programmer ID Software
Final Thoughts
OpenGL 2.0 is still in its development stages, though 3Dlabs does offer some insight into the new features needed for this aging standards to maintain acceptance within the graphics marketplace. As noted earlier, the concepts and ideas presented here are only preliminary at best. The information gathered for this article was obtained through various discussion overviews published by 3DLabs and associated companies. It appears 3DLabs and other developers are steadily moving forward with development of a new and exciting OpenGL standard that strives to offer the best compatibility with sustained performance across the widest variety of hardware configurations available.

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.

Success

[torre]

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.

Re:Goobers

[Mark Garrett]

Does anybody else get the impression that "MJ" works for "XtremePcCentral"?

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

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:GL/DX or C/C++?

[Osty]

(full quote, for the parent is at Score: 0)

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?

It shouldn't make any difference. Since C++ is a superset of C, you can use OpenGL just fine with it (and if you can't find one of the 092384092389 C++ wrappers for OpenGL out there, you can always wrap it up yourself). At the same time, COM has always been available to C code as well as C++ code, so you can use DX in C as well (it's just very ugly). In either case, I don't think the native language of the library should make a difference -- COM is supported by many languages (some requiring that the COM object support the IDispatch automation interface, but I believe DX already does that, and if it doesn't you can wrap that yourself or find bindings that somebody has already done), and thus DX is available (C, C++, VB, Delphi, Java, and all of the managed code langauges). OpenGL is written in C, which means it's easy for developers to write bindings for other languages (C++, perl, python, ruby, etc).

The moral of the story is that any properly designed library will be available across languages, so don't let the library tie you into a language you don't know or like.

Re:Too little too late?

[Ziviyr]

Yeah, ever since DirectX was integrated into the Linux kernel OpenGL has been dead. ...Huh?

Like many will point out

[bogie]

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.

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.

theory vs reality

[Anonymous Coward]

or should I say, Marketing vs Implementation?

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.

Re:theory vs reality

[ewhac]

Forgive me, but do you have the vaguest idea what you're talking about?

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.

This is the whole point of OpenGL. It also pre-dates DirectMess by ten years or so.

Silicon Graphics, the creators of OpenGL, originally wrote APIs for their workstations that were more or less hardware-specific. Every time they came out with a new machine, a new version of the API would come out, and all the apps would have to be re-written. After the fifth time or so, SGI got enough flak from both internal and external developers that they decided to write an abstract API such that the client software wouldn't know or care about the underlying implementation. This gave SGI the freedom to take features previously implemented in software and drop them into hardware, and the application would work without recompiliation.

The same principle applies to this day. Back when the first version of GLQuake was released, 3D-accelerated cards had one -- perhaps two -- texturing units. They also didn't have hardware transform and/or lighting. Now, graphics cards typically have four texture units, hardware transform and lighting, vertex shaders, full-scene anti-aliasing, etc. etc. etc. But that old copy of GLQuake id Software released five years ago still works. Heck, it even works better now. Which is the whole point.

What you describe already exists. It's called OpenGL, and it works.

Schwab

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:illustration of shaders?

[be-fan]

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:

- 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/page 4. asp
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.

I hope OpenGL doesn't die!

[krs-one]

If OpenGL dies, whatever shall I do with my site, http://openglforums.com?

Joking aside, I hope, and know that OpenGL will never die. Several reasons:

• Ease of use. With Direct3D, you have to set up all of that Win32 specific crap. Its a pain in the ass. You have to memorize all of those silly structure names and such (don't quiz me as I don't know any of them). With OpenGL, in VC++, you just have to include the right libraries (opengl32.lib, glu32.lib and glut32.lib) and your set to go. I'm pretty sure its similar on Linux.
• 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.
• John Carmack. Face it, the mans incredible. He's literally changed the face of graphics, but I'm sure everyone already knew that ;).
• 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.

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

Re:I hope OpenGL doesn't die!

[djohnsto]

Ease of use. With Direct3D, you have to set up all of that Win32 specific crap. Its a pain in the ass. You have to memorize all of those silly structure names and such (don't quiz me as I don't know any of them). With OpenGL, in VC++, you just have to include the right libraries (opengl32.lib, glu32.lib and glut32.lib) and your set to go. I'm pretty sure its similar on 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.

Misconceptions about OpenGL

[Anonymous Coward]

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.