MS quietly dumps Windows OpenGL support ??????!!!!!!!!
Eugene Mazur
Paul Miller
> What do you think/know about it?
This isn't really anything new. It's been pretty clear what Microsoft
thinks of OpenGL, and there has been little to no work on their software
implementation.
Despite Microsoft's efforts to kill off OpenGL, OpenGL is still well
supported by hardware vendors such as NVidia and Diamond, and by
libraries like Mesa, which is faster than Microsoft's implementation
anyway and supports alpha channels.
--
Paul Miller - st...@fxtech.com
Frans Bouma
> > http://www.theregister.co.uk/991129-000007.html
> > What do you think/know about it?
>
> This isn't really anything new. It's been pretty clear what Microsoft
> thinks of OpenGL, and there has been little to no work on their software
> implementation.
There isn't gonna change anything at all. So what's the point?
the ICD's cardmanufacturers had to supply are now also created by
the manufacturers themselfs and not MS.
And btw: the opengl dll's for win32 aren't coming from SGI either.
> Despite Microsoft's efforts to kill off OpenGL, OpenGL is still well
blablabla. no-one is gonna kill OpenGL. MS isn't that stupid.
I think the cardmanufacturers who have to spend A LOT of money to
produce an ICD suffer more from the fact that OpenGL is not
available in a DX driver model than the customers.
OpenGL WAS mostly a workstation API, it's now more and more coming
to the desktop of average joe's. But also understand most desktop
videocard makers design Hardware with DX in mind, not opengl.
> supported by hardware vendors such as NVidia and Diamond, and by
diamond who?
diamond is just a crappy driverkiller, creator of cheap hardware,
and if ANY company makes a mess with drivers, it's diamond. please.
> libraries like Mesa, which is faster than Microsoft's implementation
> anyway and supports alpha channels.
errrr... mesa is faster? with what? opengl software rendering?
well.. good luck. :) who carez anyway.
Do you really miss the alphachannels? or do you miss the alphaplanes!?
(a little different IMHO)
you can't create several rendercontexts with alphachannel and blend them
together automatically. But do you need to?
here are the limitations of the opengl32.dll from ms; (from the
MSDN lib (june version)
Limitations
The generic implementation has the following limitations:
Printing.
You can print an OpenGL image directly to a printer using metafiles only. For more information, see Printing
an OpenGL Image.
OpenGL and GDI graphics cannot be mixed in a double-buffered window.
An application can directly draw both OpenGL graphics and GDI graphics into a single-buffered window, but not
into a double-buffered window.
There are no per-window hardware color palettes.
Windows NT/2000 and Windows 95/98 have a single system hardware color palette, which applies to the whole
screen. An OpenGL window cannot have its own hardware palette, but can have its own logical palette. To do so,
it must become a palette-aware application. For more information, see OpenGL Color Modes and Windows Palette
Management.
There is no direct support for the Clipboard, dynamic data exchange (DDE), or OLE.
A window with OpenGL graphics does not directly support these Windows NT/2000 and Windows 95/98 capabilities.
There are workarounds, however, for using the Clipboard. For more information, see Copying an OpenGL Image to
the Clipboard.
The Inventor 2.0 C++ class library is not included.
The Inventor class library, built on top of OpenGL, provides higher-level constructs for programming 3-D
graphics. It is not included in the current version of Microsoft's implementation of OpenGL for Windows
NT/2000 and Windows 95/98.
There is no support for the following pixel format features: stereoscopic images, alpha bitplanes, and
auxiliary buffers.
There is, however, support for several ancillary buffers including: stencil buffer, accumulation buffer, back
buffer (double buffering), overlay and underlay plane buffer, and depth (z-axis) buffer.
---------
Perhaps it's me, but did I see several 'NT/2000' thingies in there?
FB
Frans Bouma
> Look at
think: poop.
know: better
FB
Andrew Beatty
wrote:
> There isn't gonna change anything at all. So what's the point?
> the ICD's cardmanufacturers had to supply are now also created by
> the manufacturers themselfs and not MS.
>
> And btw: the opengl dll's for win32 aren't coming from SGI either.
>
>> Despite Microsoft's efforts to kill off OpenGL, OpenGL is still well
>
> blablabla. no-one is gonna kill OpenGL. MS isn't that stupid.
> I think the cardmanufacturers who have to spend A LOT of money to
> produce an ICD suffer more from the fact that OpenGL is not
> available in a DX driver model than the customers.
I'm trying to understand the situation here. Is it the case that:
1. MS' opengl32.lib (on NT4 and Win98?) is basically an interface to
whatever ICD is installed with your hardware. ie. Most of the library
functions are just stubs that call the ICD functionality ?
2. Win2000 will be the same.
3. The support that was withdrawn was that MS would write these
drivers for the ISVs ?
4. The end result is that it will take longer for OGL hardware support
to be widespread on Win2000 ?
Thanks, Andrew.
Paul Miller
Huh?
> the ICD's cardmanufacturers had to supply are now also created by
> the manufacturers themselfs and not MS.
ICDs always have been created by the manufacturers. Microsoft was going
to provide a smaller driver interface (like the Win9X MCD) but killed it
shortly before it was finished.
> And btw: the opengl dll's for win32 aren't coming from SGI either.
Who said they were?
> > Despite Microsoft's efforts to kill off OpenGL, OpenGL is still well
>
> blablabla. no-one is gonna kill OpenGL. MS isn't that stupid.
Huh? Microsoft has done everything they can think of to kill it.
> I think the cardmanufacturers who have to spend A LOT of money to
> produce an ICD suffer more from the fact that OpenGL is not
> available in a DX driver model than the customers.
ICDs are harder to write, yes, but they can be a lot more efficient.
Most vendors have decent ICDs now so it doesn't really matter.
> OpenGL WAS mostly a workstation API, it's now more and more coming
> to the desktop of average joe's. But also understand most desktop
> videocard makers design Hardware with DX in mind, not opengl.
Most vendors are designing with both in mind, now.
> > supported by hardware vendors such as NVidia and Diamond, and by
>
> diamond who?
> diamond is just a crappy driverkiller, creator of cheap hardware,
> and if ANY company makes a mess with drivers, it's diamond. please.
Diamond has a professional OpenGL board called the FireGL1 that has the
best Windows OpenGL drivers I've seen on a PC. And the board is *fast*
and pretty inexpensive (less than $900). Sounds like you had a bad
(childhood?) experience with Diamond. Diamond's professional boards a
are *very good*.
> > libraries like Mesa, which is faster than Microsoft's implementation
> > anyway and supports alpha channels.
> errrr... mesa is faster? with what? opengl software rendering?
> well.. good luck. :) who carez anyway.
Yes, software rendering. Plenty of people care, such as anyone with a
laptop. And software OpenGL on a PIII500 can be extremely fast for a lot
of operations.
Good luck with what? You're not making a whole lot of sense.
> Do you really miss the alphachannels? or do you miss the alphaplanes!?
> (a little different IMHO)
Same thing, when referring to destination alpha (which I assumed people
would understand I was referring to. Guess not.)
> you can't create several rendercontexts with alphachannel and blend them
> together automatically. But do you need to?
Huh?
> Printing.
> You can print an OpenGL image directly to a printer using metafiles only. For more information, see Printing
> an OpenGL Image.
OpenGL does not have a printer interface because it is platform and
windowing-system agnostic.
> There are no per-window hardware color palettes.
Bummer. Should get an SGI workstation then.
> There is no direct support for the Clipboard, dynamic data exchange (DDE), or OLE.
> A window with OpenGL graphics does not directly support these Windows NT/2000 and Windows 95/98 capabilities.
OpenGL is platform and windowing-system agnostic. If you want those
features, add them yourself.
> The Inventor 2.0 C++ class library is not included.
This is because it is a separate product, and not part of OpenGL. OpenGL
is a low-level API.
> There is no support for the following pixel format features: stereoscopic images, alpha bitplanes, and
> auxiliary buffers.
> There is, however, support for several ancillary buffers including: stencil buffer, accumulation buffer, back
> buffer (double buffering), overlay and underlay plane buffer, and depth (z-axis) buffer.
Blame Microsoft - they could have added these to their software
implementation if they wanted to. These features, among others, are
supported by several IHVs, however.
Frans Bouma
>
> I'm trying to understand the situation here. Is it the case that:
>
> 1. MS' opengl32.lib (on NT4 and Win98?) is basically an interface to
> whatever ICD is installed with your hardware. ie. Most of the library
> functions are just stubs that call the ICD functionality ?
correct. Most OpenGL functionality has to do something with the
hardware and is done by the ICD. it changes when there is a very
lousy videocard in the system with no ICD. Then the opengl32.dll
does the rendering, but that's slow.
Dx is modelled different: there is a huge system already provided.
all the HW manufacturers have to do is provide the real basic
functions to operate with the hardware. MS is now NOT going to
do that for OpenGL. but some other company can. (I however doubt
any company will. )
> 2. Win2000 will be the same.
true
> 3. The support that was withdrawn was that MS would write these
> drivers for the ISVs ?
no, write a part of the drivers for the ISV's. so they didn't have
to write a complete ICD, which costs a lot.
> 4. The end result is that it will take longer for OGL hardware support
> to be widespread on Win2000 ?
no. All major cardvendors and chipmanufacturers have a full ICD now.
and those ICD's just have to be tweaked for every chipset they
make. so I don't think there will be any OGL hardwaresupport drawback
on win2K.
FB
Frans Bouma
> > There isn't gonna change anything at all. So what's the point?
>
> Huh?
shall I restate it?
the situation NOW will be the situation NEXT YEAR. which equals:
nothing changes.
> > the ICD's cardmanufacturers had to supply are now also created by
> > the manufacturers themselfs and not MS.
>
> ICDs always have been created by the manufacturers. Microsoft was going
> to provide a smaller driver interface (like the Win9X MCD) but killed it
> shortly before it was finished.
true, but... perhaps it wasn't worth the efford?
> > And btw: the opengl dll's for win32 aren't coming from SGI either.
>
> Who said they were?
well, MS is blamed for dropping huge driver model improvements
while the mothercompany of OpenGL isn't supporting win32 either.
> > > Despite Microsoft's efforts to kill off OpenGL, OpenGL is still well
> >
> > blablabla. no-one is gonna kill OpenGL. MS isn't that stupid.
>
> Huh? Microsoft has done everything they can think of to kill it.
what a piece of crap.
NT has, since it came out, OpenGL support. THat's done on purpose.
till today it still has opengl support as the only platform for hw rendering.
kill it? how!?
most cardvendors just go for d3d instead of opengl. 3dfx, ring a bell?
> > I think the cardmanufacturers who have to spend A LOT of money to
> > produce an ICD suffer more from the fact that OpenGL is not
> > available in a DX driver model than the customers.
>
> ICDs are harder to write, yes, but they can be a lot more efficient.
> Most vendors have decent ICDs now so it doesn't really matter.
true, however S3 is a bit of a problem ;)
and if you have already an ICD, it's not that hard to come up with a
version for a new videocard IMHO.
> > OpenGL WAS mostly a workstation API, it's now more and more coming
> > to the desktop of average joe's. But also understand most desktop
> > videocard makers design Hardware with DX in mind, not opengl.
>
> Most vendors are designing with both in mind, now.
I wonder why. Because: if you look at it and be reasonable: how many
programs do NEED opengl on win32, the market for most of the 3d cards.
not that much. It's just that some manufacturers release dx drivers
from the start with all the features and opengl drivers later. Have you
seen G400 extensionlists for the opengl driver for the g400?
> > > supported by hardware vendors such as NVidia and Diamond, and by
> >
> > diamond who?
> > diamond is just a crappy driverkiller, creator of cheap hardware,
> > and if ANY company makes a mess with drivers, it's diamond. please.
>
> Diamond has a professional OpenGL board called the FireGL1 that has the
> best Windows OpenGL drivers I've seen on a PC. And the board is *fast*
> and pretty inexpensive (less than $900). Sounds like you had a bad
> (childhood?) experience with Diamond. Diamond's professional boards a
> are *very good*.
errr, ever had NT with a diamond videocard, like a firegl ?
or a TNT based board from diamond and you wonder... why ain't my drivers
updated and why are the diamond drivers still crashing?
the FireGL1 is pretty fast, but how much faster is it than the
geforce? iirc not that faster, perhaps even slower.
that doesn't matter anyway, diamond just glues the stuff on a card.
to me nVidia has supplied the best PC drivers, together with Creative.
o and my childhood was pretty good, thank you :)
> > > libraries like Mesa, which is faster than Microsoft's implementation
> > > anyway and supports alpha channels.
>
> > errrr... mesa is faster? with what? opengl software rendering?
> > well.. good luck. :) who carez anyway.
>
> Yes, software rendering. Plenty of people care, such as anyone with a
> laptop. And software OpenGL on a PIII500 can be extremely fast for a lot
> of operations.
suuuurre. but who are you kidding? if you have an app with multiple textures
per poly or extensive opengl lighting, where is your software rendering?
it's ok in shading polies but not more than that. 'extremely fast' sounds
a bit weird.
> Good luck with what? You're not making a whole lot of sense.
good luck with the software rendering!
> > Do you really miss the alphachannels? or do you miss the alphaplanes!?
> > (a little different IMHO)
>
> Same thing, when referring to destination alpha (which I assumed people
> would understand I was referring to. Guess not.)
which is supported by the ICD. I have perfect destination alpha on my
TNT.
> > you can't create several rendercontexts with alphachannel and blend them
> > together automatically. But do you need to?
>
> Huh?
duh. never mind.
> > Printing.
> > You can print an OpenGL image directly to a printer using metafiles only. For more information, see
Printing
> > an OpenGL Image.
>
> OpenGL does not have a printer interface because it is platform and
> windowing-system agnostic.
>
> > There are no per-window hardware color palettes.
>
> Bummer. Should get an SGI workstation then.
do you need it? a screen with true color can use any color
at any window. or do you need more than true color per window?
> > There is no direct support for the Clipboard, dynamic data exchange (DDE), or OLE.
> > A window with OpenGL graphics does not directly support these Windows NT/2000 and Windows 95/98
capabilities.
>
> OpenGL is platform and windowing-system agnostic. If you want those
> features, add them yourself.
I just pasted it :)
I guess some people asked for these functions
> > The Inventor 2.0 C++ class library is not included.
>
> This is because it is a separate product, and not part of OpenGL. OpenGL
> is a low-level API.
true, but again, I just pasted the text.
> > There is no support for the following pixel format features: stereoscopic images, alpha bitplanes, and
> > auxiliary buffers.
> > There is, however, support for several ancillary buffers including: stencil buffer, accumulation buffer,
back
> > buffer (double buffering), overlay and underlay plane buffer, and depth (z-axis) buffer.
>
> Blame Microsoft - they could have added these to their software
> implementation if they wanted to. These features, among others, are
> supported by several IHVs, however.
why should I blame MS? because it's MS? I guess...
I feel you look at opengl as a religious thing or something. It's just
an api for rendering 3D stuff. If there is a better api around, use
that. Sure, opengl is nice and easy to use. But perhaps a new 3d api
is also easy to use and nice.
stereoscopic images... well...
auxiliary buffers.... even the redbook doesn't talk about them.
and personally: I really don't care about the software rendering of
an opengl implementation. opengl is an api that needs hardware, like
any 3D rendering api does. Software rendering was nice back in the
days when 3D hw was too expensive. today it's very cheap and people
don't have to look at blocky screens anymore.
just my 0.02$
FB
Martin Knoblauch
Paul Miller wrote in message <384304CD...@fxtech.com>...
>
>> > Despite Microsoft's efforts to kill off OpenGL, OpenGL is still well
>>
>> blablabla. no-one is gonna kill OpenGL. MS isn't that stupid.
>
>Huh? Microsoft has done everything they can think of to kill it.
>
me thinks both of you have a point here. For the games market M$ indeed
tried a lot to kill off OpenGL. Thanks to a few enthusiasts they they failed
miserably. For "professional" applications (CAD, DCC), they silently
accepted that there is no way to sell D3D. I just try to imagine what
happens if they would make such a proposal to the likes of Dassault or PTC
:-) As M$ is interested to sell into the usership of this kind of products
(in order to kill off Unix maybe *) they just did the smart thing.
Martin
*) Fortunatelly there are quite a few enthusiasts who will prevent that from
happening
--
------------------------------------------------------------
Martin Knoblauch
Compaq Computer EMEA BV
E-Mail: Martin.K...@Compaq.com
Std.Disclaimer: Not speaking for COMPAQ in any form on this medium
Peter Kelm
MS Direct3D):
"Do not let your personal preference for the Quake family of games
dominate your
understanding of this market. OGL is not strategic for us... as the
last three years of
history in the multimedia space have shown... SoftImage has about
20,000 seats total.
And I just about had them convinced to do a port to D3D before we sold
them. Outside
of the Quake family of games there are, maybe, two hands-full of apps
that use OGL.
Somewhere between 5-10 per cent. D3D has overwhelming support in terms
of titles,
yet we have a serious lack of drivers. D3D drivers are strategic for
us."
What the heck is he talking about? IMHO Direct3D is nothing more than
some
"strange" game API... in contrast to OpenGL.
I cannot find a reason to switch to Direct3D at all!
Concerning OpenGL support in Win2k I doubt that there will be no OpenGL
support.
Elsa for example has drivers in beta test already...
Peter
Eugene Mazur wrote:
> Look at
>
> http://www.theregister.co.uk/991129-000007.html
>
> What do you think/know about it?
---------------------------------
Peter Kelm
kel...@ina.de
INA-TB (Analysis department)
INA Waelzlager Schaeffler oHG
D-91074 Herzogenaurach
Germany
Jon Leech
Frans Bouma <per...@xs4all.nl> wrote:
>Andrew Beatty <abe...@bc.sympatico.ca> wrote in message
>news:3842f0ad....@news.bcandid.deja.com...
>>
>> 1. MS' opengl32.lib (on NT4 and Win98?) is basically an interface to
>> whatever ICD is installed with your hardware. ie. Most of the library
>> functions are just stubs that call the ICD functionality ?
>
> correct. Most OpenGL functionality has to do something with the
> hardware and is done by the ICD. it changes when there is a very
> lousy videocard in the system with no ICD. Then the opengl32.dll
> does the rendering, but that's slow.
>
> Dx is modelled different: there is a huge system already provided.
> all the HW manufacturers have to do is provide the real basic
> functions to operate with the hardware. MS is now NOT going to
> do that for OpenGL. but some other company can. (I however doubt
> any company will. )
SGI provides (redistributed to IHVs by Microsoft) the driver
development kit from which IHVs write their ICDs. The DDK is a complete
OpenGL implementation, including a software renderer and a reference
hardware driver; the purpose is to demonstrate how to write a driver as
well as to provide fallback paths for hardware that doesn't support
particular OpenGL features.
>> 2. Win2000 will be the same.
>
> true
Yes.
>> 3. The support that was withdrawn was that MS would write these
>> drivers for the ISVs ?
>
> no, write a part of the drivers for the ISV's. so they didn't have
> to write a complete ICD, which costs a lot.
This topic is being throughly beaten to death on the
OPENGL-GAMEDEV-L mailing list, including comments from people who were
referenced in the Register article. In one case someone sent in a bug
report regarding lack of Windows 2000 ICDs for a couple of older video
cards - something which is and always has been the responsibility of the
IHV, not Microsoft. Somehow, minor issues like this have grown into the
outlandish claims being made on the newsgroup. Some of the comments in
the article were clearly been taken way out of context, as well. Refer
to the mailing list for details:
http://www.geocities.com/SiliconValley/Hills/9956/OpenGL/
I'm appending a canned response that I and my manager composed
earlier today; while it can't possibly address every misunderstanding
arising out of this article, please feel free to forward it as
appropriate if this thread crops up in other forums.
Jon Leech
OpenGL ARB Representative
SGI
Canned response follows:
> The Register article has generated some confusion between Fahrenheit
> and OpenGL, which have always been distinct. OpenGL is not going away on
> Windows platforms:
>
> - While SGI is under NDA for the Windows 2000 beta and cannot comment
> on its contents, we have every expectation that OpenGL support in
> Windows 2000 will be the same as support in NT 4 or Windows 98
> today: Microsoft ships OPENGL32.DLL (the link library), and IHVs
> ship the hardware drivers (ICDs) for their chips and boards. All
> major 3D graphics IHVs are OpenGL licensees and are continuing to
> put significant effort into their Windows OpenGL drivers. NDAed beta
> testers of Windows 2000 can check for OpenGL support by enabling an
> OpenGL screensaver.
>
> - SGI continues to do engineering work on the OpenGL driver
> development kit shipped from Microsoft to IHVs, and the 1.2 DDK is
> in beta with selected IHVs. In addition to the 1.2 features, it
> includes geometry path optimizations from Intel and other
> enhancements.
>
> - OpenGL 1.2 support is planned for a service pack after Windows 2000
> ships, as we and Microsoft have both been saying for a long time.
>
> - Questions about Fahrenheit on Windows should be directed to
> Microsoft (email: fsgfb 'at' microsoft.com).
>
> - Further questions about OpenGL on Windows should be directed to
> SGI's OpenGL Product Manager, Steve McGuigan (email:
> opengl-secretary 'at' sgi.com) or to Microsoft, depending on the
> nature of the question.
>
> Ken Nicholson (OpenGL Group Manager)
> Jon Leech (OpenGL ARB representative)
> SGI
Stuart Dunn
news:384392AA...@ina.de...
> That link contains some words from Microsoft's Philip Taylor (senior in
> MS Direct3D):
>
> "Do not let your personal preference for the Quake family of games
> dominate your
> understanding of this market. OGL is not strategic for us... as the
> last three years of
> history in the multimedia space have shown... SoftImage has about
> 20,000 seats total.
> And I just about had them convinced to do a port to D3D before we sold
> them. Outside
> of the Quake family of games there are, maybe, two hands-full of apps
> that use OGL.
> Somewhere between 5-10 per cent. D3D has overwhelming support in terms
> of titles,
> yet we have a serious lack of drivers. D3D drivers are strategic for
> us."
>
> What the heck is he talking about? IMHO Direct3D is nothing more than
> some
> "strange" game API... in contrast to OpenGL.
>
a game API that hardly compares with a professional API like Opengl even if
a certain popular game uses it. Its chalk and cheese....
If you want to write a game for the windows platform and don't care less
about not being cross platform, go ahead and use D3d if you must. But for
anything else its just pants.
> I cannot find a reason to switch to Direct3D at all!
>
And why should you!
From the article it looks as if they have just not bothered to include ICDs
for the various HW drivers that ship on disk, but that won't stop you
downloading the latest driver from the HW manufacture's web site. Probably
as much to do with saving space on disk as anything else. If you think NT
2000 is going to be one hell of an install even without 20 odd meg going on
various IDC files. Also it probably tends to stear newbies in the D3D
direction which is what MS wants, but I don't think there stupid enough to
drop opengl from NT (The high end workstation product). It would almost
certainly loose them their market share in the graphics workstation market.
Something, if I remember correctly, they were actively trying to expand not
so long ago.
BTW I think NT5.0\NT2000\Windows2000\whatever_the_hell_they_are_calling_it
_now2000 is meant to have opengl 1.2 libs
Anyone want to confirm or deny?
just my two cents.
or should that be 0.01854367377 euros :) stupid bloody currency if ever
there was one....
Frans Bouma
> In article <8201n5$ig0$1...@news1.xs4all.nl>,
> Frans Bouma <per...@xs4all.nl> wrote:
> > correct. Most OpenGL functionality has to do something with the
> > hardware and is done by the ICD. it changes when there is a very
> > lousy videocard in the system with no ICD. Then the opengl32.dll
> > does the rendering, but that's slow.
> >
> > Dx is modelled different: there is a huge system already provided.
> > all the HW manufacturers have to do is provide the real basic
> > functions to operate with the hardware. MS is now NOT going to
> > do that for OpenGL. but some other company can. (I however doubt
> > any company will. )
>
> SGI provides (redistributed to IHVs by Microsoft) the driver
> development kit from which IHVs write their ICDs. The DDK is a complete
> OpenGL implementation, including a software renderer and a reference
> hardware driver; the purpose is to demonstrate how to write a driver as
> well as to provide fallback paths for hardware that doesn't support
> particular OpenGL features.
this, together with your attached statement says there is nothing
to worry at all, if there was already room for worries at all.
thanks Jon.
Frans Bouma
> That link contains some words from Microsoft's Philip Taylor (senior in
> MS Direct3D):
>
> "Do not let your personal preference for the Quake family of games
> dominate your
> understanding of this market. OGL is not strategic for us... as the
> last three years of
> history in the multimedia space have shown... SoftImage has about
> 20,000 seats total.
> And I just about had them convinced to do a port to D3D before we sold
> them. Outside
> of the Quake family of games there are, maybe, two hands-full of apps
> that use OGL.
> Somewhere between 5-10 per cent. D3D has overwhelming support in terms
> of titles,
> yet we have a serious lack of drivers. D3D drivers are strategic for
> us."
>
> What the heck is he talking about? IMHO Direct3D is nothing more than
> some "strange" game API... in contrast to OpenGL.
hhehehe.
it WAS, but it's mature now. It's just a total different approach.
It's COM based, opengl is not. it has a high level api AND a low level
api, opengl has just 1 version of the api. It's a matter of how
you want to program stuff. If you like COM a lot, opengl will look
very weird to you and vice versa. but this gets off topic. d3d vs opengl
wars are just as stupid as any other religious war. Choose the
api that fits the problem and brings the best for your situation.
> I cannot find a reason to switch to Direct3D at all!
like I said: if you have a system that is totally COM based, it's
VERY HARD to include opengl because of it's non-com nature. Within
a few months I'm facing this, so I will try to write a com wrapper
around opengl to get this done. d3d just fits in. It's not a world
where an application is written around a 3D api, but an application
poops some stuff that has to be rendered, and any api who can do that
should do that. Unreal Engine is a good example.
> Concerning OpenGL support in Win2k I doubt that there will be no OpenGL
> support. Elsa for example has drivers in beta test already...
exactly. Of course it would be way more nicer if opengl would have
the same driver model as d3d on win32, so opengl drivers were
packed with all the newest features right out of the box. Now, afaik
some (not all, nvidia does it right) chipmanufacturers don't include
all hw features as extensions in their opengl drivers.
FB
Eugene Mazur
>BTW I think NT5.0\NT2000\Windows2000\whatever_the_hell_they_are_calling_it
>_now2000 is meant to have opengl 1.2 libs
>Anyone want to confirm or deny?
>
Read John Leech responce re this.
Paul Martz
news:384392AA...@ina.de...
> That link contains some words from Microsoft's Philip Taylor (senior in
> MS Direct3D):
>
>
> What the heck is he talking about?
As I mentioned in the other thread on this subject, Microsoft simply sees no
ROI in doing any OpenGL support. They do not consider any games or
applications which use OpenGL to provide enough incremental Windows2000
sales to be worth providing any substantial OpenGL support.
It makes sense from a business perspective. Microsoft has D3D which plenty
of game developers use. They need to weigh the cost of providing a second 3D
API (a high-quality feature-rich OpenGL product) against the revenue
generated from OpenGL games and apps that will use it. They see the cost as
being too high, especially in light of the existing model, in which IHVs do
all the real work and Microsoft gets all those OpenGL games and apps on
Windows for free.
The main con of this model is that the monopoly provider of desktop
operating systems is not directly involved in the production, support, or
direction of OpenGL.
--
-Paul Martz
Hewlett Packard Workstation Systems Lab
Remove DONTSPAM to reply
Rene Tschaggelar
DirectX is for the mass game market on cheap machines, whereas OpenGL is for
professionals. Their tools are also more targeted for the hobby market.
The manufacturer of my machine kind of promised an OpenGL driver for Win2k.
Rene
--
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
Yum
>operating systems is not directly involved in the production, support, or
>direction of OpenGL.
More serious con is that the M$company is devided next year due to harmful
besiness. No one wants to be a slave to M$.
Yum
Frans Bouma
Only dumb, blind, religious people are slaves to some kind of
thing.
Normal, rational thinking people just choose what fits their needs.
if that's not available they choose the best that can fit their
needs.
FB
Rolf Magnus
> Only dumb, blind, religious people are slaves to some kind of
> thing.
>
> Normal, rational thinking people just choose what fits their needs.
> if that's not available they choose the best that can fit their
> needs.
So you think most people are dumb, blind and religious?
--
Rolf Magnus
Frans Bouma
If you consider most people as slaves, yes.
I don't however. Only some people see several objects as religious
goods that should be protected, no matter what others say.
projected to opengl: it's just an api. it;'s very nice, it's a
breese to program for, it's very well constructed, but if there
is something better on the block, why not choosing that for some
purposes? some people here in this thread think everything else
is crap per definition compared to opengl. I think that's a bit
non-rational, religious thinking :)
FB
Paul Miller
> is crap per definition compared to opengl. I think that's a bit
> non-rational, religious thinking :)
It's not 'non-rational' or religious if it's true. :-)
Frans Bouma
> > purposes? some people here in this thread think everything else
> > is crap per definition compared to opengl. I think that's a bit
> > non-rational, religious thinking :)
>
> It's not 'non-rational' or religious if it's true. :-)
hehhehehe, I have the feeling, IF we continue, this thread
will be here till doomsday ;)
FB
Paul Miller
>
> hehhehehe, I have the feeling, IF we continue, this thread
> will be here till doomsday ;)
Let's just say this is probably the wrong newsgroup to be a serious
Direct3D advocate.
Frans Bouma
> > > It's not 'non-rational' or religious if it's true. :-)
> >
> > hehhehehe, I have the feeling, IF we continue, this thread
> > will be here till doomsday ;)
>
> Let's just say this is probably the wrong newsgroup to be a serious
> Direct3D advocate.
o don't get me wrong: I'm not a d3d advocate. I'm also not an opengl
advocate. I just say that, like with Os-es or whatever, people
should look more at the facts than at personal preferences which don't
have to be the same. it has nothing to do with d3d or opengl or whatever.
but bashing opengl from a d3d point of view is as wrong as bashing d3d
from an opengl point of view ;)
concluding: advocates are wrong per definition. ;)
FB
Eugene Mazur
LET'S STAY ON FUCKING TOPIC !!!!!
Frans Bouma wrote in message <822t7b$mru$1...@news1.xs4all.nl>...
>Yum <y...@krd.edu> wrote in message news:821957$q...@cwis-20.wayne.edu...
>> >The main con of this model is that the monopoly provider of desktop
>> >operating systems is not directly involved in the production, support, or
>> >direction of OpenGL.
>>
>> More serious con is that the M$company is devided next year due to harmful
>> besiness. No one wants to be a slave to M$.
>
> Only dumb, blind, religious people are slaves to some kind of
> thing.
>
> Normal, rational thinking people just choose what fits their needs.
> if that's not available they choose the best that can fit their
> needs.
>
> FB
>
>
Frans Bouma
> I started this thread, so I guess I can politely interfere here.
>
> LET'S STAY ON FUCKING TOPIC !!!!!
what does FUCKING have to do with opengl?
;)
FB
Olivier
a new M$ monopoly with directX
forget OpenGL, learn directX and shut up...
grrrrrrrrrrrrrrr
I begin to hate M$
Eugene Mazur a écrit dans le message ...
Paul Miller
DirectX IS NOT THE SAME as Direct3D. Components of DirectX can be used
perfectly fine with OpenGL. I wonder what about this is so hard to
understand.
Karl Kazzu
was the solution to developing games on the Windows platforms. Why dump
it?!? This was an answer to a generic set of
APIs to interface to game-related hardware (multimedia).
2. We refer to DirectX in direct comparison to OpenGL but this is a mistake.
The fight is between a
PART of DirectX, Direct3D, and not the suite of APIs which make up DirectX.
3. Microsoft doesn't have to directly support OpenGL. This means Microsoft
should not have to build drivers for OpenGL-compatible graphic
boards/chipsets. Does Microsoft do this for Glide, Metal, or the other
proprietary graphic APIs out there?!?! So why is OpenGL a big issue?!?! Sun
did it because Sun
has graphic hardware. As for Sun, there are many patches and bugs to this
implementation of OpenGL.
Microsoft has a army of Third-Party-Developers that can write far better
ICDs than Microsoft alone.
Why spend the cash when game developers have PROVEN better solutions and a
company called 3Dlabs specializes on OpenGL drivers?!?!?!
4. The hardware vendors should have an OpenGL-compliant product and an ICD.
They could come together and build a generic model. They could implement
certain extensions to have that market differential and demonstrate new
features.
What were the graphic APIs used for Playstation2, Playstation, Nintendo64,
Amiga, Colecovision,
Intellivision, Dreamcast, or Vectra?!?! Were they using OpenGL?!? What abou
tthe game companies like Konami and Namco?? Is OpenGL a standard for
developing games??
Paul Miller <st...@fxtech.com> wrote in message
news:384573C4...@fxtech.com...
Michel Grenier
Hello NG.
A few weeks ago, Paul Martz answered me on a question
I put on the OpenGl new group about the
OpenGl development environment on the HP.
And Paul was right... A sysAdmin guy installed
what I needed and it worked... Thanks to you Paul!
Now I have another question...
It seems that my rendering time is incredibly
slow on my HP machine...
What is the "proper" hardware (graphic card,
library version... etc) to make the HP opengl
rendering reasonably fast...
For the moment my old PC 200 MHZ with a
matrox mystic 2Mb kills my HP...
My current HP configuration is
C180 and the graphic card is visualize 24
Thanks again
Michel G.
Paul Martz
news:evFnsXMP$GA.268@cpmsnbbsa02...
> 3. Microsoft doesn't have to directly support OpenGL. This means Microsoft
> should not have to build drivers for OpenGL-compatible graphic
> boards/chipsets. Does Microsoft do this for Glide, Metal, or the other
> proprietary graphic APIs out there?!?! So why is OpenGL a big issue?!?!
I don't think Microsoft ever released a Glide, Metal, Hoops, or Phigs
product, did they? They did release an OpenGL product at one time, which
gave us OpenGL developers and aficionados the hope that OpenGL would become
the 3D graphics API of choice on the world's most used operating system. But
now Microsoft is backing off of OpenGL support, and this is an OpenGL
newsgroup. So I think that explains why OpenGL is a big issue. OpenGL is now
faced with taking a backseat to D3D on Microsoft platforms, just like all
those other niche-market 3D APIs.
I don't think anyone here is suggesting that Microsoft should develop IHV
OpenGL drivers. Surely that is a ludicrous idea.
At issue here is that Microsoft has decided it is in its best interests to
be involved with OpenGL as little as possible. Microsoft is big -- so big,
in fact, they have been declared a monopoly. And when a monopoly corporation
has it's own 3D graphics API that it is pushing, I think that bodes poorly
for any other 3D graphics APIs. I'm not saying Microsoft is going to kill
OpenGL, certainly it will live on forever just like Phigs, Glide, OS2/Warp,
VMS, and Netscape. But it is obvious that OpenGL would be a lot healthier
with Microsoft's involvement and support.
What do I mean by "involvement and support"? Employ a full staff of
engineers dedicated to OpenGL's quality and success on Microsoft operating
systems, similar to how they have done with Direct3D. Obvious signs that
they are not doing this include: a total void of updates to their original
OpenGL software product; a cumbersome model for accessing IHV-specific
extensions; and public statements like "we want to make sure D3D is 100%
before we lift a finger for OpenGL".
Unfortunately, it is not cost-effective for Microsoft to do this. Without
this onvolvement and support, OpenGL will always be fall short of its
potential on Microsoft platforms. It will always be regarded as "that other
API" which runs well on those esoteric Unix boxes but isn't quite there 100%
on the Windows machines that everyone owns.
After rereading what I've written, I guess I should throw in a disclaimer. I
am not speaking for HP. Nor am I attempting to disrespect the good name of
Microsoft. Nor am I suggesting that Microsoft change anything it is doing. I
totally understand Microsoft's business case for its current approach to
OpenGL support, and while I feel this is unfortunate for OpenGL, if I were
Bill Gates instead of an OpenGL developer I'd probably be doing the same
thing he is.
Paul Martz
news:38468260...@ec.gc.ca...
> It seems that my rendering time is incredibly
> slow on my HP machine...
>
> What is the "proper" hardware (graphic card,
> library version... etc) to make the HP opengl
> rendering reasonably fast...
>
> For the moment my old PC 200 MHZ with a
> matrox mystic 2Mb kills my HP...
>
> My current HP configuration is
> C180 and the graphic card is visualize 24
The Visualize24 graphics card was developed before HP jumped on the OpenGL
bandwagon, and as a result OpenGL drivers were never developed for it -- it
lacks key hardware support for many OpenGL features. As a result, you are
using the Virtual Memory Driver and going 100% software path. (If you were
using Starbase, PEX, or Phigs instead of OpenGL, you would be using the
hardware, as the Vis24 has full hardware support for these APIs.)
The OpenGL graphics card family (now getting a little long in the tooth, but
not as ancient as your Vis24) is the Visualize FX2, FX4, and FX6. They do
not have texture map hardware built in, but this can be purchased as an
optional daughterboard for the FX4 and FX6 devices. My recommendation for
your C180 would be an FX4 with the TM option.
You need to be on HPUX 10.20 with the ACE5 upgrade to be on the latest
drivers.
Hope this helps,
Stuart Dunn
"Paul Martz" <ma...@DONTSPAMgplmail.fc.hp.com> wrote in message
news:8263om$ckk$1...@fcnews.fc.hp.com...
> What do I mean by "involvement and support"? Employ a full staff of
> engineers dedicated to OpenGL's quality and success on Microsoft operating
> systems, similar to how they have done with Direct3D. Obvious signs that
> they are not doing this include: a total void of updates to their original
> OpenGL software product; a cumbersome model for accessing IHV-specific
Not totally true opengl 1.2 is due out in NT2000 final release. Other than
that what updates do you want?
> extensions; and public statements like "we want to make sure D3D is 100%
> before we lift a finger for OpenGL".
>
> Unfortunately, it is not cost-effective for Microsoft to do this. Without
> this onvolvement and support, OpenGL will always be fall short of its
> potential on Microsoft platforms. It will always be regarded as "that
other
> API" which runs well on those esoteric Unix boxes but isn't quite there
100%
> on the Windows machines that everyone owns.
>
True Microsoft's software implementation is utter crap (very slow). But
professionals\games users don't use software OpenGL they you hardware
OpenGL. So most if not all of the code paths are different. So what
Microsoft do with their code is mostly irrelevant. Take Mesa its software
rendering mode is much faster than microsofts but it (this info is from a
freind of mine who dual boots his machine) runs opengl games no faster than
win95!
They are responsible for:
The software implementation (sell above)
The API (such as 1.1. v 1.2). But if you think that most of the 1.2 updates
have already been implemented as extensions to 1.1 anyway in most cases that
isn't such an issue. So even if the API version does lag behind other
platforms its effects are reduced.
The dd. for OpenGL (again minimal support needed).
If Microsoft puts little into OpenGL that will not stop vendors writing
drivers nor will it stop people writing software that needs it. All it will
mean is that when OpenGL 1.3 or whatever comes out there will be a lot of
post here saying that it will not be out until NT2000 SP13 or NT2001 etc etc
etc.
However, it will encourage smaller game companies from using it. And this
will lead to less crossplatform game development since software houses will
stick to DX7. Therefore Microsoft get to control the gaming market to an
even greater degree.
To sum up, I think OpenGL is still part of Microsoft's high end strategy but
it definitely isn't part of their gaming strategy. So OpenGL will not
disappear from MS OS's but its target market will change.
> After rereading what I've written, I guess I should throw in a disclaimer.
I
> am not speaking for HP. Nor am I attempting to disrespect the good name of
> Microsoft. Nor am I suggesting that Microsoft change anything it is doing.
I
> totally understand Microsoft's business case for its current approach to
> OpenGL support, and while I feel this is unfortunate for OpenGL, if I were
> Bill Gates instead of an OpenGL developer I'd probably be doing the same
> thing he is.
Phil McRevis
<evFnsXMP$GA.268@cpmsnbbsa02> thusly:
>What were the graphic APIs used for Playstation2, Playstation, Nintendo64,
>Amiga, Colecovision,
>Intellivision, Dreamcast, or Vectra?!?!
Dunno about the rest, but the Amiga had no native 3D API ever. I think
someone has made a Mesa port available, but it wasn't done by C= or any
of the other "owners" of the Amiga technology; its a third-party
add-on. The Amiga used its own proprietary window system API, just
like MS. It used a proprietary multimedia API, just like MS. It used
a proprietary OS, just like MS. Before Apple adopted OpenGL you could
say exactly the same thing about them: proprietary OS, proprietary
window system API, proprietary multimedia API, proprietary 3D graphics
API. The only thing that has changed with Apple is that they now
support OpenGL, but the rest of their system is just as proprietary as
MS Windows. I notice all the people who bitch about the
closed-standard nature of MS Windows don't similarly go bitching about
the closed-standard nature of Apple's MacOS. So its not really a case
of open vs. closed standards, just that you want to bitch about MS
because they are the big, obvious, barn-sized target.
If the Amiga had been actually marketed, it might have stood a chance
of taking some market share away from the IBM PC clones. However, had
it made any kind of impact on the market place so as to maintain a
significant market share, you would have all the same problems you have
with MS: proprietary, closed interfaces to system functions.
In this respect MS isn't doing anything different from any other
computer vendor in history.
--
http://www.xmission.com/~legalize Legalize Adulthood!
lega...@xmission.com
``Ain't it funny that they all fire the pistol, <URL: http://
at the wrong end of the race?''--PDBT www.eden.com/~thewho>
Phil McRevis
<8263om$ckk$1...@fcnews.fc.hp.com> thusly:
>At issue here is that Microsoft has decided it is in its best interests to
>be involved with OpenGL as little as possible. Microsoft is big -- so big,
>in fact, they have been declared a monopoly. And when a monopoly corporation
>has it's own 3D graphics API that it is pushing, I think that bodes poorly
>for any other 3D graphics APIs.
About 10 years ago, you could have made the same case for SGI being
the "100 lb. gorilla" in the graphics workstation market, making it
difficult for anyone else to create competing products that would be
successful in the marketplace because of the dominance of the
proprietary iris gl API.
David Blythe
>"Paul Martz" <ma...@DONTSPAMgplmail.fc.hp.com> spake the secret code
><8263om$ckk$1...@fcnews.fc.hp.com> thusly:
>
>>At issue here is that Microsoft has decided it is in its best interests to
>>be involved with OpenGL as little as possible. Microsoft is big -- so big,
>>in fact, they have been declared a monopoly. And when a monopoly corporation
>>has it's own 3D graphics API that it is pushing, I think that bodes poorly
>>for any other 3D graphics APIs.
>
>About 10 years ago, you could have made the same case for SGI being
>the "100 lb. gorilla" in the graphics workstation market, making it
>difficult for anyone else to create competing products that would be
>successful in the marketplace because of the dominance of the
>proprietary iris gl API.
Except that SGI licensed the IRIS GL API to other vendors for use
on their platforms (IBM, for example), and later proposed OpenGL
as an open standard with the thinking that a good open standard
would allow a broader set of portable applications to become
available. A similar idea is now occuring with the Linux Base
standardization efforts. In the short term concentrate on
minimizing the work for ISVs rather than introducing fragmentation
through needless differentiation. I don't think SGI was ever
really the 100lb gorilla from an application or market share
point of view (just my opinion).
-db
Michel Grenier
Thanks to Mike Phelps,
You cleared up all my questions and gave me hope!
I will send all your tips and recommandation
to the responsible of all the purchase done here...
He or I might get back to you if it is accepted
Again thanks!
Bye
Michel G.
Mike Heck
> Michel Grenier <afs...@ec.gc.ca> wrote in message
> news:38468260...@ec.gc.ca...
> > It seems that my rendering time is incredibly
> > slow on my HP machine...
> >
> > What is the "proper" hardware (graphic card,
> > library version... etc) to make the HP opengl
> > rendering reasonably fast...
> >
> > For the moment my old PC 200 MHZ with a
> > matrox mystic 2Mb kills my HP...
> >
> > My current HP configuration is
> > C180 and the graphic card is visualize 24
>
> The Visualize24 graphics card was developed before HP jumped on the OpenGL
> bandwagon, and as a result OpenGL drivers were never developed for it -- it
> lacks key hardware support for many OpenGL features. As a result, you are
> using the Virtual Memory Driver and going 100% software path.
FYI, TGS still sells an OpenGL for this older hardware
that translates the OpenGL calls into Starbase calls
in order to get hardware acceleration. The FX cards
are better all around, no question, but if you're stuck
with old hardware there is an option...
-Mike
TGS Inc, http://www.tgs.com
Phil McRevis
<827hi0$7u...@fido.engr.sgi.com> thusly:
>I don't think SGI was ever
>really the 100lb gorilla from an application or market share
>point of view (just my opinion).
Do we have say a DataQuest report for 1989 showing the graphics
workstation sales? I'm talking stuff with 3D accelerators, not 8-bit
or 24-bit displays with software implementations. I don't have any
hard data available myself but my recollection is that SGI had a
dominant position in this market.
Paul Martz
> Paul Martz wrote:
=> FYI, TGS still sells an OpenGL for this older hardware
> that translates the OpenGL calls into Starbase calls
> in order to get hardware acceleration. The FX cards
> are better all around, no question, but if you're stuck
> with old hardware there is an option...
>
> -Mike
> TGS Inc, http://www.tgs.com
Thanks, Mike. I knew that was the case a few years ago, but haven't been
keeping up enough to know that TGS still supported this product.