Note in particular the contact email address at the end, and the words “next generation”. Could they actually be planning to - gasp - update opengl32.dll?
Don’t understand the bit about working on hardware drivers though. How is this Microsoft’s job? XBox, maybe?
I fail to see how Microsoft could get by without aggressively making sure they’re the best-performing OpenGL platform on the market. Workstation people would be just too glad to have an excuse to go to Linux instead.
Microsoft needs to make sure OpenGL runs best on Windows, for Microsofts own interests. Whether they understand this, I have no idea
Since D3D started Microsoft has been caught between the need to support OpenGL and be competitive and the need to crush OpenGL with their proprietary API and be anti-competitive. I’m sure both sides of the issue have been clear to them since the beginning.
Originally posted by jwatte: Microsoft needs to make sure OpenGL runs best on Windows, for Microsofts own interests. Whether they understand this, I have no idea
No they don’t. The ball is in the individual hardware vendors hands and they have to make sure their graphics card is the stablest fastest one of all. They (I mean MS) need consultants, who will be helping other companies.
The number of job offers involving game development + medical, military, scientific needing some GL graphics compared to driver writers for GL seem to be equal. Very odd.
[This message has been edited by V-man (edited 02-24-2003).]
Microsoft does have some measure of responsibility for OpenGL under Windows. The reason that Win32 GL programmers have to upload extensions for Gl 1.2-1.4 manually is because Microsoft has not updated OpenGL32.lib. That is their library that serves as a go-between for the user and the driver.
The question as to how Win32 programmers will access GL2.0 has been around since 2.0 was announced. There were rumors that the ARB itself might take over OpenGL32.lib, or write a new interface library. But now, it appears that Microsoft may be willing to play ball and write it themselves.
If they did write it themselves it would be a change of heart on a, ehem, rather large scale.
I’m guessing jwatte is closer to the truth. Not supporting GL fully is probably hurting MS now in the “serious” workstation market, rather than benefiting D3D. D3D is still an excellent product though, don’t get me wrong.
I was going to say actually, that if this is true, then thats excellent news for me at work!
[This message has been edited by Robbo (edited 02-25-2003).]
Say MS did upgrade their opengl32.lib/dll to 1.4 - what would happen if a card was installed that only supported, say, 1.2? Would the 1.4 exported functions be null?
Dont they have to implement all the 1.4 features via software? so that if the card doesn’t support a particular feature it falls back to the M$ generic device.
Actually, provided the driver is a full ICD and not some old Vodoo mini client driver, it’s the drivers job to provide a software fallback, noy Microsofts. If you can’t get a hardware pixelformat then you get MS’ sw implementation.
Originally posted by V-man: In some sense, GL doesn’t have version numbers, just added extensions on top of a base.
Not really. GL functions are exposed by the normal dllexport mechanism, and can be statically linked against or retrieved dynamically with GetProcAddress(). GL extensions can ONLY be retrieved dynamically via the GL extension mechanism; GetProcAddress() won’t work, or at least won’t portably work.
I don’t think you can treat the two as interchangeable.
No knackered, but the driver won’t deal with certain pixel formats (16 bit color and stencil on older cards for example, or accum. buffres) which might give yoiu the MS software renderer. This is exactly the way things work now, if your card doesn’t support colour logic ops, edge flag arrays or two sided lighting in hardware, you don’t get MS’ implementation you just get those particular functions performed in software.
I’m not saying that the cases are interchangeable with the current situation.
GetProcAddress should always return NULL for extensions. Who has succeeded in getting valid pointers?
But if MS creates a 1.4 DLL (and maybe they need to make changes to the ICD mechanism), a driver that implements an older GL version might work.
I just did a quick Google search for any news regarding Microsoft resigning from the ARB. There was none. I would imagine that it would have, at the very least, made the front page of OpenGL.org.