Slashdot Mirror

Umm... it has OpenGL.

Feel free to knock us out with your s00p3r l33t UI design skilz.

Yeah, and the point of the Firing Squad article was that 8800GT cards (replacing the 8400/8600 at that price point) could be had for nearly the same cost as a 1950Pro, and are DX10 and have 512MB of memory instead of DX9 and 256. If you want to go cheaper, look for the older model cards, but remember these cards are sometimes outperformed by last generation cards (but support DX10/OpenGL 2.1).

That just reminded me that OpenGL still has yet to provide their answer to DX10 - hopefully still this year, but possibly next year, according to the latest info. On the plus side, OGL3 is supposed to run on any new hardware released after Nov 6, 1996 (it's an API change on current hardware). Still, most new features (e.g. geometry shaders) will still be extensions until mid-next year at this rate - a full year-and-a-half behind Microsoft (though still usable as extensions on older OS's like XP, unlike the canned DX10 [not the Alky hack]).

I just read that XP will be sold in shops for a few years more, so I don't think I wasted my money on that regard. But I was greatly misinformed about OpenGL on XP, as this page proofs. My bad, I should have checked my facts better.

I'd have to agree with you - I'd like to see proof/info on that. The design hit appears to be driver related, not Vista related. The poster possibly is referring to the MS's original compositing plan of using hardware overlays before deciding they're obsolete. OpenGL on nVidia cards do not use this, so that is not the cause of my problems. Still, the compositing desktop framebuffer should run at near native levels (as I said, 10-15% due to overhead) and it's not. According to Siggraph slides, nVidia and Khronos had worked together to get near-native speeds.

Most of my code changes I did for Vista are based on this article. I haven't had any luck with the PFD_SUPPORT_COMPOSITING or PFD_SUPPORT_GDI flags (same framerate).

after further research, there is a hardware implementation of 1.4 that converts calls to DirectX. It is frozen, but not deprecated. The OpenGL that was dropped was a software implementation of 1.3 (the one deprecated way back in Longhorn). This driver is not being used, so is not the cause of my slowdown.

This is true to only a minimal degree. nVidia does quite a few extensions, and they do give some access to new "stuff". In a lot of cases, it's rather minimal access though, and in other cases, it's basically nonexistent. Just for an obvious example right now, I don't know of any way to get at the geometry shader functionality via OpenGL. It simply doesn't fit well with the (current) OpenGL model.

EXT_geometry_shader4
What other stuff do you feel there's 'minimal' access to? nVidia has a history of doing real kitchen-sink extensions that expose EXACTLY what their hardware support (eg. NV_register_combiners).

ATI does far fewer extensions than nVidia, though we'll have to see whether that changes with the AMD buyout.

So far, I've found that their hardware features are well exposed. Plus, they do a nice line in hidden experimental extensions, which are good fun to play with.

It's true that OpenGL covers more of the market than I noted. It's also true, however, that of those, the only one that matters as a rule is probably the PS3. Getting a game to run decently on a phone (for example) involves a lot more than changing the way you display the graphics.

Agree. Plus, any PC game that's source-compatible with a phone is going to look crappy on the PC side. It just makes development a bit easier.
So yeah, PC360 is probably the only situation where I'd expect any low-level graphics code to be shared across platforms.

Yes and no -- they certainly have a lot of information, and in some cases it's quite helpful. OTOH, they still don't cover everything -- just for one obvious example, DirectX has supported instancing for quite a while. Under OpenGL, you could sort of imitate instancing, but that's about it -- and yes, nVidia has had an OpenGL "pseudo-instancing" demo for quite a while, but if you compare it to their real instancing demo that runs under DirectX, you'll quickly find that the DirectX version is still faster.

EXT_draw_instanced

I'm curious: when you say "every other recent console", do you have more in mind than the Wii (not to to slam the Wii -- I'm just curious what else you might have had in mind).

I was thinking of the NDS, PSP and NGC. I haven't gotten the chance to mess with a Wii, but I assume it's graphics API is just a revision of the NGC's.

This is true to only a minimal degree. nVidia does quite a few extensions, and they do give some access to new "stuff". In a lot of cases, it's rather minimal access though, and in other cases, it's basically nonexistent. Just for an obvious example right now, I don't know of any way to get at the geometry shader functionality via OpenGL. It simply doesn't fit well with the (current) OpenGL model.

EXT_geometry_shader4
What other stuff do you feel there's 'minimal' access to? nVidia has a history of doing real kitchen-sink extensions that expose EXACTLY what their hardware support (eg. NV_register_combiners).

ATI does far fewer extensions than nVidia, though we'll have to see whether that changes with the AMD buyout.

So far, I've found that their hardware features are well exposed. Plus, they do a nice line in hidden experimental extensions, which are good fun to play with.

It's true that OpenGL covers more of the market than I noted. It's also true, however, that of those, the only one that matters as a rule is probably the PS3. Getting a game to run decently on a phone (for example) involves a lot more than changing the way you display the graphics.

Agree. Plus, any PC game that's source-compatible with a phone is going to look crappy on the PC side. It just makes development a bit easier.
So yeah, PC360 is probably the only situation where I'd expect any low-level graphics code to be shared across platforms.

Yes and no -- they certainly have a lot of information, and in some cases it's quite helpful. OTOH, they still don't cover everything -- just for one obvious example, DirectX has supported instancing for quite a while. Under OpenGL, you could sort of imitate instancing, but that's about it -- and yes, nVidia has had an OpenGL "pseudo-instancing" demo for quite a while, but if you compare it to their real instancing demo that runs under DirectX, you'll quickly find that the DirectX version is still faster.

EXT_draw_instanced

I'm curious: when you say "every other recent console", do you have more in mind than the Wii (not to to slam the Wii -- I'm just curious what else you might have had in mind).

I was thinking of the NDS, PSP and NGC. I haven't gotten the chance to mess with a Wii, but I assume it's graphics API is just a revision of the NGC's.

Here are some facts, Ogl is just as supported on vista as is directX:

      1. Windows Vista fully supports hardware accelerated OpenGL;
      2. OpenGL applications can benefit from Window Vistas improved graphics resource management;
      3. OpenGL performance on Windows Vista is extremely competitive with the performance on Windows XP.

Read this full explanation:

http://www.opengl.org/pipeline/article/vol003_9/

What you just said is so completely wrong [opengl.org] it's not even funny.

I'm wrong that "I was under impression X"? Sounds pretty hard to be wrong when all I said was "I think" ...

Semantics aside, it seems my impression was incorrect: Windows Vista and OpenGL

1. Windows Vista fully supports hardware accelerated OpenGL;
2. OpenGL applications can benefit from Window Vistas improved graphics resource management;
3. OpenGL performance on Windows Vista is extremely competitive with the performance on Windows XP.

With a thorn like this in Microsoft's side, there is certainly a part of me that hopes that we will begin to see more OpenGL games released versus DirectX.

Don't get me wrong, DirectX is a nice graphics library, but the seriousness of the vendor lock-in is just staggering -- and scenarios like this are a perfect example of a game development company's worst fears.

This situation was created because not enough effort was put into OpenGL when it needed it the most to make it a truly cutting-edge standard. The blame for that particularly lies with Microsoft and their aggressive campaign for Direct3D (and DirectX). As a result, OpenGL languished for several years, with only incremental feature updates (to version 1.5, which IIRC wasn't even a real release, but more of a vendor patchset for 1.4). In the meantime, DirectX leapfrogged its way to version 9 with a ridiculous amount of features being added.

OpenGL 2.1 finally came out last August (http://www.opengl.org/documentation/current_versi on/) to very little fanfare. About the only companies it really mattered to were the Xbox competitors, namely, Sony and Nintendo. The PC gaming industry as a whole didn't care, because they had a solution that was "good enough" -- DirectX 9.

Now, OpenGL 3.0 is "on track" to be finalized at the end of this month. Whether that will happen is anyone's guess, but it looks like the DX10 situation has finally lit a fire under their collective asses. Who knows, we may even see an OpenGL 3.0 specification by September, but I'm not really holding my breath.
http://www.opengl.org/cgi-bin/ubb/ultimatebb.cgi?u bb=get_topic;f=3;t=015351;p=0

Of course, even though there's a brand spanking OpenGL almost ready to again kick Direct3D's ass performance wise, Microsoft has already taken steps to ensure that won't happen. OpenGL 1.4 (yes, 1.4!) is implemented in Vista as a translation layer to run Direct3D calls on the hardware. http://en.wikipedia.org/wiki/Direct3D_vs._OpenGL#P ortability This cripples OpenGL's performance advantage. Of course, if you want to run the newest OpenGL on the newest hardware, as you should, they've put another roadblock in the way with Vista: you have to use the Windows XP drivers, which disable the nice flashy Aero interface. At this point, you're probably thinking, "Wait, wasn't Aero a selling point of Vista?" Well, that certainly makes sense. Only hardcore gamers would want to trade off their interface for OpenGL's performance, but your average casual gamer doesn't care.

So even if OpenGL 3 is technically superior, publishers probably won't adopt it because of the widespread view that it's slow (thanks to Vista's emulation). iD Software will likely use it as they always have, but it'll become harder to explain to your average user why he needs to install unverified drivers and disable his nice flashy interface just so he can run said game.

It's almost sickening, really, when you think about the damage DirectX has done.

With a thorn like this in Microsoft's side, there is certainly a part of me that hopes that we will begin to see more OpenGL games released versus DirectX.

Don't get me wrong, DirectX is a nice graphics library, but the seriousness of the vendor lock-in is just staggering -- and scenarios like this are a perfect example of a game development company's worst fears.

This situation was created because not enough effort was put into OpenGL when it needed it the most to make it a truly cutting-edge standard. The blame for that particularly lies with Microsoft and their aggressive campaign for Direct3D (and DirectX). As a result, OpenGL languished for several years, with only incremental feature updates (to version 1.5, which IIRC wasn't even a real release, but more of a vendor patchset for 1.4). In the meantime, DirectX leapfrogged its way to version 9 with a ridiculous amount of features being added.

OpenGL 2.1 finally came out last August (http://www.opengl.org/documentation/current_versi on/) to very little fanfare. About the only companies it really mattered to were the Xbox competitors, namely, Sony and Nintendo. The PC gaming industry as a whole didn't care, because they had a solution that was "good enough" -- DirectX 9.

Now, OpenGL 3.0 is "on track" to be finalized at the end of this month. Whether that will happen is anyone's guess, but it looks like the DX10 situation has finally lit a fire under their collective asses. Who knows, we may even see an OpenGL 3.0 specification by September, but I'm not really holding my breath.
http://www.opengl.org/cgi-bin/ubb/ultimatebb.cgi?u bb=get_topic;f=3;t=015351;p=0

Of course, even though there's a brand spanking OpenGL almost ready to again kick Direct3D's ass performance wise, Microsoft has already taken steps to ensure that won't happen. OpenGL 1.4 (yes, 1.4!) is implemented in Vista as a translation layer to run Direct3D calls on the hardware. http://en.wikipedia.org/wiki/Direct3D_vs._OpenGL#P ortability This cripples OpenGL's performance advantage. Of course, if you want to run the newest OpenGL on the newest hardware, as you should, they've put another roadblock in the way with Vista: you have to use the Windows XP drivers, which disable the nice flashy Aero interface. At this point, you're probably thinking, "Wait, wasn't Aero a selling point of Vista?" Well, that certainly makes sense. Only hardcore gamers would want to trade off their interface for OpenGL's performance, but your average casual gamer doesn't care.

So even if OpenGL 3 is technically superior, publishers probably won't adopt it because of the widespread view that it's slow (thanks to Vista's emulation). iD Software will likely use it as they always have, but it'll become harder to explain to your average user why he needs to install unverified drivers and disable his nice flashy interface just so he can run said game.

It's almost sickening, really, when you think about the damage DirectX has done.

I hate to gripe, but there are a few glaring misconceptions that need to be addressed in your post. Mainly this claim that DirectX/Direct3D is "pointing and clicking in Visual Studio." You're probably thinking more along the lines of XNA, but core Direct3D is a pretty basic interface to the graphics hardware (you're dealing with vertex buffers, texture objects, vertex/pixel shaders and their associated inputs, and a number of state parameters). Functionality wise it offers essentially what OpenGL does, except wrapped up in a platform-specific COM interface. There is a higher level library called D3DX that adds some helper functions for loading textures and meshes and doing vector and matrix math, but even that's quite a ways from the "pointing and clicking in Visual Studio" you mentioned.

DirectX isn't "easier" than OpenGL/OpenAL (in fact, OpenAL is higher level than DirectSound or XAudio, if you've ever used any of those APIs). The extra price of OpenGL comes not from "the fact they are intended for real developers" (whatever that means), but rather from the fact that it's not exactly the cleanest API at the moment (but that will change in a few months when OpenGL 3.0 finally hits). In combing through this thread I'm surprised I haven't seen mentioned that one big reason Direct3D took off over OpenGL on Windows is because OpenGL is notoriously difficult to write stable, performant drivers for. An article in issue #2 of the OpenGL newsletter mentioned how the old object model caused unnecessary driver overhead, for instance: http://www.opengl.org/pipeline/article/vol002_3/

Back in the late 90's when all this stuff was taking off, major games like Half-Life, Quake 2, and Unreal had several graphics renderers encapsulated in DLLs. Half-Life had software, OpenGL, and Direct3D. Quake 2 had software, OpenGL, and I think PowerVR or something. Unreal had a heck of a lot of different renderers, I know software, D3D, Glide, and OpenGL were among them. They did this because driver performance and compatibility was such a big issue back then, by writing to more than one API they could cover all the bases (card X doesn't run GL well but does run D3D well? Then we support that scenario. Card Y runs D3D poorly but does GL well? We support that, too). At the end of the day, the major graphics vendors ended up putting out really excellent D3D drivers and that helped the API out significantly. D3D was the only hardware-agnostic solution back then aside from OpenGL (ATI wasn't implementing Glide), and the API mapped to the general hardware case well enough that it was relatively easy for most vendors to write good drivers for.

Like pretty much everyone else who isn't a Microsoft employee, I do wish Microsoft would have adopted OpenGL as the sole hardware graphics standard instead of running off and creating their own thing and creating yet another obstacle to porting games over to different platforms (and to be clear, there are MANY more issues to porting games to different platforms than I/O APIs, for some reason I'll never understand that point is lost on a lot of people), but painting game developers who use DirectX as corporate Microsoft shills isn't the most honest or productive characterization of why things are the way they are. What is productive is looking at the technical flaws present in OpenGL and rectifying them, which is something the Khronos ARB Working Group has done an excellent job of.

As far as id is concerned, Carmack is using the Direct3D-only Xbox 360 as his benchmark development platform at the moment (you can go back to his Quakecon 2005 speech for a reference on that). That doesn't mean he's turned into a D3D fanboy, the Windows version of Rage is still going to be OpenGL. What it does mean is, these days he's probably more concerned with things like efficient multicore utilization, robust and productive content developer toolsets, and having a nice stable platform with excellent developer support as a testbed (something Mic

>>> OpenGL 3 is announced recently: http://www.opengl.org/cgi-bin/ubb/ultimatebb.cgi?u bb=get_topic;f=3;t=015351;p=0

Is it just me or does that page give you folks a nostalgic déjà vu-ish feeling?

Thanks for the informative URL. However the / at the end is wrong. http://www.opengl.org/cgi-bin/ubb/ultimatebb.cgi?u bb=get_topic;f=3;t=015351;p=0 should work fine.

Wow, what a load of FUD. OpenGL is completely supported under Vista and is in no way routed through DX:

http://www.opengl.org/pipeline/article/vol003_9/

OpenGL 3 is announced recently: http://www.opengl.org/cgi-bin/ubb/ultimatebb.cgi?u bb=get_topic;f=3;t=015351;p=0/.

While only sort of relating to Linux, I'd be interested to hear any comments about unlocking the potential of hardware via OpenGL.

I fail to see how it has any superiority, when the extensions you are mentioning are all IHV unique and the implementations are different across the board. Hell, you could do a ton of things that geometry shaders allow in directx 9 (and opengl), but the algorithms are forced to run on the CPU.

BTW, OpenGL 3.0 is the version that is supposed to bring opengl to par with directx10, by adding support for things like geometry shaders and refactoring of the api. If you are interested, you can read more about it at http://www.opengl.org/pipeline/article/vol002_1/. Or you can pretend like opengl is the best thing ever, and miles ahead of directx, when in reality, it has a lot of catching up to do.

You may not call your graphics library "OpenGL", because OpenGL is a registered trademark of SGI. Have a look at the page footer of http://www.opengl.org/

Open Source on the other hand is not a registered trademark, so the OSI are pissing into the wind.

OpenGL already has extensions to support DirectX features, they were added by NVIDIA.

Also, the entire OpenGL API is being redesigned from scratch (after 13 years of active service). The first version is currently named 'Longs Peak' and will have feature parity with the current version of OpenGL. The next version which is called 'Mount Evans', will build on Longs Peak, adding DirectX 10 features.

From what I've seen of the new API, DirectX is in for a serious challenge (well, I hope anyway).

More information about the new API can be found in the OpenGL newsletters.

Emulation software for DX9 - ha - you apparently missed the fact that Vista is actually built on top of DX9, not DX10. DX9 is backward compatible to DX1, so you should technically be able to run any DirectX game on it. Aero is a DX9 based GUI (which is why it works on DX9 cards, but not earlier cards) with some limited forward compatibility with DX10 (so it can, say, run DX10 windows in a DX9 windowing system without compositing, which I believe was a change actually added to DX9.0c).

The problem is that Vista has a new driver interface and Microsoft puts the onus on hardware developers to create updated drivers that are not done in-house. Anytime you need to move off a heavily tested and debugged platform to a new one, you're going to have some growing pains. Drivers are usually the most susceptible to change because they're at the lowest level - even Apple has had issues there (moving from OS9 to X.0, and X.0 to X.2, as I recall, required rewriting the drivers)

OGL is a different matter - MS has made Vista OGL 1.3 compatible (so no 1.4, 1.5, 2.0, 2.1 features), but my understanding is that this is a software driver and it should work with any OGL 1.3 or lower program, even with no graphics card. They also deprecated the API and plan to remove it from Windows after 2 more major releases and then only support Direct X. Technically it should still be possible to use OGL > 1.3 in Vista by getting the card's callbacks similar to how XP worked, but there currently is a speed cost to that, which is one reason why OGL is slower than DX. Later this year OGL will get two new "profiles" that should address speed issues. The first, "Long's Peak" includes backward compatibility as well as a "Lean and Mean" profile that is not backwards compatible, but will be faster for people that don't need many older features. The second "Mt. Evans" due in October is a lot like DX10 - it only works on very new graphics cards and is not backwards compatible (see this doc for more details. I wouldn't expect to see a "Long's Peak" card until sometime in 2008, so Microsoft has a good jump on OGL.

No... I think there's some confusing language in the introduction of that article. Vista will support OpenGL ICD's and nVidia and ATI are already working on these. Apparently there was some question about the issue at first, but this is now old news from almost a year ago. I think what the article meant was that currently nVidia and ATI do not have the vista drivers for it. Correct me if I'm off base on this one, but that's how I read it.

Looks like DirectX 10 functionality - unified (geometry) shader and like will be available in in the NVIDIA drivers very soon. Seems the entry points for new OpenGL extensions are already present in the driver nvoglnt.dll (96.89), including
GL_NV_geometry_shader4
GL_NV_gpu_program4
GL_NV_gpu_shader4
and new Cg profiles
All we need now is header file
Chances are, for OpenGL directX 10-like functionality will be here before VISTA. Another one for swith to OpenGL from DirectX. Also it will be at least couple of years before majority of the gamers switch to VISTA, but with OpenGL developers can utilize latest GPU to their full potential on the Windows XP.
More about it in this thread form OpenGL.org:
http://www.opengl.org/discussion_boards/ubb/ultima tebb.php?ubb=get_topic;f=3;t=014831

This is not what CPU's are good at. CPU's are general purpose processing units. They do bad code well. In fact Intel is particularly good at running crazying branching all over every where code with no particular sense to it. CPU's are good at doing un-predictable things to a few memory locations. Even the MMX/altivec etc code really only are set up for doing 4-16 memory locations at a time. Not much compared to GPU's, which are designed for doing 256x256 to 2048x2048 things at a time. That's several orders of magnitude more.

So again, GPU's do a single thing to a bunch of things well. Their memory model is setup with that in mind. Its all about keeping the stream running as fast as possible.

So what other things might this be used for? Check the GPGPU sites for specifics, but mesh based simulations come to mind, and as another poster said, the same kinds of things as the physics cards. The thing is, gaming keeps getting higher levels of graphic fidelity, to the point where if the underlying physics is wrong, its distracting. People don't need to know physics to know something looks funny. So game titles, and others, are increasingly spending time on simulations.

Today's GPU's can run a program for each and every pixel with 60fps+ framerates. These programs can do more than just set a color, or read a value out of an image, and write it to the destination pixel. They can calculate accelerations, velocites, etc, based on force applied. There really is alot of freedom. My personal favorite flavor of talking to GPU's is this one: http://www.opengl.org/documentation/glsl/

And the other thing is, the GPU is powerful, and a BIG part of the total budget for a PC now. So it seems like it should be used for more than high end games, and the thing is, with the exception of the occasional high end graphics professional, it really isn't right now.

MacOSX changed that to some extent, but seriously programmable GPU's can do a lot right now. Notice that MacOSX runs well on the iBooks, which don't have high end GPU's, but integrated Intel graphics. But games like BattleField2 requires the high end GPU. The point is there is ALOT of room to run in the high end GPU's, and it is basically idle for everyone not playing BF2 http://www.ea.com/official/battlefield/battlefield 2/us/ or some other modern game title.

So you can see why ATI (and NVidia, etc) would want to find other reasons for these cards to exist. Otherwise, the game market will go even more to XBox/PS2, etc, because marketing aside, there is little reason to put a high end graphics card in most peoples machines. The GPU hardware will go to those boxes, and Intel's integrated stuff will win the day. (cheaper, easier to build a system around)

Actually, the OpenGL in Vista has been set up so that vendors can provide full OpenGL acceleration. This story on the OpenGL site has shown that the previous concerns about GL support in Vista have since been addressed. As for emulating through DX, I'm fairly sure it's up to the 3D card vendor (in the Windows model) to provide a DirectX- and OpenGL-compliant driver, so if they support DX and not GL that's as much their fault as it is anyone's.

what

...they've at least promoted programmable shaders to core features:

http://www.opengl.org/documentation/current_versio n/

Anyone remember the old days of "IBM-PC compatible" gaming? Will my sound card be supported? Is my video card the right kind? Using the OS as a layer of abstraction for compatibility makes it easier for the developer.

Agree and good comparison! Making games for Linux now is like what making games for DOS was years ago.

Obviously you have not tried developing games for Linux. If you had (and actually given it a good go), you would have come across the wonderful world of SDL, OpenGL, OpenAL, etc.

If OpenGL "dies" somehow, say bye to already troublesome gaming on Mac too.

In fact OS X desktop uses OpenGL extensively. Quartz Extreme and Quartz 2D Extreme (not enabled yet) relies on OpenGL.

I don't get how OpenGL can be "bought" anyway. OpenGL is an industry board already,

http://opengl.org/about/arb/overview/

Notice 3dLabs, Intel, Apple, Sun, Dell and IBM which lives its good days again?

It is not some sort of a "geek" "4 guys coding" project which Microsoft can take over. Military even relies on OpenGL.

They need a clarification , people think opengl may be effected at all by SGI going down. No, it can't. I tell you, lets say all of those board members gone chap. 11, DARPA will take over the OpenGL. Military simulations, petrol industry...

Do you *NEED* .NET? Can you learn something else? Something cross platform, maybe? Surely there's something out there that will do the job?

Got one for you. I get a finders fee though. Okay? Here it is: http://www.opengl.org/

Back in the late 1990s and earily 2000s, I used a VRML plug-in for the Windows version of Mozilla called Blaxxun Contact. I think when X3D came along and replaced the VRML97 standards (both defined by The Web3D Consortium, things became confusing. Of course there are other graphics standards such as OpenGL and SVG that are also used. DirectX will slow you down.

You are aware what you're asking for makes no difference if you pull right from the framebuffer or render back to main memory? Your question seems to be backwards thinking. You setup the scene correctly instead of render out a framebuffer then pull that out and modify it over and over. RTT and shaders were made to avoid this in the first place. You ideally only want to make a few 'passes' per frame.

If you're really intersted in graphics:

      http://www.opengl.org/

Probably going to be modded down as a troll, but...

Alternatives does exist. Besides Direct3D and DirectInput, which realisticly speaking are the ONLY pieces of DirectX that actually work well (the rest being just too much bother to be worth it), DirectX sucks ass. And yes, IAAGD (I Am A Game Developer).

It says it was invented and patented by two guys in 1999, one year before Carmack reinvented it in 2000 for doom3.

OpenGL is now a "industry group"/board for long time.

http://www.opengl.org/

Whatever (sad!) happens, nothing happens to OpenGL.

Look at members
http://opengl.org/about/arb/overview/

It is kind of similar to hardware, the PowerPC board. So when Apple gives up PowerPC, nothing happens to powerPC since

http://www.power.org/kshowcase/view/browse_profile s/mp_browse

If Apple did not give up powerPC and it went chap. 11, Power Architecture would still continue.

OpenGL is now a "industry group"/board for long time.

http://www.opengl.org/

Whatever (sad!) happens, nothing happens to OpenGL.

Look at members
http://opengl.org/about/arb/overview/

It is kind of similar to hardware, the PowerPC board. So when Apple gives up PowerPC, nothing happens to powerPC since

http://www.power.org/kshowcase/view/browse_profile s/mp_browse

If Apple did not give up powerPC and it went chap. 11, Power Architecture would still continue.

OpenGL ARB is a group that is independent of SGI. They will keep on going on; with folks like Apple, Sun and IBM, and the major card manufacturers behind them, I don't think Unix folks have anything to fear. I wonder what major stuff SGI was contributing lately, anyway?

No.

and now that SGI will more than likely be leaving the playing field, wont this mean that OGL will belong to microsoft?

No, the OpenGL ARB controls OpenGL, not SGI. Check the website.

who will more than likely take it, lock it up, and sue the living fuck out of anyone who implements it? (read, makes free software implementations without paying absurd royalty costs)

No. SGI is far from the most important company relying on OpenGL. Check the ARB member list: 3DLabs, Apple, ATI, Dell, IBM, Intel, NVIDIA, SGI, and Sun Microsystems.

OpenGL is fine.

Check out:
http://www.opengl.org/discussion_boards/cgi_direct ory/ultimatebb.cgi?ubb=get_topic;f=12;t=000001

OpenGL 1.4 support, emulated by D3D?
Yeah right, good luck convincing slashdotters that "Vista Won't Suck" :-D

Bollocks - forgot to paste in this link for the Quake 4 relief mapping. What a numpty...

It wasn't the one I was thinking of - but it does show how "out of date" Tomshardware is...

The article I was thinking of was actually based on "Relief Mapping" (which AFAIK is better than parallax mapping). The link is here. Unfortunately the link to the zip is broken. But the more recent post on the subject relates to Quake 4 which can be seen here. The links (for DOOM and Quake 4 are both working).

Can opengl.org stand the /.?

I believe this is the link you were looking for:
http://www.opengl.org/discussion_boards/ubb/Forum3 /HTML/011292.html

IIRC this was the first public discussion of the technique.

Two things:

1. I've recently been in correspondence with Bruce Morgan of Microsoft's IE7 team about their continued, misleading use of theproduct identifier 'Mozilla/4.0' in their user-agent string. He was unapologetic, unrepentent and wholly unprepared to consider changing it. The gorilla not only intends to continue to misbehave, it's perfectly happy for everyone to know it's misbehaving.
2. Microsoft is deliberately crippling Open GL performance in Windows Vista. This, again, is blatant, unashamed abuse of monopoly - deliberately making it harder to build cross-platform apps which perform well on Vista

In summary, Microsoft is behaving as badly as ever: the very opposite of good corporate citizens.