Originally posted by V-man:
The thing to do is bring together all these technologies together : GL, AL, IL, (something for 3D models?), ML and perhaps ES
Creative has dropped the ball on OpenAL. Maybe nVidia will push it forward with their onboard audio solutions.
DevIL is quite good.
3D models are a mess since CAD and modelling companies want to keep their formats proprietary.
Can’t speak about ML or ES, don’t have any experience.
Originally posted by V-man:
[b]As for the meeting notes, it sounds like affirmative action is taking place.
The thing to do is bring together all these technologies together : GL, AL, IL, (something for 3D models?), ML and perhaps ES
To this date, when people think of GL strengths, they list cross platform.
If there was a full package like DX, but cross platform, I think the BIG developing houses would seriously consider a switch.
It’s good that the ARB recognized this.[/b]
I have the sad feeling, that you are interpreting too much into their statements.
@Adrian: Thanks for proving me wrong 
Jan.
Originally posted by V-man:
The thing to do is bring together all these technologies together : GL, AL, IL, (something for 3D models?), ML and perhaps ES
But why? They’re nothing more than a set of API’s. And if they’re all modelled on the GL model then there’s little difference between DX and *L - it’s just that with Dx there’s a single install and with *L there’s multiple. Plus with *L there’s the choice of not installing the components that you don’t need…
[This message has been edited by rgpc (edited 01-15-2004).]
Originally posted by rgpc:
But why? They’re nothing more than a set of API’s. And if they’re all modelled on the GL model then there’s little difference between DX and *L - it’s just that with Dx there’s a single install and with *L there’s multiple. Plus with *L there’s the choice of not installing the components that you don’t need…
Developers who use DX probably know GL, but do they know the rest? Probably not.
Have you noticed how DX based games tend to use D3D, DSound, DInput, DPlay?
I’m sure there are plenty of cases that also make use of other libraries instead but in general D3D and DSound are always used it seems.
MS’s strategy has worked.
On the developer side of things, I think things are improving. Float buffer is candidate to become core but I think they will settle for an extension instead.
ARB_vp + ARB_fp wont get in the core for sure.
ARB_fragment_program_shadow?
I guess they mean something like this
TXP reg0, coord, texture[0], SHADOW;
It’s true that all the extension mess + the lack of standard libraries is really awkward.
I mean, for my latest projet I had to use my own extension loader lib, my own image lib, my own math lib, etc…
There are already a lot of libs around the net that do those things, but none of them is fully complete or completly standard.
Finally we end up using a part of them, and for the rest we all reinvent the wheel each time.
IMHO the ARB should work more closely with the whole OpenGL community (and not just ISV) to get feeback, and eventually start dedicated committees/projets.
I think that the C++ Standards Committee (http://anubis.dkuug.dk/jtc1/sc22/wg21/) has nice ideas about the ways of handling the language evolution. For example ANYONE can make proposal about future features and extensions to the language and/or the library.
That way current 3rd party libs, developers, and even amateurs, can discuss and propose ideas (even working and already implented ideas).
The good thing is that the result is generally a merge of all the good ideas and influence, and not just the promoting of one big library. So at the end the final result is more complete and generally suits everyone better.
IMHO the ARB should push the creation of a standard library (or multiple standard libraries) that way.
Personnaly I would be delighted to help them, and I think most of of the people on this forum would be too, wouldn’t you?
EDIT: About ARB_query_extension, I think it has nothing to do there. It’s a library problem, not an API problem.
[This message has been edited by GPSnoopy (edited 01-16-2004).]
Extension loading and the outdated 1.1 windows DLL really is a solved problem. Extension loading libraries (like GLee for example), give you seamless support for OpenGL 1.5 and all available extensions. An extension such as ARB_query_extension doesn’t really solve the problem directly.
It’s a shame this stuff isn’t available as standard, but a number of free libraries are available under unrestrictive licenses which do the job perfectly well.
Direct3D has better render target support than OpenGL, but worse Z buffer readback support. It also has a single, uniformly supported high-level shading language.
Originally posted by Zak McKrakem:
they have HLSL and we begin to have it now with the first ATI driver exposing it released this month (they have it from the end of 2002)
Not quite true. 3Dlabs has been shipping drivers with support for (an earlier version of) GLSL since early 2002. 3Dlabs has shipped drivers with support for the official ARB approved OpenGL Shading Language right after the ARB approved these extensions in July 2003.
Now, I can’t help it that most of you don’t have 3Dlabs graphics cards 
Also, they should note that in the D3D mailing list, there are always answers from IHV people and MS and sometimes about things of future driver features, when they are planned to be available and things like this. Here you can ask about when will be GLSL in NVIDIA drivers or about the state of the highly-anticipated superbuffers extension and you will have no answer. This causes a big frustration in developers.
Employees of IHVs read these forums, and do answer questions when it makes sense. I don’t think you’ll ever find such an employee to make a statement about future availability of hardware or drivers etc. It is too competitive of a market to do that. I would like to know too when NVIDIA is going to support The OpenGL Shanding Language
Barthold
3Dlabs