Stephen J Baker wrote:
> On Fri, 10 Sep 1999, Thomas Roell wrote:
>
> ? Looks almost perfect to me. Two minor isses:
> ?
> ? 1. What does GetProcAddressEXT return for core API functions if they
> ? are not supported by the library implementation ? Assuming there
> ? is a OpenGL 1.1 based libGL and you query a 1.2 function. Does a
> ? non-NULL value imply that the function would work ?
>
> No - just as you shouldn't query for an extension unless it's
> enumerated in glGetString(GL_EXTENSION), you shouldn't query for
> an OpenGL 1.2 function is glGetString(GL_VERSION) says 1.1 or 1.0.
>
> If you *do* make the query, it's undefined whether you'll get a
> NULL return or not - and if you do get a function address in return,
> you'd better not call it!
Oh please don't do this! This needs to be nailed down. Either we get NULL or
the function pointer is callable and useable. I agree that is stupid to
query for functions you know are not there but I think we should always
strive to not have undefined behaviors if it is possible to avoid. An an
ISV, we have been burnt too many times by "undefined" behaviors which, in
the cases I can remember, were holes in the Ogl spec.
>
>
> No different from the rule on extensions that we established yesterday.
>
> ? I would vote for no. Consider the GLX remote case, where you could
> ? have a 1.2 libGL, while the remote X-Server has only a 1.1
> ? implementation. In that case GetProcAddressEXT would return a
> ? non-NULL value. Hence it should be mandatory to use
> ? GetString(VERSION).
>
> Yes.
>
> ? 2. Having a bound context, while retrieving the function pointers is
> ? kind of difficult to handle for applications. There are
> ? applications which create first all the contexts they need, before
> ? actually making them current. Hence it would be easier to really
> ? pass a GLXContext explicitely.
> ?
> ? The downside would be that then GetProcAddress really had to be
> ? called glXGetProcAddress. The upside is, that glProcAddress could
> ? be implemented trivially by:
> ?
> ? glXGetProcAddressEXT(glXGetCurrentContext(), name)
> ?
> ? Hence I would suggest to have 2 functions defined right away in
> ? this extension:
> ?
> ?
> ? glGetProcAddressEXT(name)
> ? glXGetProcAddressEXT(ctxt, name)
> ?
> ? The first one would return only GL API functions along with
> ? extension functions, while the glX variant would also return all
> ? glX functions.
>
> OK - but you still have to call the gl version from the context in
> which you'll call the function that it returns. (That would certainly
> HAVE to be the case for EXT functions - so we might as well make
> it the rule for all functions - if only to simplify the manual!)
>
> Steve Baker (817)619-2657 (Vox/Vox-Mail)
> Raytheon Systems Inc. (817)619-2466 (Fax)
> Work: [EMAIL PROTECTED] http://www.hti.com
> Home: [EMAIL PROTECTED] http://web2.airmail.net/sjbaker1
--
Richard Pimentel
Manager of Graphics and Integration
Industrial Design Products
Parametric Technology Corp.
540 Arapeen Drive, Suite 100
Salt Lake City, UT 84108
(801) 588-4668
