Quote:>I could be wrong but I think glu just calls OpenGL
>functions - any old glu will do, it doesn't have to
>be part of the driver.
The 3Dfx standalone drivers were never part of the ICD mechanism. That is
why they had to supply GLU to claim the name OpenGL. Because they were too
lazy (or greedy) to bother doing it the driver had to be renamed to "Quake
I can't remember clearly now. But, I think some of the function calls were
different so the system glu or mesa glu was useless. You had to build a
version specifically linked against it.
After 3Dfx started pulling stunts with ropey drivers and leaving customers
of cards that weren't the latest model out in the cold, I decided from that
point on never to support a proprietary 3Dfx feature ever again.
Coincidently they went bust within the year.
Quote:>In fact I recall reading an article on this where
>people were complaining that gluNurbs couldn't be
>done in hardware because glu wasn't part of the ICD.
I remember seeing an item on opengl.org last year where some IHV was
* an accelerated GLU implementation. Never heard of it again.
Replacing the system GLU with an IHV GLU is a bit *. Although it would
have to be aware of what implementation was running, I don't see why it
couldn't be done.
My own position on the OpenGL ICD issue is that Microsoft should be forced
to allow anyone who wants to produce a graphics API have free and fair
access to the underlying driver mechanism without being wrapped in NDA's. I
don't see it any differently to the Java/Netscape issue.
They're using their monopoly control of the Win32 platform to stifle
competition of their own competing (D3D) product. Following on from this,
the cost to developers and customers of the D3D version mess is most likely
measured in the hundreds of millions.
Charles E Hardwidge