Slashdot Mirror
OpenGL 2.0 Released
berny@work writes "OpenGL has finally released version 2.0. The benefits include Programable Shaders, in particular: Shader Objects, Shader Programs, OpenGL Shading Language and changes to the Shader API. If you are interested take a look at the tutorials and the case studies that are linked to from the OpenGL site."
Isn't it used for the Unreal Engine games and a lot of the Q3 engine games? There's a lot of games based on each of those engines.
It's like sex, except I'm having it!
Seriously, that guy almost has kept OpenGL relevant in the gaming industry almost single-handedly.
There were DX9 compatible cards about 6 months before the release of DX9. They set the standards ahead of time, and the card makers comply with those standards when they design the architecture. They can't really predict when Microsoft (or OpenGL's coders) will actually finish the product.
It's like sex, except I'm having it!
Its used for a lot of popular games including Doom 3, Return to Castel Wolfenstein, Quake series, etc. See http://www.opengl.org/applications/windows/games/ for a list of the windows games using OpenGL
The new functionalities were in the previous versions as extensions AFAIK, OpenGL 2.0 adds them to the standard.
So (unless I missed something that wasn't previously an extension), you just need a new driver for your card and you'll be set.
The IT section color scheme sucks.
Can OpenGL ever match DX in popularity among developers?
Yes. id (quake, doom, etc) and I believe unreal both use it. Both are competitors, and as small of importance as portability to other operating systems such as Linux may seem to be, it is still somewhat important to them (although, I -still- haven't heard anything new about doom3 on linux)
Interest into porting to Linux is slowly becoming more popular between game makers, mostly because if you do it right for the windows port in the first place, it isn't as difficult as it might seem to port to Linux, and it helps open up a small new (starved?) market.
Supporting OpenGL 2.0 is the job of the drivers, which didn't support it so far simply because the specification didn't exist. The cards have all the capabilities necessary to support OpenGL 2.0, which makes sense if you understand the development process of OpenGL: The card makers come up with some new feature, and they can immediately implement it in the form of an extension and release it with their driver. After some time, the new features become generally supported, so the ARB looks over the extensions and makes an ARB extension out of it that the card makers have to implement again. This means that the new features of OpenGL 2.0 are actually just the features that the cards already have put together into one API.
You really have no idea what you're talking about do you. OpenGL vs D3D flamewars have been raging for years, FYI D3D started out well behind OpenGL feature for feature and gradually added OpenGL features, each generation of D3D we had to listen to Microsoft claim that all the interesting features of OpenGL were already in D3D and OpenGL had no advantage, only for them to add more in the next release.
D3D is a proprietary windows programming API owned by Microsoft and designed for games with some incredibly ugly and arduous API semantics, OpenGL is an open, extensible cross platform industry standard controlled by a board of interested industry specialists that anyone may join. The rendering and dispatch API semqantics have been optimized by the vendors in a standard way. If there was a need for any particular feature the vendors would add it as an extension either individually (something they can do and have done on their own) or they could collaborate on shared extensiosn for a common API. Red herring features that do not make any sense or map to real hardware have no place in a programming interface explicitly designed to sit close to the metal like OpenGL.
OpenGL is just an API that provides a general way to communicate with the graphics card in your computer to make "3D stuff". A card may fully support OpenGL 2.0 as long as its hardware can implement (can perform) what the API specification says.
In that respect, most modern cards (that now implement OpenGL 1.5) have the hardware capabilities to implement OpenGL 2.0. So it's just a matter of updating the drivers. More specifically, update the OpenGL implementation library of them.
Um, what do you think OpenGL 2.0 is? It's a specification.
A deep unwavering belief is a sure sign you're missing something...
You used to be able to draw "dots" on the resulting screen, used for whats called "particle effects", like mud spraying out of the back wheel of an offroad racer, for instance. Very simply (quicky) drawn because you're just handing out x,y coordinates for htem.
Now, rather than just colored dots, you can use textures or sprites (little pictures). So instead of a cloud of brown dots coming from a dirt bikes rear tire, you could have little chunks of rocks and grass. Or rather than a cloud of red dots coming out of a guys head when you shoot it, you could have little chunks of brain and skull.
I don't need no instructions to know how to rock!!!!
Deader than a dodo bird? That's quite a statement to make especially when you have: http://www.opengl.org/applications/windows/scienti fic/
http://www.opengl.org/applications/windows/modelin g/
http://www.opengl.org/applications/windows/cad/
http://www.opengl.org/applications/windows/simulat ion/
http://www.opengl.org/applications/windows/vrml_we b3d/
http://www.opengl.org/applications/windows/games/
not to mention that some of the most immersive 3d environments are created by SGI hardware all based around the OpenGL API.
Now if you want to simply talk about games, sure there are more DirectX games since MS monopolized the desktop market.
Anyways I think serious gamers should do something productive. I only play ut2k4 to blow off some steam.
Apart from having no relevance to OpenGL, most of the lighting examples etc on the page rely heavily on either NVs registry combiner extension or NVs 'CG' shader asm. Both of which are non-standard methods that have been depreciated for ARB standards for a while now.
<BioWare> Yeah, that's a great idea. Let's re-do a whole bunch of work, lengthen our dev cycle, have to re-do our schedule just so we can pander to 1.5% of the market.
Not to mention, the release of 2.0 is just formalizing support for these features. They all existed previously as extensions. Bioware could have developed using them a year or two ago if they wanted. I suspect they chose Direct3D because it is more convenient to develop with, has more driver support, and works excellently on their target platform.
perl -e 'printf("mmm %x\n", 3735928559)'
Cg is identical to HLSL, the shader language in DirectX9.
While I agree with you about DirectX in general, I find HLSL/Cg to be an absolute joy to program for, so credit where credit's due - I don't see why we need a seperate, different and incompatable shader language when the one we already have been kicking around for the past couple of years is so well thought out.
Cg works fine on ATI hardware, and any other hardware that supports D3D or arbvp/arbfp assembly.
Have you used D3D recently? It's generally perceived as being vastly improved over earlier incarnations (just like most of MS' products), and perfectly useable these days.
But you are right on one point -- linux, like Mr. Carmack, is indeed a factor contributing to OpenGL's lack of demise.
OpenGL, by the ARB's very nature, will always be playing catchup, and perhaps that's fine. Unfortunately, the ARB is increasingly driven by political, rather than technical considerations, giving MS further opportunity to extend D3D's lead.
Gentoo did that in ~2002-2003 but they have dropped the project iirc
"If the only popular games using OpenGL use the same engine, that tends to make me think that people are not fond of programming for OpenGL in general, just one person/company."
Yes, but as you say they may have just simply created a kick-ass engine, in which case if you wanted to leverage OpenGL (cross-platform titles come to mind) there's less reason for others to create from scratch.
Combine that with the OpenGL-friendly Torque game engine and you've got a good pair of heavyweight tools.
From their site: "The Torque Game Engine started life as the technology behind Dynamix/Sierra/Vivendis products Tribes, Starsiege, and Tribes 2, and is an industry proven engine. It is currently being used by thousands of developers around the world with shipping titles such as Marble Blast, Orbz, Think Tanks, Tennis Critters, and the upcoming mecha game, Lore."
OpenGL isn't OOP because it's a procedural API, low-level API. DirectX isn't really OO either --- it just happens to use objects. If you want an OO interface to OpenGL, you should use a proper scene graph library.
A deep unwavering belief is a sure sign you're missing something...
If OpenGL v3 added a higher level API
That would be something like Open Inventor.
It appears that only the specification was released. No platform implementations are availible, so its not currently possible to make and use open gl 2 applications.
You seem to be very confused. XBOX is basically a GeForce3 system with some extra vertex processors, yes it supports D3D but your assumptions about APIs are wrong. NVIDIA actually extended D3D on the XBOX with a few OpenGL like features that don't even exist today on Windows versions of D3D. So rather than D3D giving hardware the advantage it holds developers back, in a situation where hardware developers are free to extend (as they can with OpenGL) they do and bring innovative hardware features to developers early. In the unique case of the XBOX NVIDIA actually threw in a few extra functions they'd always wanted to expose on Windows D3D but couldn't because D3D didn't let them. With the shackles off on XBOX they did.
The only reason D3D is the API on XBOX is a Microsoft business decision, technical merits have nothing to do with it.
Learn DX or D3D? You do know that D3D is discontinued and Avalon is the replacement so what will it look like? I personally suspect they'll clean up D3D and it may wind up looking a lot different. The graphics scheduling, and resource/context management will obviously be a major issue/headache.
As for OpenGL, OpenGL|ES will have way more volume than longhorn units shipped, it will be on every mobile device. So I could justifiably claim that if you don't learn OpenGL|ES now you will be left behind, but I'd never say anything so silly.
Cross platform compatability is often a major goal but it depends on your project and what you're developing. Let's be clear, the hardware details and graphics programming requirements tend not to change from platform to platform, so OpenGL suitability is not compromised by it's cross platform support, it just happens to be supported on many platforms. Hardware acceleration and consistent implementation are the primary design goals of OpenGL and it succeeds spectacularly well. Implying that because it is cross platform it is somehow compromised ignores the fact that the only reason D3D is single platform (or even exists for that matter) is Microsoft's proprietary control of the market.
Let me guess -- you've never been to an ARB meeting. ;)
Let's just say that the big dogs on the ARB are often as interested in preventing their perceived competitors from getting a leg up (no pun intended) as they are in advancing the state of the art.
As business becomes more cutthroat, the parties look for any and all advantage they can find. The ARB does a reasonable job of balancing the competing forces, but the price is the mediocrity of compromise/design by committee, excessive caution, and delay...
Some of the graphic effects (heat ripples etc.) require a DX9 video card so this is unlikely to work at all under Linux.
What are you talking about? The NVIDIA Linux drivers support the same OpenGL extensions as the Windows drivers, and they support the same set of GPUs - right up to the GeForce 6800. Why would an OpenGL-based game look any different between the two?
So the simple way to understand OpenGL code is to think of a really big state machine. Each call just modifies the currently existing state. The state persists until the state is changed - even to the point of maintaining it between rendered frames.
If you want Java bindings for OpenGL, there's two major projects.
JOGL, which is the basis for the formal bindings in JSR 231.
LWJGL which is a community driven project and somewhat akin to DirectX in that it also merges audio and input device APIs as well.
If you need some tutorials to get started, check out http://opengl.j3d.org in a couple of weeks when it gets officially opened and has lots of beginner tutorials to play with.
After that, the OpenGL Red Book is your friend.
Life is complete only for brief intervals in between toys or projects -- John Dalton
I you think that's all there to DirectX then you are horribly mistaken. There is also the debugging support, the easy to use tutorials and samples, as well as the integrated help. You mention Allegro, but you probably don't realise that Allegro uses DirectX for some things.
Also, your statement about more and more companies using OpenGL is false. More and more companies are using DirectX right now, even if you include all the Quake engine games.
-]Phreak Out[-
What about SDL?
What about it? It's a great idea.
But. It can't really compete. SDL is "Simple", and doesn't provide the same amount of functionality.
Also, SDL doesn't seem to be going anywhere. The 2.0 version has been 'in the works' for years now..
(I've written a bunch of posts on this.. The lack of good crossplatform graphics API:s, both for 2D and 3D is one of my pet peeves, and IMHO a major barrier to Linux on the desktop.)