Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Graphics Software

3D Labs Proposes OpenGL 2.0 To Kick DirectX 196

Posted by Hemos from the rolling-out dept.
furiousgreencloud writes "3Dlabs is trying to drive the graphics interface away from hardware specific extentions, as seen in DirectX. Instead, they are proposing an open (no NDA) dialog on OpenGL 2.0. The guidelines mention good-ol-fashioned platform independence (linux included) and emphasis on programmability, time control and memory managemenmt. They've got a PDF availible for consumption."
This discussion has been archived. No new comments can be posted.

3D Labs Proposes OpenGL 2.0 To Kick DirectX More

3D Labs Proposes OpenGL 2.0 To Kick DirectX

Comments Filter:

  • Nvidia makes games eventually. (Score:3, Interesting)

    by minus23 ( 250338 ) on Monday September 24, 2001 @10:51PM (#2345104)
    Soon we'll have Nvidia making games tho I'm sure that will be created on a proprietary system even more stringent than where we are now. You don't think so? --- Example: ... "It's the hottest game of the year and they don't take ATI." (Sung to the toon of a Visa comercial. It's in Nvidias best intrest to make this happen. Tho maybe not in the markets best interest.
    • you mean something like Glide? Hell, they own 3Dfx now anyways.

    • Re:Nvidia makes games eventually. (Score:4, Funny)

      by bonzoesc ( 155812 ) on Monday September 24, 2001 @11:14PM (#2345171) Homepage
      minus23 gathered up his thoughts and spouted this out:
      Soon we'll have Nvidia making games tho I'm sure that will be created on a proprietary system even more stringent than where we are now.
      Oh, the X-Box.
    • Nvidia will make a game console and screw MS. they will take nForce tech, put a GForcex(what ever is the best at the time) put it in a box, and sell it as a game station.

    • Re:Nvidia makes games eventually. (Score:4, Insightful)

      by Glock27 ( 446276 ) on Tuesday September 25, 2001 @09:35AM (#2346585)
      Soon we'll have Nvidia making games tho I'm sure that will be created on a proprietary system even more stringent than where we are now. You don't think so?

      No, I don't. The culture at NVIDIA comes mainly from an SGI background, so OpenGL is something of a religion there. Further, unlike some companies, NVIDIA seems to understand the positive feedback effect of open APIs (just not Open Source, yet).

      So, NVIDIA will have to be content with the current situation: "It runs at 30 FPS on the Radeon, but at 80 FPS on a Geforce 3!". ;-)

      --- Example: ... "It's the hottest game of the year and they don't take ATI." (Sung to the toon of a Visa comercial. It's in Nvidias best intrest to make this happen. Tho maybe not in the markets best interest.

      The current (OpenGL) situation is one where vendor-specific extensions are used to expose advanced functionality (shaders primarily). This means diffent paths through large portions of OpenGL based rendering engines. This is actually closer to 'NVIDIA specific' games, but NVIDIA knows that ISVs will just migrate to Direct3D where those features are properly abstracted. DirectX 8.0 has incorporated these features into the base API (and NVIDIA is just another player there, although it had a hand in defining the spec - just as it will with OpenGL 2.0).

      OpenGL faces losing many ISVs unless there are standard ways to access these features. THAT is the motivation behind OpenGL 2.0. If you want strong, cross-platform 3D capabilities, do whatever you can to support OpenGL. OpenGL 2.0 looks like a great evolutionary improvement, and should continue to spank Direct3D in most respects. It certainly will in the area of Linux support. ;-)

      If you're interested in OpenGL programming, there are many great resources on the web, including the The Official OpenGL Site [opengl.org] and The OpenGL GameDev Mailing List [geocities.com].

      299,792,458 m/s...not just a good idea, its the law!

      • I agree with this person - mod him up.

        if you've ever written code for it, the nvidia is sweet - and they rock with opengl and directx, so I'm not entirely sure why they would then close all that down all for their own stuff. nothing points in that direction now.

        slashdot has plenty of conspiracy theorists on it, that is for sure.
    • contrary to what many seem to think, it's not so easy to monopolize an industry (MS won theirs through finance when all the other players were busy coding). I know that *I* wouldn't code for Ndiva cards only, and neither would any other programmer who had to put food on the table. Even games which were Glide driven had a software mode (and usually a d3d mode too)

      The market has made much more money by being open and allowing competition than by using APIs meant for one system

      Or are you still using S3 MeTaL?(I'm not)

      One other thing to notice is that Nvidia made their fortune my making a video card *without a specific API*. Their card was designed specifically to run on windows d3d, which saved them money. I think the best way for Nvidia to keep making money is to keep making the fastest cards on the planet.

  • Good idea... (Score:4, Interesting)

    by talonyx ( 125221 ) on Monday September 24, 2001 @10:54PM (#2345113)
    ...but the current OpenGL standard is extensible enough for the time being. More important would be a complete OpenAPI setup with input, sound, network, and graphics options all combined and available on all platforms.

    Sure, including specific instructions for per-pixel operations etc. for all cards as opposed to stuff like GL_EXT_NVIDIA_WHATEVER would be great, but it's not likely that there will be many drivers for any older cards for this, and all the new cards have great GL drivers already...

    Basically, this is unneccessary.

    • Re:Good idea... (Score:2, Offtopic)

      by Anonymous Coward
      there already is an open sound library, apparently, its done by loki. http://www.openal.org/home/ [openal.org]

      • Re:Good idea... (Score:1, Offtopic)

        by SbooX ( 181758 )
        Hmmm... I forgot about OpenAL. But have they actually done any thing yet? Are they even working anymore or is this just another defunct project?

        How about SDL [libsdl.org]? I know its a bit simplistic, but it is rather cool and runs on an assload of platforms.

        • Re:Good idea... (Score:2, Interesting)

          by GiMP ( 10923 )
          OpenAL is not dead, as it seems many believe.. but it is very stable :) There isn't much one can do to it now, other then bugfixes..

          SDL sound sucks, thats why OpenAL was written. all of Loki's sdl based games use OpenAL.
          • No SDL sound does not suck, and OpenAL was written because of that. It wasn't written to provide cross-plastform 3d audio. OpenAL is not really designed to do traditional 2d audio like SDL is.

            Hence why OpenAL was written (AFAIK)...

    • Re:Good idea... (Score:1, Offtopic)

      by Dean Kusler ( 29799 )
      An OpenAPI, eh? I beleive that's already around at http://www.libsdl.org

    • Re:Good idea... (Score:5, Insightful)

      by donglekey ( 124433 ) on Monday September 24, 2001 @11:15PM (#2345174) Homepage
      This is completely untrue.

      A standard for pixel and vertex shaders that is not specific to any one card is a very big deal, and people are reconizing that it is the future. Many people are scared of games being released for only one card, and/or having to write a game for only one card. I don't think anyone wants that to happen. Standards mean more competition, more competition means higher quality and lower price at a faster rate. Defining a standard for procedural, hardware implemented functions will be key in advancing realtime 3D further. Image based textures are eventually going to be phased out for most purposes (as seen with trends relating to high-end 3D and the trickle down effect into realtime) and a standard makes it infinitly easier. There are many other applications, such as acceleration of non-realtime rendering, which is also a very big deal, and vastly accelerated and much more realistic previews in 3D applications. 3D Studio has already started to do this a little bit and it looks great.
      • In my opinion, they seem to focus a lot on programmability, but I think the future is in the SceneGraphs not so much the programmability. I think they are thinking to low level, when there needs to be many changes to the high level part of it. With high level programming for example shadows dont have to be customized hacks, and its even possible for the user to customize to their system what kind of effects to use. Scene graphs also give the video card more information about a scene necesary for many realistic effects.

        While OpenGL does have partial scene graph support I think a lot more could be done, a lot of redundant tasks that programmers have to do in creating a more complete scene graph.

        Another area is animation. Supporting 2d graphics is one thing, supporting 2d animation/video is another aspect that I have heard considered, and that can also be extended to 3d animation in conjunction with better scene graph support.

        It just seems to me that, to many of the vendors are looking for low level programmers. Most game developers these days are starting to reduce redundancy, rather then reinventing the scenegraph, they are starting to use for example the Unreal or Quake Engine, which is really a larger package of a scene graph and a whole lot more. And I think the reason they look at it this way, is that scene graphs would take a lot of time and investment on the part of the IHVs drivers then on the game and application developers.
        • Definitly some intersting ideas, but video games are dynamic of course, so when you say scene graphs what exactly are you referring to. Everything has to be relative to something else, but nothing is really set in stone. I think that this isn't really the focus for good reason right now, complex animation and movement will be the frontier after achieving a good amount of realism that we seem to be on the verge of with the Gamcube and XBox. Games are starting to look very good, and have distinguished styles. Making the animation as complex will come later, and it will be fucking incredible.
          • The minimal thing I think would be necesary to make OpenGL an better scene graph is to have an display list reference with a single transform matrix. Hierarchal information (relativity of objects) may not be necesary or may be an add on kind of utility (glut maybe). The import information for a renderer to have is the location of objects, especially when it comes to real time shadow and raytracing effects (which if done today would require accumulation of meshes every frame and even then object clipping is not always done by OpenGL implementations).

            I agree about animation for the time being because I dont think we have hit the highest parts of this yet, but any one who is familiar with Softimage|3D or Maya knows that animation can do some really nice things. I think when boned animations become more useful that we will start to see these things in games more often, current games are still using moprhs for animations.

            I shouldnt discount programmibility out right, I think some very interesting things could be developed with it (although I'm not sure how extensive current implementations are), it would be nice to start seeing procedural texture, objects, and fog effects. But procedural is a good option when you are low on memory, but memory is cheap these days, I think it would be nice if an API allowed for real time shadows in at least a minimal scene graph.

            Another interesting thing that scene graphs allow for is optimizations. Programmers use several techniques these days, like BSPs Quad/OctTrees and Portals, in order to optimize rendering and collision detection. While they could still be used to optimize collision detection, it could be allowed that a video system can optimize a scene to the way it prefers to render it.

    • Re:Good idea... (Score:2, Interesting)

      by dimator ( 71399 )
      Well, from what I understand (and feel free to prove me wrong), whenever you target multiple platforms, you sacrifice the performance you'd get if you focused and optimized for one platform. Add that to the fact the only platform that people seem to buy games for is Windows, and you see why game developors gravitate towards DX.

      So, it might be too late for such an initiative already.

      • Re:Good idea... (Score:4, Insightful)

        by SurfsUp ( 11523 ) on Tuesday September 25, 2001 @02:36AM (#2345525)
        Well, from what I understand (and feel free to prove me wrong), whenever you target multiple platforms, you sacrifice the performance you'd get if you focused and optimized for one platform.

        Sure, that's why Linux runs so poorly on a dozen different platforms, right? :-P

      • Re:Good idea... (Score:3, Insightful)

        by Paul Komarek ( 794 )
        Once you have platform independence, you can run games on the latest, greatest hardware with less or even no rewriting. Don't think of the cards supported at one time slice, think of the hardware coming out in the next half year. Using history as an example, wouldn't it have been nice to be able to run all those old (Voodoo days) Glide-based games on your NVidia TNT(2)(ULTRA) or GeForce[23][MX|ULTRA|GTS] or ATI Radeon?

        So you might lose 5% performance by targeting multiple platforms now, but you gain 200% performance when new hardware comes out.

        At one time, 3DFX was threatening or suing people that wrote Glide-like wrappers around DirectX. These wrappers allowed NVidia cards to run Glide-based games. That was when NVidia was starting to threaten 3DFX's revenues, but 3DFX was still the leader in the 3D gaming market.

        NVidia has already badmouthed the Kyro, telling computer salespeople that selling the Kyro is begging for irate customers -- what with all the incompatibilities that it might have, and the fact that it is an "unproven" platform. Through extensions to DirectX, it will be easier for NVidia to generate deliberate "incompatibilities", and NVidia has the money to push game makers into utilizing the features, and the marketing force to change the market into believing these features are important.

        That scenario plays out much differently if we reduce or disallow vendor extensions. I think it is worth the 5% performance penalty. As usual, peace and harmony are in our interests, but not in the interest of any business that wants to control the market.

        (all percentages above are made-up; any similarity to real percentages is strictly coincidental, not to mention lucky)

        -Paul Komarek
      • Please feel free to share why you think kinkatta sucks less than gaim. Does kinkatta support yahoo, msn, icq, and jabber? I'd have to say NO based on reading their website. And that counts for a lot. gaim does pretty much any necessary AOL IM feature, like chat groups and of course one-on-one chat. It even does buddy icons (fluff, i know). And its stable. The *only* benefit I can see from using kinkatta would it'd look like the rest of my kde apps (I am a kde user)


        siri

    • " ...but the current OpenGL standard is extensible enough for the time being. More important would be a complete OpenAPI setup with input, sound, network, and graphics options all combined and available on all platforms. "

      That's why we have SDL. Input, audio and graphics are provided, and you can still render into openGl contexts.

  • Carmack's feedback on this ;)

  • Mirrored (Score:5, Informative)

    by ekrout ( 139379 ) on Monday September 24, 2001 @10:59PM (#2345123) Journal
    This 2.25MB pdf will surely be inaccessible in a few minutes. I've mirrored it at http://ekrout.resnet.bucknell.edu/mirrored.pdf [bucknell.edu].

  • Lacking (Score:2, Redundant)

    by SilentChris ( 452960 )
    "The guidelines mention good-ol-fashioned platform independence (linux included) and emphasis on programmability, time control and memory managemenmt."

    Minus DirectSound, DirectInput, and all the other things which make DirectX a "good thing (tm)" for Windows (simple interoperability with hardware using standardized API's, simple driver writeups). For the time being I'll pass.

    Besides, I can always teach my upcoming XBox to dual-boot. :) Best of both game-playing worlds.

    • Re:Lacking (Score:3, Interesting)

      by SurfsUp ( 11523 )
      Minus DirectSound, DirectInput, and all the other things which make DirectX a "good thing (tm)" for Windows (simple interoperability with hardware using standardized API's, simple driver writeups). For the time being I'll pass.

      I suppose it's not your fault that some clueless moderator thought your post was insightful but I'm embarrassed for him ;-)

      OpenGL is the (free, open, clean and crossplatform) counterpart to Direct3D, not DirectX.

      • Re:Lacking (Score:3, Informative)

        by SilentChris ( 452960 )
        Ahem.

        "3D Labs Proposes OpenGL 2.0 To Kick DirectX"

        DirectX includes all of the extensions shown above. OpenGL just does graphics. The author of the post, and the person who posted the story, clearly wanted to make a comparison between OpenGL and ALL of DirectX, which as as mentioned before, is ludicrous because of all the stuff OpenGL is lacking.

        Get your facts straight.

        • The author of the post, and the person who posted the story, clearly wanted to make a comparison between OpenGL and ALL of DirectX, which as as mentioned before, is ludicrous because of all the stuff OpenGL is lacking.

          DirectX does only three things: graphics, sound, and input. OpenGL handles graphics, GLUT handles input, and OpenAL [openal.org] can do sound. Other multimedia programming libraries include Allegro [sourceforge.net], SDL [libsdl.org], and ClanLib [clanlib.org], all of which can coexist peacefully with OpenGL graphics.

          • DirectX is a monster, it does more then just 3 things. According the newest SDK from MS, here are the features of 8.1

            Microsoft® DirectX® 8.1 is made up of the following components.

            DirectX Graphics combines the Microsoft® DirectDraw® and Microsoft® Direct3D® components of previous DirectX versions into a single application programming interface (API) that you can use for all graphics programming. The component includes the Direct3DX utility library that simplifies many graphics programming tasks.
            DirectX Audio combines the Microsoft® DirectSound® and Microsoft® DirectMusic® components of previous DirectX versions into a single API that you can use for all audio programming.
            Microsoft® DirectInput® provides support for a variety of input devices, including full support for force-feedback technology.
            Microsoft® DirectPlay® provides support for multiplayer networked games.
            Microsoft® DirectShow® provides for high-quality capture and playback of multimedia streams.
            Microsoft DirectSetup is a simple API that provides one-call installation of the DirectX components.


            Also, you can use DX from VB and before they killed support for it, Java as well. Why would you want to use it from VB/Java? Prototyping a game is a good idea. Anyway, DX will win because in the end, programmers (in the general sense) are like everyone else, they are lazy. The API that provides the most bang for the buck will win.
            • DX will win because in the end, programmers (in the general sense) are like everyone else, they are lazy. The API that provides the most bang for the buck will win

              Programmers are lazy, so they will use the API that is either chained to their neck (Windows' basic interface API) or the 'best bang for the buck.' Since most everyone in the commercial software world has at least a few major APIs hanging from that iron chain (Windows), 'best' is not the winner.

              And NO Linux is not the end-all-be-all home to the "best" APIs. The history of computing is littered with the smoking wreckage of companies that produced "the best" and found that all their customers already had "crappy enough" chained to their necks. And if you think companies are evil then I hope you enjoy your free Quake clone.
          • DirectX does only three things: graphics, sound, and input.
            >>>>>
            That's like saying that all Linux does is run programs!

            OpenGL handles graphics
            >>>>>
            Well, but Direct3D is a tad ahead at the moment.

            GLUT handles input,
            >>>>>
            But if infinately weaker than DirectInput

            and OpenAL [openal.org] can do sound.
            >>>>>
            But does it do MIDI like DirectMusic?

            Then what about protocol-independant multiplayer (DirectPlay), and multimedia (DirectShow)?

            Other multimedia programming libraries include Allegro [sourceforge.net], SDL [libsdl.org], and ClanLib [clanlib.org], all of which can coexist peacefully with OpenGL graphics.
            >>>>>
            They can do the same with DirectX, but because of all of DirectX's features, you don't need extra libs.

            • That's like saying that all Linux does is run programs!

              Which would be correct. Linux is a kernel; a kernel's job is to run programs.

              Well, but Direct3D is a tad ahead at the moment.

              Just a tad, and DirectX Graphics's superiority is in areas that require hardware that most consumers (early adopters excluded) do not yet own. Even so, I hope Microsoft is enjoying its fleeting precious moments [gocollect.com] of superiority because they will end very soon.

              But if infinately weaker than DirectInput

              Or "GLUT is infinitely weaker than DirectInput." Could you elaborate?

              But does it do MIDI like DirectMusic?

              The sound quality of the General MIDI support on most consumer-grade sound cards sucks, and General MIDI has never been good for many genres of electronic music. Point me to a .mid file doing a good impression of a tb-303 to convince me otherwise. Why else did Unreal Tournament use S3M, XM, and IT tracked music instead of MIDI, and most newer games like q3a use streaming MP3 or ogg anyway?

              Then what about protocol-independant multiplayer (DirectPlay)

              The sockets API is also protocol independent and can support any protocol for which your sockets implementation (such as BSDsock or Winsock2) has a backend.

              and multimedia (DirectShow)?

              Why can't you use the game engine (built on d3d+dsound or opengl+openal) to do cut scenes, as Metal Gear Solid and Zelda 64 do? Or do you have some other reason for wanting to play movies?

              [Allegro, SDL, and ClanLib] can do the same with DirectX, but because of all of DirectX's features, you don't need extra libs

              All three libraries have DirectX backends, but they also have backends for operating systems not controlled by Single Point of Failure Corp. [google.com]

              • Which would be correct. Linux is a kernel; a kernel's job is to run programs.
                >>>>>
                But those words carry a far larger meaning than the sentence implies. DirectX does only do sound, graphics, and input, but those words understate its power.

                Just a tad, and DirectX Graphics's superiority is in areas that require hardware that most consumers (early adopters excluded) do not yet own. Even so, I hope Microsoft is enjoying its fleeting precious moments [gocollect.com] of superiority because they will end very soon.
                >>>>>>>>
                Why? The link you provide doesn't have anything to do with DirectX or OpenGL, so I surmise that you have no proof that OpenGL will suddenly stage a comeback. Even if OGL 2.0 gets rolling right now (it won't) it will quite awhile before the glacial-paced ARB will produce something useful.

                Or "GLUT is infinitely weaker than DirectInput." Could you elaborate?
                >>>>
                Read the GLUT API, then read the DirectInput API. Juding from the GLUT 3.7 API reference [opengl.org] GLUT supports three button mice, keyboards, and spaceballs. DirectInput can be programmed to handle anything, from mice with dozens of buttons buttons to 6 axis force-feedback joysticks to full-body cybersex suits. Also, GLUT's callback-based mechanism doesn't exactly scream "performance" in a game setting.

                The sound quality of the General MIDI support on most consumer-grade sound cards sucks, and General MIDI has never been good for many genres of electronic music.
                >>>>>>>
                That's why DirectX doesn't use standard MIDI support anymore. On cards that have poor MIDI support, MS uses its (pretty good) software synth.

                Point me to a .mid file doing a good impression of a tb-303 to convince me otherwise. Why else did Unreal Tournament use S3M, XM, and IT tracked music instead of MIDI, and most newer games like q3a use streaming MP3 or ogg anyway?
                >>>>>
                The music requirements of Q3 or UT aren't exactly terribly stressing. MIDI is uniquely suited to all sorts of things, such as dynamic adaptation to the game environment, that are hard to do with pre-recorded music. With DirectMusic, you can program scores that follow a general patterns, but fluctuate depending on conditions or at random times. The power is there, it is only a matter of time (DirectMusic only became mature fairly recently) until some clever developer decides to use it.

                The sockets API is also protocol independent and can support any protocol for which your sockets implementation (such as BSDsock or Winsock2) has a backend.
                >>>>>
                True, but DirectPlay is a *much* more integrated solution. It does lobbies, transport, all sorts of things.

                Why can't you use the game engine (built on d3d+dsound or opengl+openal) to do cut scenes, as Metal Gear Solid and Zelda 64 do? Or do you have some other reason for wanting to play movies?
                >>>>>>>>
                DirectX isn't necessarily just for games. You can use DirectX to get hardware acceleration for DVD playing and other multimedia uses. Also, many games use video quite well. The Final Fantasy series, for example, uses full motion video to a great effect. Also, game engines still aren't up to the quality of good FMV yet.

                All three libraries have DirectX backends, but they also have backends for operating systems not controlled by Single Point of Failure Corp. [google.com]
                >>>>>
                Yes, but their functionality is a fairly limited subset of DirectX's features. Also, it is not fair to criticize DirectX just because MS sucks. DirectX is a quality technology, Microsoft or not.

    • Re:Lacking (Score:2, Informative)

      by Osram ( 185373 )
      Have you seen PLIB [slashdot.org] ?
      This not only includes a portable (Linux, BSD etc, Windows, MacOS etc) scene graph on top of OpenGL and sound and input, but also the other stuff you need for games development like networking and graphical user interface.

  • Interview (Score:1, Interesting)

    by Phleg ( 523632 )
    Going to be interviewing a friend of mine at nVidia about this tomorrow morning, after he clears it. Will submit the story tomorrow if he gets the OK.

  • This IS necessary (Score:5, Informative)

    by rips ( 34200 ) on Monday September 24, 2001 @11:16PM (#2345182)
    There seem to be a lot of posts stating that the current OpenGL implementation is good enough but I question whether or not these people are developing software with the latest graphics features.

    Vendor specific extensions are making cross-vendor OpenGL development difficult. It is necessary to implement several different codepaths in order to achieve various effects on different hardware (bump mapping, cubic environment mapping, etc.) because each vendor wants to do it their own way to expose all of the new capabilities of their hardware. The SGI multitexture extension is probabily the only real exception to this since it seems to be supported by the bulk of cards on the market.

    I don't know of any current AAA, A or B grade game that doesn't support at least one proprietary OpenGL extension.

    DirectX8 exposes the hardware in an 'almost' abstract manner but again vendor specific features have started to creep into the mix (the different shader version support is something that comes to mind), meaning that developers still have to develop multiple versions of the same effect for different hardware.

    This is definately a great move! I hope they succeed!

    • Re:This IS necessary (Score:2, Interesting)

      by Anonymous Coward
      So in OpenGL, you have vendor specific extensions.

      In DirectX, you have vendor specific releases of the whole API!

      DirectX 8 = DirectGeforce
      DirectX 8.1 = DirectRadeon

      It'd be a lot more honest and less confusing if they just used the names of the cards rather than numbers...
      • If I had moderator points, I would so mod you up. It's so true.. I have an original Radeon and it sucks, it was all advertised as DirectX 8 and stuff, but then Microsoft went and fucked them over on the API with the pixel shaders and shit, so it's broken on my card and doesn't work right in DX. Yay Microsoft!

        Now 8.1 is coming out, and the Geforce is screwed because it has Pixel Shader 1.4 in 8.1 which the R8500 supports but the GF3 doesn't (AFAIK).. among other things (higher-order surfaces/TruForm, etc.).

      • Re:This IS necessary (Score:5, Insightful)

        by Jurjen Katsman ( 19539 ) on Tuesday September 25, 2001 @12:31AM (#2345334)
        While it might be true that DX8.0 added a lot of features that only worked on the Geforce3 back then, the new Radeon 8500 supports all those features just fine as well.

        DX8.1 adds new features only available on the Radeon 8500, but a new NVidia card will be able to run all that just fine as well.

        The plan is for this to continue in this fashion, so the next NVidia card will probably support PS1.4 again (the R8500) stuff, and so forth.

        This is a very different situation from OpenGL where the way to do pixelshaders is completely different on ATI or NVidia hardware, and anything you do for an NVidia card will never work on an ATI card, and not the other way around either. As far as I know the same applies to vertexshaders, and ATI still doesn't have their own version of NV_VertexArrayRange. (And they certainly need it).

        On OpenGL2.0, it seems like an interesting plan at first (I'm always open for API innovation), but atleast for gaming it doesn't seem to be a very interesting API, and not very forward thinking either. For example keeping the framebuffer blend out of the programmable pipe goes directly against what game programmers have been asking for.

        In addition it seems the API would have a lot of problems running on current hardware (not to mention how long it would take for drivers to even get close to stability). OpenGL2.0 would expose model for vertex and pixelshader programming that would be completely unsupported by current hardware. This means you will have a lot of rules to follow to achieve hardware acceleration on specific hardware. When using more features you'd drop back to mostly unacceptably slow software emulation. This would either be hidden (and you could only find out by browsing PDFs hidden somewhere on some IHV site), or it would have to be exposed through some sort of caps system. (Exactly what the OpenGL crowd so seems to dislike.)

        Anyway, I don't see this working yet, not for the games market, maybe for others. Best of luck to them anyway.

        • Maybe what is needed is for the extensions to be open, at least in the way of their API. That way as a new feature is added by on company it becomes an extension registered with some body and then work would be performed by the community to ensure that is available for implementation by any other of the card manufacturers. I can imagine that this would lead to a case where we would be talking OGL + extension collection 1, etc. At least this way the time for implementation should be reduced.
      • Correct with DX8 and DX8.1, but not with DX9.

        DX9 will be hardware independent again.

        The text explicitly states that they don't want to repeat Microsoft errors in doing such a thing.

        To quote from slide 6:

        Currently proposed OpenGL extensions
        are repeating the mistakes of DX8
        How is OpenGL going to respond to DX9?
    • Aye not only is it necessary, but there's a very good chance that the product we all seek is laying out among the various current projects in pieces. One of the VERY common problems with Open Source (Not that I knock it, mind you. I totally love and embrase it), is that the wheel tends to get reinvented numerous times, where one package has not large, but small things in it that another similar package does not.

      What really needs to be done is SOMEONE (unfortunately, it's a a fair bit over my head atm) needs to gather all the projects like SDL, Mesa, OpenGL, OpenAL, SDLnet, SDL Input, (and the numerous other libs out there that I haven't used) and attempt to use those libraries as a basis for a wrapper.

      First We must duplicate the existing, ie. DX with our own software. Then take steps to merge them together using the incredible amount of knowledge in the OSS environment into a well-focused library set which is both extensible and cross-platform compatible. Many of the projects out there already do this, but it must be solidified.

      Now don't go bashing me for mentioning an OSS version of DX. Not having messed with it more than a week, I'm no expert on it. However, there are OBVISOUSLY things about DX that developers like well enough that makes their jobs easier. That's what We have to do as well. Create libraries that are easy to install, cross platform compatible, feature rich enough to satisfy the majorities needs of functionality, and finally optimized to the max. It's been proven that Linux is faster that WinX in a number of different senarios, but if We can't pull together with this, then it's going to take a VERY long time for OSS to gain it's footing in the gaming market.

      Besides, with an OSS solution, people like Carmack can spread their knowledge to extend the library with functionality with a simple submission whereas trying to get that into DX... well.. M$ would just laugh at you.
      • How do you defeat the Borg? Build a better Borg!

        Yes, there are times when having a single unified entity is a good thing. That's a big part of how Microsoft got to where they are today. Windows is Windows and Office is Office -- there's only one version, and everybody is comfortable with it. The masses don't care so much about choice -- they'd rather use something they are familar with -- so it becomes a de facto standard.

        Now, on Linux, you have lots of choices, but run the risk of coming across looking like a collection of disparate and disorganized parts rather than one unified entity. Choice can be intimidating for people. Do I choose Debian? Do I choose Mandrake? How do I know? On the other hand, you've got Apache, which is pretty much the Microsoft Office of the web server world (on the Unix platform) -- almost everyone uses it -- they don't have to think about the choice, because a generally-accepted "standard" exists.

        Choice -- the very thing that attracts many people to the Linux platform -- may be a big part of what keeps everyone else away.

    • Re:This IS necessary (Score:5, Interesting)

      by Namarrgon ( 105036 ) on Tuesday September 25, 2001 @01:06AM (#2345383) Homepage
      Indeed. This is one of the things they talk about in the recent OpenGL ARB meeting notes [opengl.org].

      nVidia's extensions alone total more than 500 pages, compared to 230 pages for the entire OpenGL 1.3 spec. ATI has their own comprehensive list of extensions, as does SGI and many others. Since there's little natural overlap, each vendor implements similar features in a different way (e.g vertex shaders), and you have to code for each vendor's set of extensions separately. The OpenGL ARB can "ratify" extensions to promote standardization, but you still have to cope with them not being present at all.

      This is exactly the problem developers have with DirectX - MS regularly revs the entire API to try and support features from every vendor, so there's an ever-increasing number of ways the underlying hardware differences are exposed, and the number of hardware caps that have to be checked before doing anything is growing rapidly. There are 4 different versions of pixel shaders that a vendor can support in DX 8.1, and the only reason it's not more of a mess is that there's only two chips which support any of them so far (and one of those isn't even available yet).

      Regular simplification & unification of all these diverging directions is required. Vendors should of course be able to add innovative extensions, but a core of Really Useful standard features must be maintained & extended, so that hardware vendors have a baseline to target, developers can rely on the features being present, and the lowest common denominator gets steadily pushed higher for everyone.

  • In support (Score:2, Interesting)

    by mesmin ( 519217 )
    Not only is this a worthy cause (eliminating the depenence hardware specific extensions), but I fully support a graphics solution that doesn't have the final say on everything rest with MircoSoft.
  • Hasn't 3d Labs always wanted OpenGL to be the standard? And in some sense, haven't DirectX and OpenGL always been competitors? The article heading should have said something like "work for OpenGL 2.0 progressing".

  • Misc first impressions (Score:5, Informative)

    by Anonymous Coward on Tuesday September 25, 2001 @12:31AM (#2345330)
    Loops

    I'd recommend against general for and while loop constructs in the shading languages. These are difficult to statically analyze the behavior of. For instance, you could stall your pipeline with an infinite loop but no compiler can detect infinite loops. Also, loops are rarely used except for Perlin noise where you iterate down to a particular frequency.

    Loops of a particular form can still be analyzed, and would be useful. Something like this:


    for (int i = 0; i &lt N; i++) { body }


    If i is 'const' within the body, then this will iterate at most N times, giving you a bound on the compute time needed. Note that if N is an arbitrarily large number, it may still be difficult to analyse. Here's another form that is more generally boundable:

    for (int i = 0; i &lt N && i &lt 20; i++) { body }

    This will run at most twenty times, giving an easily computable upper bound on the total run time for the loop. Of course, 20 was just pulled out of a hat, and should probably be a constant specific to the compiler or hardware available.

    Memory Management Issues

    Pinning is dangerous, your program could be really broken on a graphics card with smaller memory than you intended. At the end of the standardization process it will probably become a mere 'hint' anyway.

    An alternative might be to treat the memory management as a generational garbage collector, with user hints on what generation things should fall into. Rather than specify a particular management scheme, the programmer could hint at how dynamic the object would likely to be, say for instance ranking them from 0-7, with 0 being transient and 7 being pinned. Alternatively the systems themselves could become more intelligent, tossing everything into the transient area, and migrating them upstream automatically when the transient area starts to fill up.

    Another useful operation would be to hint flushing everything below a certain level. So for instance you could give Everquest character models a level 5, the terrain a level 4, mobs a level 3, and various effects and candy at lower levels. Then on zone you would just specify a flush of levels 4 and under to clear that memory, while leaving the character models intact.

    For added flexibility to this model, multiple different memory pools could be managed in this fashion. It remains to be tested whether that would be worthwhile or not.

    Well, that's all I could think of off the top of my head. Good luck on OpenGL 2.0!

    Michael

    • Infine loops. (Score:1, Funny)

      by Anonymous Coward
      For instance, you could stall your pipeline with an infinite loop

      That's easy - just get a faster CPU, it will execute the loop faster!

  • OpenGL ARB Meeting notes (Score:3, Informative)

    by Namarrgon ( 105036 ) on Tuesday September 25, 2001 @12:40AM (#2345346) Homepage
    Available here. [opengl.org]

    There's a lot of discussion on how/when/why they want to move forward to OpenGL 2.0. Gives some interesting insights into how these things are done.

    Also, there's some talk about nVidia's new position on opening up their vertex shading IP, GL_vertex_program_NV vs. ATI's GL_EXT_vertex_shader, and which approach would be better for OpenGL 2.0 (low-level vs. high-level).

  • Great, they're closing the barn door after the livestock has left.


    Seriously, why now? This could have easily happened long ago, before Nvidia crushed the competition. I don't like the world where looking to open source (or even just open discussion) is the last resort of a dying technology.

  • In similar news... (Score:3, Funny)

    by mattkime ( 8466 ) on Tuesday September 25, 2001 @12:54AM (#2345363)
    In similar news...

    Linus Torvalds proposes to kick Bill Gates.

    It is uncertain as to whether the world's richest man will propose a retaliation kick. Such a proposal could be viewed as a sign of weakness. It should be noted that while Gates is phyiscally much smaller than Torvalds, microsoft operating systems have a much larger market share than linux.
    • I think that Linus should start going around kicking people at random. This sort of behavior would definately bring attention to linux as it's creator would be headlined in the paper each day with "Linux creator kicks mayor of Houston" or "Linux's Linus kicks local Joe in pants". Attacking Bill Gates is very hard to do. You have to camp outside of his house for days, wait for his driver or someone to drive by hoping that he is in the car. Throw down a bunch of money on the road hoping to catch his attention. After he gets out to collect the free money, you have to charge his car, hoping one of his many body guards would not catch you before you delivered that swift, refreshing kick in the pants to M$'s ruler. I'm not saying that it wouldn't be worth it, and believe me, I've tried, but for someone in Linus's position to attempt such a dangerous act would be almost unthinkable. I say stick to the average Joe or random politician Linus. They're much easier to get to and there are many more of them.
  • This does make me feel old. I have been listening to news about the new great standard that will make games available for all platforms for longer than most slashdotters have been alive.

    It's a great idea but somebody please make it work before I die.

  • Sure, but the latest OpenGL ARB (Architecture Review Board) minutes [opengl.org] also have this comment from Bimal Poddar (Intel):

    Devil's Advocacy question: why do we want OpenGL to survive? If IHVs can't articulate this and drive progress, it won't survive.

    A "devil's advocacy" remark at an ARB meeting, but maybe not so far fetched in reality. - Mike (OpenGL dabbler)

  • DirectX is so prolific, and MS has people who do nothing but provide support to developers for DirectX. If there is an issue with DirectX, MS patches it (how well they do that is another issue).

    It's going to be a HARD sell to get development companies to move away from DX. More than 90% of the games you are going to sell will be for a platform that supports DX.

    If you have a team of well paid developers who have several years developing for DX, why does it make sense to switch?

    Though, I know this is not possible, I'd love to see an "embrace and extend" approach to this. Make an API that is "compatible" with DX, but has some "features" that DX does not support.

    I know this is fanciful, but everyone is entitled to a dream, right?
    • DirectX is prolific because it works and provides easy access to advanced funky effects. If OpenGL 2.0 offered the same level functionality *and* was cross-platform, I seriously doubt anyone would bother with DirectX anymore.


      After all, why lock your game into one platform when another equally good API allows you to port to other platforms (including consoles) with relative ease? Certainly you'd have to port all the sound and controller stuff but that's chicken feed compared to porting a game engine.

      • The number one reason DirectX is popular among developers is because every consumer vendor has a decent DirectX driver, and few have decent OpenGL drivers.

        DirectX was much simpler when it first came out, so was easier to implement. It had Microsoft's weight behind it, it was being steadily improved, and it supported 90%+ of the target market. So vendors implemented drivers for that as part of their normal Windows support.

        A few (luckily influential) die-hards (like Carmack) used & promoted OpenGL, which forced minimal support from vendors (remember 3dfx's mini-driver?), but few vendors bothered to go the whole way & write a full OpenGL ICD.

        Direct3D was the lazy way out, so that's what people got.

  • In my opinion, if you're comparing DirectX and OpenGL then you're really talking about group multimedia projects, and I really think that sticking it out in C isn't the way to go for that.

    I love C, but there are huge design benefits in going OO with C++. Eventually you'll get to the point where there'll be a large body of accepted base classes that should handle all the standard 3D objects you might need for a game, and then you won't have to (eg) search all over the internet to find obscure libraries in beta form just to get your program to load a model from a 3D cad program.
  • Are we perhaps forgetting about VA Linux laying off some of the key developers of GL software for Linux less than a week ago?

    Sure, OpenGL 2.0 would be nice, but a nice spec isn't going to do us alot of good unless we can develope drivers and implement it.
    VA Linux shut down their professional services organziation, which was funded by a number of other projects for graphics vendors and for other graphics research organizations.

    3D Labs wants to kick things into high gear and start pushing for an open collaberation on OpenGL 2.0, what are they going to do about the lapse we are going to see in card drivers and the rendering infrastructure on these open platforms that no longer have developers?

    I think what 3D Labs is doing is a Good Thing(tm), but I heard someone say somewhere that perhaps they arrived a bit late and unless they are going to pick up the buck and run with it, I would have to agree.
    • Without support from NVIDIA/ATI/IMG/etc there is very little justification for these projects (ATI and IMG have said they will use closed source drivers for their new cards, NVIDIA has made its policy clear a long time ago).
  • Game developers have to develop where the market is. Game developers aren't scratching their heads in a huddle making sure some vertex shader is going to work on a MIPS box as well as a Intel one. They also aren't wondering if they ought to code some API extensions used by a chip that is in a fraction of a percent of boxes. The ones clamouring for standards are the third tier and lower chip makers that have a fraction of the market penetration ATi and nVidia have. If you've got support for ATi, nVidia, and 3dfx you're set to go on just about everything. I'd bet the markets for the big three (now the big two) is fairly even considering the proliferation of ATi cards in OEM systems. Selling your game to a publisher doesn't necessarily entail providing support for every potential market, just the ones the publisher decides are important. A bulk of game developers and publishers won't bitch much about standards while they can hit an incredible percentage of the gaming market by focusing on one system. The developers and publishers look at it like this: what are the machines we're targeting being used for? If the answer doesn't involve the machine sitting idle with signifigant amounts of computing power (enough for the proposed game, aka most consumer Windows machines) the game probably won't be developed for the system. Macs enjoy a much wider market than linux systems and have vendor support for APIs and are still second tier for game developers because not enough of them are sitting on desks in the game purchasing consumer's home.
    • > Game developers have to develop where the market is

      True, but us game developers also buggered up the market by NOT actively pushing OpenGL instead of D3D, and developing for D3D *when we HAD a choice*.

      There was even a petition [wired.com] to Microsoft to better support OpenGL for gaming, which Microsoft responded by ramming D3D down everyones throats.

      I'm just thankfull that Carmack didn't sell out - he's the primary reason OpenGL support for games is still around. The OpenGL-Game-Dev list traffic has unfortunately slowed down, but it's not dead (yet.)



      > Game developers aren't scratching their heads in a huddle
      > making sure some vertex shader is going to work on a MIPS box as well as a Intel one.

      You don't do any PS2 coding do you? ;-)

      When your game is simulatenously being ported to X-Box, and the PS2 you need to re-implement the vertex shader natively on each hardware. It would save a LOT of time if us developers could use just ONE vertex shader description language for BOTH platforms !



      > A bulk of game developers and publishers won't bitch much about standards
      > while they can hit an incredible percentage of the gaming market by focusing on one system.

      And loose 1/2 your sales?! That's the reason a standard exists - so we DON'T have to code specifically for one card !

      Game developers want to maximize their sales with the least amount of work.

      Rest of your comment is correct.
      ~~~

      WTF is "Your comment violated the postersubj compression filter. Comment aborted" and why isn't it in the FAQ ?

  • I left 3D stuff a while ago, utterly bemused with the various complexities of D3D and OGL. There was a lot of legacy stuff in there and little fiddly bits that were in 'just because'. Now I presume there will be a refactor in the light of various progresses in the field. I believe refactoring to be a GOOD THING (tm).

    OGL2 will be 100% backwards compatible. Well, that could be either good or bad.. If we end up with so much legacy kak the new version will just be a bigger more combersome beast than before. Remember the DOS/windows incarnations.. eugh.. But it can still be done well. Refactoring need not mean throwing away + starting from scratch.

    I've done some Java3D.. that's fairly nice, fairly fast and I hope some of those lessons are fed into OGL2, along with things that other lib-developers have learned. Afterall, OGL ought to be faster and more widely used, given it's foothold (however weak some might percieve it to be).

    I really hope that OGL2 will become ther real OPEN standard for 3d programming. Various little-libs have surfaced to hide the old OGL/Dx, but it's time for those to be set aside as the core tech becomes the thing to use.

    Quick note on 'extras', should OGL include libs for keyboard/mouse/sound/controller access? Well, I honestly don't know the answer, but my guess is that there should be hooks for plugging such things in, but I also think that OGL should be focussed on the job in hand: rendering fast, amazing 3D graphics.

  • Let's see OpenGL 1.5 first. I'm tired of software dev'rs artificially bumping up version numbers for no reason. Christ, Deneba skipped Canvas 4 altogether, going from 3.5 to 5.0- what's the deal? And Photoshop 5 vs. 5.5- they include one extra bit of external software- what the hell was that? Heck, why not just bump it from 1.3 to 9.0 in order to "surpass" DirectX- it's about bloody time!
  • This is the same old argument of 'Standard interace vs. proprietary interface'. Proprietary ALWAYS wins because if everyone's the same no one has an edge. Companies out to make money are not going to give away or give up the edge that the proprietary extensions give them.

    • Proprietary does not "always" win. Proprietary interfaces only win for as long as companies can fool consumers into lusting after new features. Sooner or later, the consumers will start saying "gee, all of these cards have way more features than I need, I guess I'll just get the cheap one." That is when the companies will have to stop competing on the basis of features, and start competing on the basis of price.
    • Yeah, that's why IBM PC compatible clone market died in 80s; nobody wanted non-proprietary hardware platform. Same for the TCP/IP and WWW on 80s and 90s; neither had a chance against cool stuff like decnet, netware and various cool hypertext protocols that rule nowadays.
    • Kinda like how Glide won? Or MeTaL? Or PowerSGL? Direct3D is not extendible (game developers stopped MS from making it extendible) and it owns the majority of the consumer 3D market. All the graphics cards makers are actively in support of it, while most offer less support for OpenGL. The fact that a standard interface like DirectX allows manufacturers to reach *everyone* with a 3D card, not just those with particular 3D cards outweighs any advantages of proprietory APIs. The game developers like it because it simplifies development for them. The hardware manufacturers like it because it broadens the use of 3D hardware. Consumers like it because they aren't stuck buying unsupported crap (generally...)
  • There is hardware. That hardware is owned by your targetgroup. That targetgroup will buy/use your application. What do you do? That's right! You use the API that will make the targetgroup able to run your application on the hardware they own. Does the targetgroup care which api, which dll's, which 3d object format etc you use? No. They probably don't even know what a 'vertex' is.

    So if you have to use OpenGL, use OpenGL. If you have to use D3D, use D3D. Being productive, THAT's the key here. Not the emotional connection with any API. Save the emotions for a hobbyproject.
    • The benefit to an Open API like OpenGL is that it is cross platform, and cross hardware.

      Lets examine a few things:
      1) DirectX is Windows only. Developers who develop under DirectX/D3D have a harder time porting from platform to platform because of the API.
      2) Let's look at a more closed API, which you claim is just fine. 3Dfx for example. For a long time when 3dFx took over the gaming graphics market, it used a proprietary API called 'glide'. The problem arose when new, better video cards came out. They couldn't run the Glide apps, and everyone was developing JUST for glide. So new manufacturers had a hard time, as did customers.

      Using an Open API like OpenGL allows cross platform, cross hardware development much easier. It simply requires a manufacturer releasing an OpenGL ICD for their card, and their card runs OpenGL (Assuming it's internal hardware meets the requirements of the application in question).

      Companies looking to port their app to multiple platforms have a much easier time; OpenGL is available on most major platforms such as Unix, Windows and Mac.

  • ...their idea )
    OpenGL ARB meeting notes [opengl.org]
    Notice this:
    Action: John Stauffer volunteered Apple to lead the short-term unification work. 3Dlabs volunteered to lead the long-term 2.0 work.
  • i gotta say getting DRI, OpenGL, SDL or whatever working on a linux box does not seem as easy as applying some directx patch MS puts out. i've got an ATI AIW 128 32MB AGP card, and it goes something like this: build and install XFree86 4.1.0 from source (this gets the games working ok), next, build and install ati.2 drivers from the wonderfull livid folks. this gets xawtv working. build a new kernel, install kde, any system changes, (move your mouse the wrong way), and rebuild and re-install them all again. don't get me wrong, once it's installed and working, it works great (i wish i had the ability to record the xawtv streams to avi files), but getting it up seems to have a STEEP learning curve.
  • The "OpenGL 2.0" proposal was discussed at the last OpenGL Architecture Review Board meeting. [opengl.org] There are mixed feelings about this proposal. The big question is whether to abstract or expose the hardware.

    Organizational support for OpenGL continues, but it's not like the days when SGI was really pushing it. The Farenheit debacle turned off many people. Apple is still OpenGL oriented, but support is weak. From the minutes of the last meeting: "The next meeting date is set for Tue-Wed, December 11-12, 2001. Apple is tentatively willing to host again, if needed - the food budget was a bit of a problem for them this time."

    What this proposal really calls for is a sort of "RenderMan Lite". The concept is very like RenderMan, with programmable shaders written in a C-like language.

    This is an instance of the "programmable peripheral" problem. There's always a temptation to put programmability in peripheral devices. The usual problems of embedded systems programming apply - a special toolset is needed for the target system, debugging support is usually weak, and synchronization between host and target is complicated. That's why programmable peripherals are rare. (For example, we don't usually see the ability to put the file system in the disk controller, or the TCP/IP stack in the Ethernet controller, although hardware has been built and sold for both of those functions.)

    What usually happens is that agreement emerges on what functionality a device should export, and device controllers implement that functionality, rather than exposing their innards.

Slashdot Top Deals

"How to make a million dollars: First, get a million dollars." -- Steve Martin

Close