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.'"
You can tell by the numbers!!
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.
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...
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?
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.
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.
Analytic & algebraic topology of locally Euclidean meterization of infinitely differentiable Riemmanian manifold
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.
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!
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*
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
Can you say: Prior Art?
Could someone please explain how shaders enhance a scene, and how to know if you're seeing one? I've done a fair amount of graphics coding (2d, 3d, splines, nurbs, etc) but I don't understand what shaders offer or how they really work.
Images that can illustrate this would be especially nice.
(And no, not all CAD/CAM happens on intel boxes, actually SGI has this market cornered, guess where OpenGL comes from?)
Actually, current SGI boxes have Intel(tm) inside. For better or worse, it's been that way for a LONG time now.
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...
Did you know that they ditched NT as a recommended platform? Those SGI Visual workstation you talk about come with Linux preinstalled.
And the SGI MIPS machines are still widely used. I used to work for a R&D company that did a lot of CAD/CAM. I had to administer those Octanes and Indigo's that were used as workstations for stuff like Alias Wavefront.
I also doubt that people working on a SGI IRIX machine would give it up that easily :) In fact, that same company wanted to use NT for CAD/CAM. I heard the phrase "They'll get my machine when they pry it from my cold dead fingers" a lot.
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
As a WineX user, I must disagree. /path/to/install.exe' and you're away.
The rpm installed (--nodeps) on my Gentoo system without a hitch. Then you type 'winex
Warcraft III under WineX is quite impressive, as is Black And White - even though it has some 'issues' on my system.
Of course native Linux games are preferable. But in the meantime, WineX Rocks!
OpenGL on playstation2
OpenGL on the Xbox
This is a great quote from the article, turns out OpenGL is superior than Direct3D on the XBox.
# of revisions != rate of improvement.
# of revisions != how good it really is now.
Old DirectX was craptacular, we all agree. new directX is getting there. *shrug*.
Who is this Anonymous Coward character, how does he post so much, and why is he always such a whore?
Even if MS did provide some kind of GL-like wrapper for Xbox, just to appease John Carmack (which, honestly, I don't think is as big a deal as you're making out, given the different market in console games) they'd be unlikely to offer it to developers in general simply because they wouldn't want to chew up resources supporting the fucker.
well, in theory.
As you rightly point out, redundant is appropriate so what's the problem?
Moderation is, conceptually, to categorize the pages on behalf of the reader; not manipulate the ego of the poster.
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
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.
1. Vertex/Index Buffers
The only way to store geometry data on the video card is by using extensions. To make matters worse, you passs nvidia's extension a couple floating point numbers and it magically gives you a block of memory if it feels like it, or not. Then this is the only block you get. Its up to you to write a memory manager on top of it
2. Documentation / Extension system
First, there hasn't been any HTML or even plaintext specs of the newer APIS. The PDFs look like ASS because of the pdf fonts. Second the extensions are made so that they are incremental updates to the manual "insert these lines into section 4.3.10" This helps no one use the extension. Why can't they just be explained in full. Plus, the least important fields such as the "issues" should go towards the bottom of the spec.
3. Arcane extensions with arcane (or no) docs
i'm talking about stuff like the nvidia register combiners, fence, vertex array range. And a powerpoint outline doesn't do the job explaining these.
The gameboy is a handheld, not a console! I'm talking about real consoles, like the PSX, PS2, XBox, Gamecube, Dreamcast, etc.
A deep unwavering belief is a sure sign you're missing something...
For me, the coolest feature of OpenGL 2.0 is hardware independence. This means that an OpenGL 2.0 driver will work with any OpenGL 2.0 card; no more need for drivers specific to one video card. Vendors will probably implement all kinds of extensions in their hardware that do need specific drivers, but the basic functionality would Just Work (WOW). This may not matter much for game || app developpers, but it matters for the end user, especially when this end user is using some alternative operating system. I know that myriads of cards that do accelerated 3D don't do so under Linux, simply because no driver has been written for them. This is going to change once cards support OpenGL 2.0, and I am looking forward to that, as none of the cards I have worked (with accelerated 3D) last time I checked, even though all of them support OpenGL. Yes, I know some are going to say that I should have bought different hardware, or written a driver myself. You are right. I am cheap. I am lazy. I want OpenGL 2.0, cause then it'll Just Work (WOW). Cheers!
Please correct me if I got my facts wrong.
Joking aside, I hope, and know that OpenGL will never die. Several reasons:
To summarize:
I love OpenGL and everything about it. I know it will never die. Its an incredible API, and although its slow to update, I'm sure OpenGL2.0 will kick ass.
-Vic
Let people worry a few more years about DirectX and OpenGL 2 features and see how things shake out; then, those things may be mature enough to be widely used and built on. Until then, a good OpenGL 1.x implementation is all I want.
Um, PC games, which load from the hard drive, use in game engine cut scenes as well. Modern consoles have enough memory to handle loading FMV video. Heck, the PS 1 platform was full of FMV games. However, gamers just prefer in game cutscenes because it preserved the realism and feel of the game. You're really arguing minutae here and missing the main point.
A deep unwavering belief is a sure sign you're missing something...
If memory serves me correctly, the game was written around Voodoo 3 cards and GLIDE. The rest of the 3D accelleration was kinda just a cheap add-in. Software 3D mode will suit nearly all other cards best in that game. I don't think that it is something that Blizzard has ever addressed.
Correct. John Carmack made a post on slashdot which nulled many of the statements he had about earlier versions of DirectX.
The comment can be found here
Check in your user preferences, homepage tab, and make sure that the 'Willing to Moderate' check box is checked.
Ho! Haha! Guard! Turn! Parry! Dodge! Spin! Ha! Thrust!
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.
Anyone know when DirectX 9 is due? About a month ago, I heard it was on target for November release, but now I see no sign of it. Any news?
.NET managed runtime (except for DirectShow and DirectMusic), which I am interested in experimenting with. My hope is that the interfaces will be "compatible" with the .NET environment best practices... no more 100 character constant names in all upper case and that kind of thing... and therefore hopefully easier to program and use for a DX beginner.
DirectX 9 will supposedly add direct interoperability with the
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.
OpenGL is essentially a giant state machine. You issue a glTexture() command and now everything is drawn with that texture. Anything... from bound texture, to blending function, to rendering triangles vs. vertex arrays, is a state that can be changed. Whenever you render some fancy textured, lit, alpha-blended scene, with different materials (say, Quake 3), there are a LOT of potential state changes.
State changes are SLOW, and so anyone hoping to render mildly complex scenes had better find a better alternative to resetting the state for every object in the scene. Well, there is... lazily update the states (only change the states that need changing, instead of manually setting every one). You could even go one step further and sort how you render your objects based upon state, so as to cause the least number of changes possible.
Today, OpenGL drivers DO NOT KEEP TRACK OF THE STATE. They just merrily pass the state-changing function calls along. Thus, the programmer is forced to go through the tedium of creating some abstraction of OpenGL states, and tending to it themselves. This is frustrating boring work, there is no reason this shouldn't happen transparently!
VTK is (or at least was, last I heard) guilty of not managing states lazily. A professor around here was working on a project to render from VTK to a large tiled display, which he did by more or less replacing the opengl driver with his own custom tile-display creation. It just happened to lazily update states. The end result was the uber-demo-model displaying smoothly on the tiled display, while chunking along at 10-15 FPS on the actual computer monitor!
OpenGL implementations need to keep track of their rendering states, not just send the requests off to the card!
- spiff
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
Did the Sega Genesis format cease to be a "console" format when the Nomad was released?
More interestingly, Did ENIAC become a PDA when it was emulated in JavaScript on the Zaurus?
My other account has a 3-digit UID.
As long as there are 3d modelers out there, there will be OpenGL.
DirectX doesn't even support quads!
DirectX's lack of quad support kills you when you're working with NURBS.
And also (correct me if I'm wrong) I thought that OpenGL had to be integrated with the operating system. When MS dropped support, they effectively froze progress for OpenGL on that platform.
You are wrong. OpenGL drivers are just that, hardware drivers. Updating OpenGL on Windows is simply a matter of replacing a DLL. Microsoft's support or lack thereof simply means that those DLLs will have to be written by 3d parties.
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...
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.
This is a late post, but everything else I've seen is games-focused. But don't forget, games are not the beginning and end of graphics, no matter how dominant a subset they may be.
There are things other than games that involve graphics, even 3D graphics.
This is waaaaay more important then what games are developed, where. This amounts to the tail wagging the dog. We potentially have games making platform decisions for serious simulation, physics, and engineering CAD.
The living have better things to do than to continue hating the dead.
Many years ago (now), I worked on D3D at Microsoft. ,and 1.3 and below are nVidia. Pixel shaders prior to 1.4 are awkward, t say the least.
The constrasting APIs are quite different in their approach, but both have the same aim - that is, to enable 3D rendering on hardware devices. A few comments...
Extensibilty.
The only reason why D3D is not extendable is a decision made within MS. The underlying DDI (Device Driver Interface) supports extensions (I should know, since I designed it originally), but MS decided a long time ago not to expose them to the user. From the OpenGL perspective, you have to watch for 'proprietary' extensions that are, for licensing reasons, unlikey to be generally supported.This leads to a lot of vendor specific code.
Philosophy.
OpenGL, except for extensions, is very hardware transparent. You don't have to worry about capabilities, at least as far as the basic code goes. The driver (or more commonly library) emulates those things it does not do natively - as a result, OpenGL is more portable to new hardware than D3D is - in theory, an OpenGL implementation could be entirely software driven, and you wouldn't know it.
D3D, on the other hand, was designed originally to expose as much of the hardware as possible. In theory, this would allow software writers to only use those things that were really accelerated.
But as hardware has become more complex, the OpenGL model (with it's assumption that everything is fast) becomes more compelling.
User level code.
OpenGL runs at user level, and that gives it a significant advantage over D3D, which is a mix of user and kernel. Due to the lack of context switches, OpenGL can almost always beat an equivalent D3D implementation, no matter what batching of primitives D3D tries to do. In thoery, there is no reason why D3D could not run in the same way, but in practice the powers that be at MS have decided otherwise. I happen to believe this is a loss for MS, but who am I to decide.
Shaders.
This is the area of most contention between D3D and OpenGL. The D3D model is based (almost certainly) on the nVidia model, whereas the current OpenGL model is purely based on extensions. We get into awkward territory here, since the ATI and nVidia extensions are markedly different. This is exposed most obviously in the D3D pixel shader versioning, where PS 1.4 is ATI
Support.
Microsoft supports OpenGL beacaue it has to, not because it wants to. Back in the early days, there was a possibility that support would be dropped, but sensible (i.e. a few) people in MS knew that it was a requirement for those areas MS was most keen to be in - for example, Workstations.
The Future.
I have no doubt that both APIs will continue to be expanded, with D3D lagging slightly because of the afore mentioned differences. OpenGL 2.0 may resolve some of the conflicts, but given it's heritage (3Dlabs), it's possible that it may be further from the real major hardware (ATI and nVidia)than the extensions. As they say, it's impossible to please all the people all of the time.
Tribes had the same behaviour; it was designed for Voodoo cards, then had an OpenGL renderer built. Well, Voodoo cards kicked ass at memory transfer, or somesuch, which Tribes took advantage of. So the OpenGL port would stutter like a bitch on hardware that was over-all superior to the voodoo1.
Vintage computer games and RPG books available. Email me if you're interested.
In addition to OpenPlay as others have mentioned, don't forget about SDL_net, a networking component for the fabulously cross-platform LibSDL. I've often felt that Apple should contribute directly to SDL rather than work in parallel.
I probably dislike it because I'm learned C++ first. Hungarian notation just isn't popular in C++ circles. That aside, it also probably has something to do with it's association to the phenomenally bad naming conventions of Windows code. You've got stuff like ALLCAPSSTRUCTURENAMESWITHOUTSPACES, member variable prefixes half a dozen characters long, random made up acronyms, ugh... Windows code is phenomenally difficult to read, and Hungarian notation doesn't make things any clearer.
A deep unwavering belief is a sure sign you're missing something...
Nice strawman. Comparing playing a game to building one. Wow. Building is harder. Thanks for the update, I never would have figured that one out on my own.
Not to mention, of course, that I have hundreds of games on my Linux box, so a direct playing-to-playing comparison doesn't work either...