Why is Microsoft still reluctant to release updated version of their opengl and glu dlls? or are they still waiting for OpenGL 2.0?
Thanks.
Microsoft wants OpenGL to die.
Sad, but true.
Or they want “complete control”.
Bastards!
I too wish they would stay up to date with OpenGL.
I can’t see why they just don’t license it, then create classes around it (like MFC).
I suppose someone could do this themselves, but it’s extra work.
It would just be nice if their agenda could shared.
Or you can use MESA; haven’t done anything with it yet, but when time permits!
Sad but True… Microsoft wants everyone to use their &^#*&$^@#% DirectX. OpenGl is a thorn in their b**t.
Anyway, here is an interesting article on gl 2.0.
http://www6.tomshardware.com/graphic/02q1/020222/opengl-01.html
I’m not a M$ employee, and I hate MicroSoft for various personal reasons. However, I think you’re wrong.
MicroSoft is a permanent ARB member. Microsoft and SGI worked together, some times ago, in order to write the specifications of a new API called Farenheit. The project is dead, but M$ never used its big weapons against GL.
True, M$ attempts to put Dx everywhere. But if it wanted to kill GL, GL would be already dead.
I think D3D will become more and more GL-alike and, at some point in the future when we all have 6 fingers a hand and live on Mars, the two API will be merged. M$ buying SGI patents is a step in this direction, IMHO.
Anyway, how is this subject related to advanced GL programming ? 
Julien.
There are more features in OGL 1.2 and 1.3, but M$ has not implemented them in for Win98, ME, and NT.
I agree, M$ is buying the SGI patents to make Direct whatever more OGL like. I guess this is a good thing.
Personally, I don’t completely understand why MS still has a seat in the ARB. They haven’t contributed anything or even updated their drivers and/or provided any kind of decent support in years. Their ‘SDK’ for OpenGL (if it can be called an SDK anyway) is hopelessly outdated, so is their system library and their developer support for anything GL related on the web, and I can’t see them ever updating them, for obvious reasons.
There’s enough developer resources out there from other vendors though, so I’d say we’re not really dependent on what MS puts out (which may be something that they’re not quite used to). So, I personally stick to the resources provided by other companies and not worry about MS at least in this case 
And, in case anyone wonders, yes, I am one of the persons who thinks that MS should be prevented from monopolizing any more of the computer market. A monopolized market is not a free market.
Just my $0.02
Just my $.02. But has anyone looked into whether the Video card Co’s pushed MS NOT to update there OGL so they could develop there own SDK’s to try to sell more card’s. ie NVidia’s drivers\implatation seems more stable and mature so developers may stick to that and avoid ATI’s. Then gamer’s would tend to gravitate towards NVidia’s cards.
Even if MS did make a updated OGL driver\SDK it would not be as good as the Video card makers simply because each maker uses different approach in hardware so they would make a better more tweaked driver than MS could ever make.
Dave
Why would anyone push MS not to update their drivers? MS is providing a software renderer, so puhleeze… and even if not, why would that make the hardware vendors sell less cards than otherwise? Doesn’t really make sense to me.
But it’s not really about the functionality of the ‘driver’ - the least MS could do is provide support for at least halfways recent developments in their systems. Prime example are the headers that ship with MSVC.
Afterall MS is a member of the ARB and hence also ‘governs the OpenGL specification’. They have the resources and should have the knowledge to provide decent support for OpenGL in their products, especially their products for developers.
The point is: they just won’t.
So, to the original poster: don’t wait for MS to update anything, 'cause most likely you’ll end up waiting until you’re too old to code anything.
Go with the drivers your card manufacturer provides, and with the OpenGL SDKs that they or other vendors provide. There’s a lot of material out there, just don’t expect to get any from MS
MicroSoft is a permanent ARB member
deepmind you should learn more about politic and strategy 
Being an ARB member does not mean you’re happy with it specially in MS case. You can be sure of one thing about MS concerning OGL : the former wants the later to be down, full stop. Remember the IE/Netscape war. The only thing that keep OGL alive is OGL developers, ARB and platform independance…
M$ buying SGI patents is a step in this direction, IMHO.
It’s a step in another try to snipe OGL you mean 
[This message has been edited by haust (edited 02-25-2002).]
I find it incredible that after all this time, there still are people who post stuff like this.
The solution is simple:
Step 1. buy a recent graphics card
Step 2. install the latest drivers
Step 3. get the latest glext.h, wglext.h and whatever else there is.Step 4. begin the learning process
If you dont have hardware acceleration, performance will be so incredibly bad that you will eventually want to buy one anyway. So why fight it?
Yes I know, having a software version of GL is nice for testing, but there is MESA for that.
Conclusion: M$ is not needed.
V-man
Just in case it isn’t already obvious
1)Microsoft doesn’t need to ‘support’ OpenGL, because contrary to D3d, GL is not dependent on M$ provided layers
2)They could only be bother to provide an updated software implementation anyway, because they don’t have their own graphics chips. And who wants a sw implementation?
3)Hardware vendors already have GL1.3 drivers for their cards working without M$ supporting that. So whaddayawant?
Your typical article, really:
in Direct3D:
“Also, when new features are introduced, Direct3D offers a standardized way of accessing them.”
Hmmm, Pixel shader 1.4 vs Pixel shader 1.1 anyone?
in OpenGL weaknesses:
“I mention extensions here too. Though they are powerful, they do make code messy, very much so at times. They also make it confusing with any compiler that doesn’t offer reference tracking (browse file)”
Interesting, I heard about D3d developers having to use hrmpf->GetDeviceCaps and taking different code paths accordingly, so I do suspect that adjusting your app to work with different hardware can’t really be any easier in D3d than in OpenGL. Oh well …
Which brings us to the argument of per fragment operations. There will never be software emulation support for these. You end up with DeviceCaps versus extensions. This is not an issue I would dance around in comparison articles, but that may only be me.
Even better:
“There are two major implementations of OpenGL for Windows: One from SGI version and one from Microsoft. The Microsoft version is based on the SGI implementation. Since the latter is no longer supported, it is recommended that you use the Microsoft version. It corresponds to OpenGL 1.1, but there are no newer headers and libraries available anywhere else”
Hmmmm
[This message has been edited by zeckensack (edited 02-26-2002).]
V-man, you make an elegant and excellent point.
Software, go with MESA.
Hardware, go with vendor.
Looks clear cut to me.
I’m going to review the licensing for MESA.
Also, the only reason why I would want to go with an sw implementation is when hw does not work. Don’t know why this happens sometimes, but it does happen, so the sw implementation is a necessary backup.
[This message has been edited by lobstah (edited 02-27-2002).]