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.
That is why this story is on the front page.
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.
Whens the last time anyone wanted just Direct3D?
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!
And all this time he has been calling using the name Carmack ... the cat is out of the bag now
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!
If you consider the goal of Open-GL is to become the preferred API for 3d games on Microsoft windows, then by any measure it has already failed.
However the goals of Open-GL have always had a much broader scope. Unless someone can name a API that's more open, more standardised and available on more platforms, I can't see how Open-GL could fail.
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
OpenGL 2.0 while promising, is destined to fail.
Woa, what do you by fail? If you mean fail to be:
The only available Graphics library that works on 10+ platforms.
Be the GL of choice for 99.9 percent of the scientific community.
Well I got news for you pal, it already is. The 2.0 architecture will only increase its power. Will it become the most widely used API for games on the windows platforms? not right away, but if you'll notice, there are far more tutorials for OpenGL than there are for DirectX out there. The interest is there and the OGL dependent talent base is growing.
Even then, who really cares if OGL doesn't dominate the windows market, what it does is create an incredibly powerful platform for game developers on linux. I could care less about DX's success or lack therof, I want good linux games.
stdcallsign (aka LanRover)
DirectX is no industry standard. OpenGL is. Killing off OpenGL is VERY hard to do.
Unless you have some help from the patent office. What are the odds Microsoft has a pile of DirectX 9 software patent applications slowly wandering their way through the USPTO?
If you say, "now I'll be modded down because of X", I'll happily oblige.
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 got the impression that MJ just cut'n'pasted directly from HardOCP. Word for word. I kid ye not.
SGI dropped Intel after the PIII
SGI finally saw the light. They returned to the MIPS architecture after failing to compete successfully on cost with their Intel "solutions."
your vision is crystal clear, if it hasn't been strangled yet il will, if it already has there's no chance it can pick up. Man, I hope you haven't painted your house windows in stupid RGBY colors! Oh, go to your fav store and let M$ screw you, after all it's your wallet that's getting raped... wait, it's fools like you that got BeOS killed (never mind the last mismanagments, it's like those last contractions when a living being passes away) or that keep M$ fat living off those viral vectors like OutOfLuck or Office... next thing, we'll lose control on multimedia formats thanks to those million fools using MediaPlayer. Heh, guess that DE-COMMODITIZING strategy moved up the stack-layer... in Italy we say: "La madre dei fessi è sempre incinta" Good night (ahhh, once in a life it's fun to drop a flamebait)
Mi domando chi à il mandante di tutte le cazzate che faccio - Altan
Not only was this article a total letdown, a mysteriously (*wink wink*) similiar thing was posted somewhere else. Take a look at [H]ardNews 3rd Edition for tuesday on [H]ardOCP. I guess it's a little too much to expect from editors to look around the internet, but never the less, it seems stupid to totally rip something from another site directly, especially when the article sucks =).
But what comes after 9?
DirectX X
before you mod this down...
I have an Excellent rating and have for a while yet I never had an opportunity to moderate. Question: Is moderation selection a rare event? How often does it occur? Do you have to sign up for it?
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.
Viva Italia!!!
GCL-GL.tar.gz: OpenGL/Mesa and Xlib bindings for GCL (Gnu Common Lisp).= &ie=UTF-8&oe=UTF-8&selm=MANN.96Dec12144405%40orasi s.vis.toronto.edu&rnum=1
http://groups.google.com/groups?q=gcl-gl&hl=en&lr
http://www.cs.toronto.edu/pub/mann/Software/Lisp/
Mesa is a "more free" version of SGI's OpenGL.
he talks about the patent troubles in the development of OpenGL.
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.
But seriously now, I wonder if people 20 years down the road will come play games like Quake III with their highly advanced computers, much like people still play Pong and Space Invaders.
Just my two cents.
--- WAL
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
i know i do.Re:John Carmack?
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.
While it may not be an official standard like OpenGL has its ARB, it is basically a standard in the PC Gaming and now starting in the Concole Gaming industries with the XBox.
How gives a flying fuck about the scientific community. MS doesn't really appeal to the scientific community (as in large networks for modeling whatever). They appeal in the DirectX sense to the home market. By them supporting OpenGL instead of DX, would make them very little extra cash compared to what they have with DirectX.
If they had always supported DirectX, *nix-ers would probably hate them more. More people might be leaving *nix and going to Windows since OpenGL is available there too.
I've never used DirectX. You mention DirectPlay as if it didn't really have any good alternatives. OpenPlay is an alternative high level networking API. I think it is available for Windows, Mac, and Linux. You should be able to write games that has networking between them and OpenPlay will deal with the Big Endian/Little Endian stuff. It is open-source. I've used it on my www.idevgames.com game contest entry and I didn't find any problems.
a y/
http://developer.apple.com/darwin/projects/openpl
# 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?
That's what always happens to the elitist computing types.
It's like the rabbit and the turtle fable or whatever...
The PDP-11 people used to do it, and now the unix people do it too.
Everyone was so busy laughing at direct X when it first was released they never bother to work on openGL. Until one day DirectX was actually more powerful than OpenGL and more widely used. Now the elitest types are trying to play catch up when they used to have a huge lead.
The same thing happened with browsers. Everyone used to laugh at Internet Explorer 1. And with good reason. It sucked, badly. But then things heated up but people still thought they could just keep ridiculing the old IE and not noticing it improving. Then netscape basically stopped all development essentially no progress was made, much reinvention of the wheel (Mozilla) is not progress and now IE is the browser of choice. Sorry but actually shady business practices had less to do with the fact that IE 5.5 was actually good while netscape 4.762342344..... was stuck on 1996.
Anyways don't get so cocky laughing at Microsoft that you don't stay vigilante or they will blow past you. Sorry but it is true.
I know some hardened old unix guy will say "bah microsoft still sux0rz" well have you really used any of it lately or are you still making fun of windows 95?
Hey the PDP-11 people did it too..."PCs are crap, no one will use those peices of shit for anything important" Haha, now it's just big racks and racks of PCs and no big "Professional" system in sight.
The unix world had a long head start on windows on so many fronts but squandered laughing at microsoft and strutting about. Microsoft kept developing and fighting for market share while the unix world sat on it's laurels.
Now to really sinch the negative moderation let me also mention this turn of events in computing. The BSD people do the same thing. Bashing Linux as a "toy" os just becuase BSD had been in development for several more years. Now which is the more featureful OS? Despite the empire has no clothes attitudes of the BSD population those OSes are playing catch up to Linux on several fronts and on close examination many of their claims to fame are really no so great when faced with an honest comparison of Linux.
Oh well the moral of this story is the same as the Hare and the Tortoise or whatever it was called...
"They have cool looking leap frog graphics with lots of arrows"
We all know pretty graphics and arrows make a presentation good!
I can assure you that there is no OpenGL support on Xbox
Halo is old, and Metroid Prime for GCN is coming out. Microsoft desperately needs a first-person shooter. If Microsoft wants Doom 3 for Xbox, Microsoft will make sure that Carmack has his OpenGL.
Will I retire or break 10K?
The last time I heard of actual progress on the OpenGL 2.0 spec was around 4 months ago, with the release of a transcript from one of the ARB meetings. It contained mention of Microsoft requiring compensation for IP it owns that is contained in the OpenGL 2.0 spec. This is particularly icky since Microsoft owns many of "shader" patents that used to be held by SGI - the advantages of having billions in cash on hand, I suppose. I do not know if Microsoft requires payment from the card companies to release DirectX drivers - they certainly would use the same IP - but one can imagine that MS really doesn't have much reason to discourage DirectX development. And it does have a few reasons to discourage OpenGL...
consoles haven't been space constrained since 1995
Current Game Paks for the Game Boy Advance handheld game console are only 8 megabytes in size, the same size as the first N64 games.
Will I retire or break 10K?
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
I know some hardened old unix guy will say "bah microsoft still sux0rz" well have you really used any of it lately or are you still making fun of windows 95?
No, I'm making fun of Windows XP, which can't be slimmed down much tighter than 128 MB of RAM, as opposed to GNU/Linux which is comfortable with well under 16 MB. Thus, Linux (especially uclinux) beats Windows on handheld and embedded devices.
Will I retire or break 10K?
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.
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.
Hasn't that crap gone on in the browser war for years?
"New Netscape 6.0!"
"Wait a tic, where's 5.0?"
"Uhhh... here's Netscape 7.0!"
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
is the man.
I want to bare his children!
The gameboy is a handheld, not a console!
The dividing line between "consoles" and "handhelds" isn't as sharp as some would think. Did the Sega Genesis format cease to be a "console" format when the Nomad was released? Was the Game Boy still a "handheld" after peripherals such as Super Game Boy and TV de Advance were released? OK, I'll constrain my discussion to DVD consoles.
PSX, PS2, XBox, Gamecube, Dreamcast, etc.
Even on the disc-based consoles, if you stream in music while the game is playing, you won't be able to stream in sections of the map because the read head can only point at one part of the disc at once. That's why some games for GCN, PS2, and Xbox still use tracked music, because it makes the "loading" stall shorter. In addition, doing cut scenes with the game engine rather than with FMV gives the game even more time to stream in a large chunk of level data.
Will I retire or break 10K?
All i can say about this is using my voodoo 3 2000 OC'ed to 233 and OpenGL, i was pullin 80-90 fps just standin idle in Diablo ][. I went out and got me a GF3 Ti200, thinkin it was gonna easily be over 100 fps. Wrong. First it forced me to use DX8. Was only givin me like 30 TOPS, and skippin frames like crazy whenever i moved. This was with the stock driver that came with the card, so i went and got the latest ones, thinkg that it would perform better. SYNTAX ERROR: Try using '-please' next time. My hunch is that either i need a new mobo w/ a faster AGP slot/CPU(1x/PII 450 at the moment) or somehow figure out how to make this game and card work together under OpenGL. I cant wait to try OpenGL 2.0. Just hope D2(and my card) is supported(or vice versa).
-D
-D
AFAIK the PS2 and GC both have proprietary graphics libraries (and in the PS2 case, not much of a library at all).
But what about SDL?
The US Army: promoting democracy through unquestioned obedience
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.
What ever happened to those problems the OpenGL board was having with Microsoft and their patents on Pixel Shading? Have these issues been resolved in OpenGL 2.0?
-- -=innocent ramblings from the mind of an insomniatic programmer=-
Looks like you have found the elusive Mrs. Goatse.
I don't know anything about DirectX or DirectPlay. Admittedly, I'm a server programmer; not a client programmer. However, it's interesting that this comment was made nearly the same day as Joel "MicroSerf" Spolsky bemoans that all non-trivial abstractions, to some degree, leak and it's dragging us down.
Doug Alcorn
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
No, there are some real patent issues. The original work wasn't done my microsoft of course, but rather SGI. MS bought some of SGI's patents not so long ago. These bought patents are the ones MS is using to cause trouble with OpenGL2.0.
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.
right, diablo 2 doesn't have a bit of opengl support in it at all. It was originally written for 3dfx's proprietary api GLIDE, which no longer exists because there are no more voodoo cards.
Direct3D support was added later to appease the rest. Also because by the time Diablo 2 was done getting delayed every other quarter 3dfx was pretty much bankrupt and a 3rd rate player in the graphics industry.
The first implementation in D2 didn't even work for most cards, and vastly superior Geforce2 cards performed abysmally.
So the posters voodoo card really does suck, Diablo 2's code really does suck, and you're not going to find a way to run Diablo 2 in OpenGL. But you CAN use a GLIDE wrapper driver on your Geforce3. I dunno if that's worth it, though.
"In summary, if you want a cross-platform DirectX alternative, there are options. You just have to know about them or search them out."
Riiiiiiiiiiight. I think I'll just install Windows XP and say I did.
I'm actually playing the video game I bought. What are you doing? Oh, still compiling some library and trying to get it to work... LOL.
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
Most people have dropped SGI or are in the process of dropping em (Pixar, ILM for example, altough converting those proprietary IRIX applications/script is taking some time), they don't own the high end graphic market anymore, it's overpriced and it's slow hardware compared to what you can get with Linux and PCs. Have done work on an Octane or even an O2? It' so pathetic compared to a machine now costing 1/10 of the price.
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
I thought Microsoft had dropped support for OpenGL a long time ago. 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. If the changes are as widespread as it seems, what's to stop Microsoft just not updating their graphics code to compensate?
nope. guess again.
HINT: it is your mom giving birth to your nigguh bruthus and sistuhs
Hungarian notation aside
Why do you dislike Hungarian notation?
It is my experience that there is nothing fundamentally wrong with using it, provided it is applied carefully. Admittedly the full Hungarian Microsoft recommendations can be somewhat stupid when it comes to more obscure data types (such as long pointers [since short pointers are obsolete in most 32-bit coding]; bytes vs bools [both possibly using a 'b' prefix..]), so I tend to use simplified mappings most of the time, eg:
p = pointer (to any type, without the type that is being pointed do, eg: pData); i = 32-bit data (iValue), ch = 8-bit byte (chString); s = struct (sStruct); c = class (cObject).
You get code that's like this:
iStatus = cGizmo.Activate(iOperation, pData, &chShowText);
Neat, huh? It's really easy to tell what sort of argument is being taken at a glance.
Slicing 3D textures is the most crappy inefficient way of rendering volumes ... it's used because it is the only thing you can efficiently accelerate on hardware, but you could do a lot better in hardware (you would need support in the API of course, that is what he is asking for).
I remember when the Quantum3d Obsidian2 X-24 was released at $700.00 US at my local electronics store. And later I remembered Creative Labs released the Banshee at about $300.00 US. Enter nVidia, and the Voodoo3 competed with the TNT2 at about $150.00 US each. The GeForce came out at $175.00 US and the Voodoo5 crawled out of 3Dfx's ass at $300.00 US. But back to the Voodoo2; the revolutionary graphics adaptor: first adaptor to offer anti-aliasing on the polygons. Hell, you can buy a standard 8mb voodoo2 for about $10...the Quantum3D Obsidian2 X-24 is still a pricey fixture at no less than $70.00 of which some stocks are still available in OEM! Go check http://pages.ebay.com/catindex/computers.html for voodoo2 and be amazed...XFree86 added some nice XFree86-4.2.x support for using the Glide3x driver on a Voodoo2 for a second simulated 2D XServer head; nice!
I SED buy msft stock NOW. my Portholio is not diversfried. eat my corn more and manchode miniwheetmeel, for great justiss
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.
DIRECTAL X IS BATTER THAN DIRECT 3D. DIRACTX HAS DIRECTDRAW and it has Direct3D and DirectPlaytoy and directshowandtell. Direct3d is not just enough good. why i say you not, you understand good. for great justiss, microsoft is bested edineer of APE EYE in mocket compooter grAphicks wold. so by msft stahk today and go somwar toomarow.
i kid you not. you are his illegitimate child and he has no time for you so don't ask for college money because he spendid it all on his compooter games and he is a harry potter and star wars and lords of cox rings fan. you no not what you doing for great wold. i ake on head you why not get sirrup for I take yu to bathrom and rectal ape you in ass why yu doing not now get move assh0le. glad yu no and yu get smott and get own skul and job. yu not smot as tofu an i eat cabadge
for multiple types of mormulas (spelling incorrect deliberately).
PS If you're going to compare DX9 to OGL, I think you should compare it with the OGL 2.0 standard proposed, else you should compare with DX7 or 8.
Ta.
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...
There are more OpenGL tutorials because there is no definitive all in one answer to how to do things in OpenGL. With DirectX there is the massive help file that helps you do things you only dream of. With OpenGL there is Googling for hours finding source that actually works and then figuring out why it works.
OpenGL is also just a rendering mechanism, more than likely when developing a game you are going to use some part of DirectX. Once you learn the setup routine for one part of DirectX, the rest become a walk in the park. If OpenGL could be that easy, and come with a great help package that included step by step tutorials, then it would be a lot better off.
-]Phreak Out[-
DX9 will released early december. You can already download the RC0 from Microsoft site at http://www.microsoft.com/downloads/release.asp?Rel easeID=45160
But when OpenGL 2.0 will be released ? Is beta version available ?
Yesterday, i've seen a demo for Radeon 8500 using the new ARB_fragment_shader extension (See here http://humus2.campus.luth.se/%7ehumus/)
But didn't work with the latest ATI driver !
In a word : you can't do pixel shader correctly on OpenGL.
On day, you have to use NV_fragment_shader and ATI_fragment_shader which are differents, then you heard that there is now an ARB function. So you, developer, drop you NV/ATI code but in fact the extension is not available in all drivers. So you have to maintain the 3 versions of fragment shaders code.
And the fragment pixel shader assembler code is not the same as DirectX, so you can't write an engine using one pixel shader assembler code and able to use OpenGL or DirectX.
It's frustrating and people prefers to move to DirectX Graphics instead of OpenGL or to stay on OpenGL but doing Direct X 7 stuffs.
I need a Sino-Logic 16. Sogo-7 data-gloves, a GPL stealth module...
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.
I am just working on what i was told when i was given a v3 once. I thought that the 3dfx cards didnt use opengl as such. Didnt they just have extensions to their GLIDE drivers that emulated opengl commands, allowing non GLIDE games to run on GLIDE cards (3dfx mini-gl driver???)
:) )
I remember performance being sweet in halflife on my 300 with a v3 3000 AGP (45 fps with night vision on in opposing force
Its got to the point now that few new games support 3dfx cards. I know several people that had to rename certain game exes as quake3.exe and use a 3dfx wrapper called wicked-gl to make the games run (jedi knight II and moh allied assult methinks?)
Seb
I've used Microsoft products beginning with DOS and now up to XP. I have more recently begun to use Linux (redhat & debian). I may not know too much about Linux yet, but it is far easier to fix something under linux than it is to fix it under XP. In an effort to cater to those less literate in computers, Microsoft has obscured and hidden configuration settings and critical files to the point where it is almost impossible for someone who knows what they are doing to get XP to operate in the fashion they expect. Furthermore, XP tends to keep multiple records of what you have done on the system, and what documents you have accessed, creating unnecessary files that fill up your system and can be difficult to track down and remove. The last decent Microsoft system was DOS, and that they bought (or stole).
Life sucks, but death doesn't put out at all....
--Thomas J. Kopp
could I please score a zzero on a post please
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.
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.
While Direct* almost certianly has more documentation/books/samples than any of the Open?L libraries mentioned above, the vast majority of them are open source. And just because you CAN build them yourself doesn't mean that you HAVE TO. You can get binaries at all the sites I checked.
So you can go play your game. Great. A DEVELOPER has to get the library to work, regardless of which library it is. And there is always a learning curve to climb, no getting around it.
So LOL right back at ya.
Neener neener.
Fooz Meister
I'm not familiar with DirectShow, but from what be-fan is saying it sounds like QuickTime is a comparable technology. QuickTime may even cover DirectMusic.
Granted, QuickTime isn't open source. But it's been around for ages and supports plugins for extending media support. It has certainly been around for a lot longer than Windows' "innovative" media architecture.
---Joe
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.
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
What are you talking about? Lets go one by one:
"Object picking": what are you referring to? If by "object-picking" you mean figuring out what object is (say) under the mouse cursor (in other words, a line intersection test with your 3D geometry), this is not exactly difficult, and if you are writing a 3D app should be less than 1% of your entire work, if you can't even do that, you're not going to get anywhere anyway. Direct3D doesn't have "object picking" either. Or are you talking about something else entirely?
"coplanar geometry (lines on top of polygons)" - uhm, what problems does OpenGL have with this? There are none. Are you perhaps referring to "Z fighting" problems with polys and lines rendered to same Z? Once again, if you're doing this (and not disabling z test for your lines), you are doing something direly wrong. I hate to be the one to break it to you, but hardware like NVIDIA use the SAME internals to draw polys and lines, regardless of whether you are using GL or D3D. If you are seeing Z fighting in GL, you are going to see Z fighting in D3D too. I don't see how this is a "problem with OpenGL", this is a problem with your code.
"Poor typography support" .. hello? D3D doesn't have "typography support" either. Unless you're trying to use GDI calls to draw text, which is not only a slow and stupid thing for a 3D programmer to do, it is (thankfully) not even possible anymore since DirectX8 - Microsoft thankfully removed the "GetDC" call from surfaces.
why does OpenGL not specify things like raytraced and radiosity lighting models, along with voxel primitives
Because these are not possible to do quickly on todays hardware in real-time, and if they did this, it would thus kill them. That would be dumb.
features for window and page oriented output of arbitary geometry
As far as I can tell, this statement is meaningless, you're spouting out your nose.
Quit spreading FUD to poor /. readers who don't know better than to mod your post up because it sounds like you know what you're talking about clever. Feel free to call me on anything I've said, I've been working in 3D for many years now.
tc wrote,
even if both of the Mac owners buy your game you'll never recover your costs
Enough snide unsubstantiated remarks. If you'd done your homework, you'd find some facts like this quote from MacSoft's Peter Tamte:
As many of you know, we were ecstatic about the success of Duke Nukem 3D for Macintosh. Duke was profitable for us on its first day of sales, and it caused many retailers to tell us how pleased they were by its performance. The initial success of Duke Nukem not only proved to the country's biggest retailers that the Mac games market is healthy, it also proved to them that there is a huge base of people just waiting to spend money in their stores for great new Mac products.
Well, here's more good news. As outstanding as the sales of Duke were during its first two weeks of sales, retailers are reporting that Civilization II has sold 73% more units during its first two weeks of sales than Duke did. Wow!
That's right: the cost of porting Duke Nukem 3D to the Mac was recovered in the first day's worth of sales. Other houses like iD and Blizzard continue to faithfully develop for Mac; not for their health, but because it's profitable.
That that is is that that that that is not is not.
thank you, you just convinced me to put my Voodoo back in, in favor of the GF3, solely for the performance gains i will get in diablo 2. you are right. FUCK PROGRESSION!!!!
-D
-D
Depends on whether you're talking established shop or new outfit.
Depends on whether or not the established shop is financially strapped and trying to cut costs on new hardware.
If I were in either category, versed in the business, I would at least consider whether commodity hardware/software was up to the job, yet. Many times that answer would be/has been "No," but consider the invasion of Linux into render farms over the past few years. At some point, for some number (probably a growing number) of applications the answer will be, "Yes," over the next few years.
So examine three questions:
1: Can the hardware do the science/engineering 3D graphics job?
Increasingly, commodity hardware can.
2: Can the software on the commodity hardware platform do the job?
IMHO, same answer as above. It's very possible that Windows scores better than Linux on this one.
3: Can we move our business to the commodity platform cheaply and with minimal disruption?
IMHO, this is the key. It's also the strong point for Linux, since "legacy" is most likely SGI/OpenGL/Unix, as you say. It would be easier to move to Commodity/OpenGL/Linux than it would to Commodity/Direct3D/Windows, assuming capabilities are sufficient.
That's the key, "assuming capabilities are sufficient."
The living have better things to do than to continue hating the dead.