Re: [oglbase-discuss] Vote results: 1 YES, 2 A
Three topics follow, and hopefully resolution of the A/B/C vote. First, since we're approaching completion of the debate over the exact shape of glext.h, I've started generating a copy automatically from the extension registry. It's at http://oss.sgi.com/projects/ogl-sample/ABI/glext.h This includes some recently ARB-approved extensions from December (specs are also in the registry), and will include the new batch of extensions from the March meeting as soon as I finish updating the registry proper. I intend for this to be the canonical version of glext.h that goes with the ABI and the registry. Please test it out, let me know of problems, and start shipping it in your implementations if you're so inclined. I've done some cursory sanity testing of glext.h on the couple of platforms I have access to, but not enough to feel confident of its utility against a wide variety of implementations, yet. The http://oss.sgi.com/projects/ogl-sample/ABI/index.html page has been updated to link to glext.h from the appropriate section. Second, there's an issue we missed regarding GLX/WGL extensions and glext.h (thanks, Paula!). The spec does not pin down where prototypes for non-GL extensions should be. There is some existing practice on Windows along the lines of a separate wglvendor.h, and it also seems to make sense both in that it's difficult to declare GLX extensions without first #including GL/glx.h (which a lot of code may not wish to do), and that it's pretty nonsensical to be dumping WGL/GLX/AGL/etc. extensions. into the same glext.h, even if they are protected by #ifdefs. So I propose that we expand the spec to mandate a separate glxext.h, treated analogously to glext.h except that it's dependent on glx.h, and that defacto Windows vendors agree on a wglext.h. If at some point in the future a gluext.h becomes desirable, it can be added to a future spec revision. Third and finally, the A/B/C vote resolution. Michael requested that we re-vote specifying a desired ordering and applying 2/1/0 voting weights according to that ordering. Response died down quickly; although not everyone who initially voted responded, I think it's reasonable to bring this to a close. The preferred orderings expressed were: A B C Allen Akin 1 0 2 Brian Paul 2 0 1 Stuart Anderson 2 ? ? (didn't specify preference among B/C) Leath Muller0 1 2 Jon Leech 2 1 0 Steve Baker 2 1 0 Thomas Roell1 2 0 Michael Gold0 1 2 - 10 6+1?7+1? It appears to me that, following Michael's procedure, (A) ekes out a narrow win. In case someone has a dispute with this summary, excerpts from the email on which I based it are attached. Can we move on now? Jon Leech SGI Votes/responses follow: - From: Michael Gold [EMAIL PROTECTED] Subject: RE: [oglbase-discuss] Vote results: 1 YES, 2 A Date: Tue, 4 Apr 2000 03:02:04 -0700 ... My order of preference is c, b, a. - From: [EMAIL PROTECTED] Date: Tue, 4 Apr 2000 09:57:44 -0700 Subject: Re: [oglbase-discuss] Vote results: 1 YES, 2 A ... So my preference order was 2C, 2A, 2B. - Date: Tue, 04 Apr 2000 11:03:32 -0600 From: Brian Paul [EMAIL PROTECTED] Subject: Re: [oglbase-discuss] Vote results: 1 YES, 2 A ... My voting order is A, C, B. - Date: Tue, 4 Apr 2000 15:11:47 -0400 (EDT) From: Stuart Anderson [EMAIL PROTECTED] Subject: RE: [oglbase-discuss] Vote results: 1 YES, 2 A ... I think there are some things that we can put in place to help minimize code like this (no offense 8-)). I don't think that we can figure it out in just a couple of days, which is why I voted for A. Let's get what we have out there, and start getting some practical experience. ... - Date: Thu, 06 Apr 2000 00:10:42 +1000 From: Leath Muller [EMAIL PROTECTED] Subject: Re: [oglbase-discuss] Vote results: 1 YES, 2 A ... This is definitely the preferable way for me to go. I know there is a lot of concern about legacy applications and their compatibility, but quite simply, I would rather get things 'right'. (i.e.: vote C, B then A) - Date: Wed, 5 Apr 2000 11:39:36 -0700 From: Jon Leech ljp Subject: Re: [oglbase-discuss] Vote results: 1 YES, 2 A ... My voting order is A, B, C. - Date: Wed, 5 Apr 2000 13:42:07 -0500 (CDT) From: "Stephen J Baker" [EMAIL PROTECTED] Subject: Re: [oglbase-discuss] Vote results: 1 YES, 2 A ... My voting order is also A, B, C - but I protest the need to re-vote. - Date: Wed, 5 Apr 2000 12:46:17 -0600 (MDT) From: Thomas Ro
RE: [oglbase-discuss] Vote results: 1 YES, 2 A
Jon, My order of preference is C, B , A. - Mark
Re: [oglbase-discuss] Vote results: 1 YES, 2 A
In your message of 10 April 2000 you write: Three topics follow, and hopefully resolution of the A/B/C vote. First, since we're approaching completion of the debate over the exact shape of glext.h, I've started generating a copy automatically from the extension registry. It's at http://oss.sgi.com/projects/ogl-sample/ABI/glext.h Two things that should be changed: 1. The defines (types/tokens) should be per extensions, and guarded properly, so that they are only defined, if the extension has not been defined yet in gl.h. I know that in theory there should never be conflicts, but it would be just nicer to deal with. 2. Explicite function prototypes should go away. Either you use wglGetProcAddress() or glXGetProcAddressARB() to retieve the extension functions. Hence there are no external declarations needed. In fact it better if the compile can issue a warning about an undeclared function if a direct reference is encountered. - Thomas -- Thomas Roell /\ An imperfect plan executed violently Xi Graphics / \/\ _ is far superior to a perfect plan. [EMAIL PROTECTED] / / \ \ / Oelch! \ \ George Patton
Re: [oglbase-discuss] Vote results: 1 YES, 2 A
Thomas Roell wrote: In your message of 10 April 2000 you write: Three topics follow, and hopefully resolution of the A/B/C vote. First, since we're approaching completion of the debate over the exact shape of glext.h, I've started generating a copy automatically from the extension registry. It's at http://oss.sgi.com/projects/ogl-sample/ABI/glext.h Two things that should be changed: 1. The defines (types/tokens) should be per extensions, and guarded properly, so that they are only defined, if the extension has not been defined yet in gl.h. I know that in theory there should never be conflicts, but it would be just nicer to deal with. Yes. I had several compiler warnings because of this. 2. Explicite function prototypes should go away. Either you use wglGetProcAddress() or glXGetProcAddressARB() to retieve the extension functions. Hence there are no external declarations needed. In fact it better if the compile can issue a warning about an undeclared function if a direct reference is encountered. If developers could be trusted to do the right thing, I'd say keep the regular extern prototypes. In the case of Mesa, my compiler flags trigger "no previous prototype" warnings for non-static functions that haven't had a previous extern declaration. I found a few other problems: 3. glCullParameterfvEXT() and glCullParameterdvEXT() are missing 'const' keywords on their second arguments. I've noted before that a lot of extension specifications omit const keywords in the prototypes in the "New Procedures and Functions" section. 4. There are two sections surrounded by #ifndef GL_EXT_subtexture / #endif. The first section has the glTexSubImage3DEXT() function and the second has the glTexSubImage1DEXT() and glTexSubImage2DEXT() functions. The prototypes and function pointers for the 1D and 2D functions are thus skipped. 5. The tokens for GL_SGIS_pixel_texture are missing. I've mentioned on the OpenGL ARB list that the values for these tokens are unknown. -Brian
Re: [oglbase-discuss] Vote results: 1 YES, 2 A
On Mon, Apr 10, 2000 at 07:57:49AM -0600, Thomas Roell wrote: 1. The defines (types/tokens) should be per extensions, and guarded properly, so that they are only defined, if the extension has not been defined yet in gl.h. I know that in theory there should never be conflicts, but it would be just nicer to deal with. Some extensions share enumerants; currently the generator script does one pass over all the enums defined in the spec file and comments out redefinitions. Are there still compilers around that complain about benign redefinitions? 2. Explicite function prototypes should go away. If we were using this solely for Linux, I would agree. However, it's intended to be used on other platforms not supporting the query mechanism. Jon Leech SGI
Re: [oglbase-discuss] Vote results: 1 YES, 2 A
In your message of 10 April 2000 you write: On Mon, Apr 10, 2000 at 07:57:49AM -0600, Thomas Roell wrote: 1. The defines (types/tokens) should be per extensions, and guarded properly, so that they are only defined, if the extension has not been defined yet in gl.h. I know that in theory there should never be conflicts, but it would be just nicer to deal with. Some extensions share enumerants; currently the generator script does one pass over all the enums defined in the spec file and comments out redefinitions. Are there still compilers around that complain about benign redefinitions? Yes. 2. Explicite function prototypes should go away. If we were using this solely for Linux, I would agree. However, it's intended to be used on other platforms not supporting the query mechanism. Good point. Ok, let's think it throu. There are three cases: 1. MS-Windows. There is always a wglGetProcAddress. 2. Linux. There is always a glXGetProcAddressARB. 3. Everbody else (UNIX ...). They have either not glXGetProcAddressARB, in which case all the extensions supported by the relevant libGL are defined properly in gl.h, or they have glXGetProcAddressARB, in which case they don't need prototypes. - Thomas -- Thomas Roell /\ An imperfect plan executed violently Xi Graphics / \/\ _ is far superior to a perfect plan. [EMAIL PROTECTED] / / \ \ / Oelch! \ \ George Patton
Re: [oglbase-discuss] Vote results: 1 YES, 2 A
On Mon, 10 Apr 2000, Thomas Roell wrote: http://oss.sgi.com/projects/ogl-sample/ABI/glext.h Two things that should be changed: 1. The defines (types/tokens) should be per extensions, and guarded properly, so that they are only defined, if the extension has not been defined yet in gl.h. I know that in theory there should never be conflicts, but it would be just nicer to deal with. I believe our standards document states that explicitly. 2. Explicite function prototypes should go away. Either you use wglGetProcAddress() or glXGetProcAddressARB() to retieve the extension functions. Hence there are no external declarations needed. In fact it better if the compile can issue a warning about an undeclared function if a direct reference is encountered. To be clear about this - they should not be in glext.h - but they can still be in gl.h since that's implementation-specific. Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation Training (817)619-2466 (Fax) Work: [EMAIL PROTECTED]http://www.hti.com Home: [EMAIL PROTECTED] http://web2.airmail.net/sjbaker1
RE: [oglbase-discuss] Vote results: 1 YES, 2 A
From: Stephen J Baker [mailto:[EMAIL PROTECTED]] Sent: Monday, April 10, 2000 12:52 PM 2. Explicite function prototypes should go away. Either you use wglGetProcAddress() or glXGetProcAddressARB() to retieve the extension functions. Hence there are no external declarations needed. In fact it better if the compile can issue a warning about an undeclared function if a direct reference is encountered. To be clear about this - they should not be in glext.h - but they can still be in gl.h since that's implementation-specific. Yes, absolutely.
RE: [oglbase-discuss] Vote results: 1 YES, 2 A
On Mon, 10 Apr 2000, Michael Gold wrote: One caveat: If gl.h defines the extension, it will not be redefined in glext.h. This is bad because the prototype function pointer typedef will therefore not be defined. Yuk! Good point. The cleanest solution IMO is that gl.h should not define any extensions when glext.h is in use. ...Or the prototype function pointer could be left outside of the guardian ifdef in glext.h since gl.h won't define function *pointers* only the functions themselves. Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation Training (817)619-2466 (Fax) Work: [EMAIL PROTECTED]http://www.hti.com Home: [EMAIL PROTECTED] http://web2.airmail.net/sjbaker1
RE: [oglbase-discuss] Vote results: 1 YES, 2 A
In your message of 10 April 2000 you write: The cleanest solution IMO is that gl.h should not define any extensions when glext.h is in use. ...Or the prototype function pointer could be left outside of the guardian ifdef in glext.h since gl.h won't define function *pointers* only the functions themselves. This would cause a problem with gl.h implementations that include function pointers for extensions supported directly in libGL ... - Thomas -- Thomas Roell /\ An imperfect plan executed violently Xi Graphics / \/\ _ is far superior to a perfect plan. [EMAIL PROTECTED] / / \ \ / Oelch! \ \ George Patton
RE: [oglbase-discuss] Vote results: 1 YES, 2 A
In your message of 10 April 2000 you write: On Mon, 10 Apr 2000, Thomas Roell wrote: In your message of 10 April 2000 you write: The cleanest solution IMO is that gl.h should not define any extensions when glext.h is in use. ...Or the prototype function pointer could be left outside of the guardian ifdef in glext.h since gl.h won't define function *pointers* only the functions themselves. This would cause a problem with gl.h implementations that include function pointers for extensions supported directly in libGL ... Does anyone actually do that (other than under Windoze that is) ? Yep. We (Xi Graphics) do so. Why ? We started shipping a preliminary gl.h/glext.h about half a year ago. Of course with no compile-time define that would indicate that glext.h would be included or not. Now for compatibility reasons a few extensions are declared the old style. An example would be EXT_texture_object. Some applications ported from other UNIX platforms really do use those things. Now glext.h must include gl.h to get all the type defines. So some extensions end up in gl.h and some in glext.h. Hence in order to avoid redefinitions or redeclarations, you have to include at least the function pointers in gl.h for the extensions that are defined there. Of course, the real clean way around all of that is to conditionally include glext.h from gl.h, because then there is a way for gl.h to figure out what to declare in what way. - Thomas -- Thomas Roell /\ An imperfect plan executed violently Xi Graphics / \/\ _ is far superior to a perfect plan. [EMAIL PROTECTED] / / \ \ / Oelch! \ \ George Patton
RE: [oglbase-discuss] Vote results: 1 YES, 2 A
On Mon, 10 Apr 2000, Thomas Roell wrote: ...Or the prototype function pointer could be left outside of the guardian ifdef in glext.h since gl.h won't define function *pointers* only the functions themselves. This would cause a problem with gl.h implementations that include function pointers for extensions supported directly in libGL ... Does anyone actually do that (other than under Windoze that is) ? Yep. We (Xi Graphics) do so. Why ? We started shipping a preliminary gl.h/glext.h about half a year ago. Of course with no compile-time define that would indicate that glext.h would be included or not. Now for compatibility reasons a few extensions are declared the old style. An example would be EXT_texture_object. Some applications ported from other UNIX platforms really do use those things. Now glext.h must include gl.h to get all the type defines. So some extensions end up in gl.h and some in glext.h. Hence in order to avoid redefinitions or redeclarations, you have to include at least the function pointers in gl.h for the extensions that are defined there. Are you confused about function *POINTERS* versus function *DEFINITIONS* ? I realise that existing gl.h's will include function definitions eg void glTexImage3DEXT ( ...whatever... ) ; ...but I don't see why you found the need to include function pointers: typedef void PFNGLTEXIMAGE3DEXT ( ...whatever... ) ; ...which were useless prior to GetProcAddress - and are the only thing that are at issue here. Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation Training (817)619-2466 (Fax) Work: [EMAIL PROTECTED]http://www.hti.com Home: [EMAIL PROTECTED] http://web2.airmail.net/sjbaker1
RE: [oglbase-discuss] Vote results: 1 YES, 2 A
In your message of 10 April 2000 you write: On Mon, 10 Apr 2000, Thomas Roell wrote: ...Or the prototype function pointer could be left outside of the guardian ifdef in glext.h since gl.h won't define function *pointers* only the functions themselves. This would cause a problem with gl.h implementations that include function pointers for extensions supported directly in libGL ... Does anyone actually do that (other than under Windoze that is) ? Yep. We (Xi Graphics) do so. Why ? We started shipping a preliminary gl.h/glext.h about half a year ago. Of course with no compile-time define that would indicate that glext.h would be included or not. Now for compatibility reasons a few extensions are declared the old style. An example would be EXT_texture_object. Some applications ported from other UNIX platforms really do use those things. Now glext.h must include gl.h to get all the type defines. So some extensions end up in gl.h and some in glext.h. Hence in order to avoid redefinitions or redeclarations, you have to include at least the function pointers in gl.h for the extensions that are defined there. Are you confused about function *POINTERS* versus function *DEFINITIONS* ? No, not at all. I realise that existing gl.h's will include function definitions eg void glTexImage3DEXT ( ...whatever... ) ; ...but I don't see why you found the need to include function pointers: typedef void PFNGLTEXIMAGE3DEXT ( ...whatever... ) ; ...which were useless prior to GetProcAddress - and are the only thing that are at issue here. Quite simple. As I said before, gl.h must be included somehow before glext.h is included (or glext.h includes gl.h). This means that some extensions will be defined in gl.h, and some in glext.h. If now extensions in glext.h are guared properly against redefines and redeclarations (ala #ifndef GL_EXT_XYZ), then you are missing the function pointers for the extensions already declared in gl.h. Somebody who includes glext.h clearly wants to have access to ALL function pointers for all extensions. So not declaring the function pointers for the extensions defined in gl.h would result in a mess. - Thomas -- Thomas Roell /\ An imperfect plan executed violently Xi Graphics / \/\ _ is far superior to a perfect plan. [EMAIL PROTECTED] / / \ \ / Oelch! \ \ George Patton
Re: [oglbase-discuss] Vote results: 1 YES, 2 A
I don't see how it's less arbitrary for Michael to invoke an Australian ballot, or whatever this method is, than any other method we ^^ could use to break a tie, but what the heck. HEY!!! Watchit buddy!!! :) Leathal.
Re: [oglbase-discuss] Vote results: 1 YES, 2 A
My order of preference is c, b, a. Here's the results of the sample poll (obviously I will wait for people to state their actual preferences and not rely on my opinions): A B C Michael 0 1 2 Steve 2 1 0 Thomas 1 2 0 Leath 0 1 2 Totals 3 5 4 Winner: B This is definitely the preferable way for me to go. I know there is a lot of concern about legacy applications and their compatibility, but quite simply, I would rather get things 'right'. (i.e.: vote C, B then A) Being primarily a windows developer moving slowly into Linux, I have to say that I don't think that the support of legacy applications is really that important (uh oh -- better jump into a pool full of flame retardant liquid!!! :) I know that sounds harsh and possibly detrimental in some areas, but from what I can see from current Linux applications, you can very easily fix them -- lets face it, you have to be a programmer at heart to develop on Linux at all -- fixing older problems won't be hard, and a few years down the track when Linux become the major development platform for most companies (I can hope... :) they will be much happier with a solid solution... and yes, I know that isn't the most solid ground for my decision, but it's definitely what I am comfortable with. 'C' works best for me as I won't have to change anything with all my current development projects such as the tools, main engine, and research code... 'B' and 'A' are almost identical from my point of view, and to be perfectly honest I just prefer 'B' because it appears that it can work exactly the same way as 'A' anyway... is this right? With 'B' it appears that I can do a #define GL_OGLBASE_EXTENSIONS and have the glext.h included, or include it myself in the application exactly the same way 'A' works (seemingly making 'A' moot). If you want a second vote, mine is as above. Leathal.
Re: [oglbase-discuss] Vote results: 1 YES, 2 A
I don't see how it's less arbitrary for Michael to invoke an Australian ballot, or whatever this method is, than any other method we could use to break a tie, but what the heck. My voting order is A, B, C. Jon Leech SGI
Re: [oglbase-discuss] Vote results: 1 YES, 2 A
On Wed, 5 Apr 2000, Jon Leech wrote: I don't see how it's less arbitrary for Michael to invoke an Australian ballot, or whatever this method is, than any other method we could use to break a tie, but what the heck. Yes. I'd like to start another ballot in which votes for 'A' count as 2 points, votes for 'B' count as 1 and votes for 'C' count as 0. :-) My voting order is also A, B, C - but I protest the need to re-vote. The previous vote was to overturn the status quo after the end of the public comment period. It didn't get a clear majority - so it didn't pass and (A) remains. No tie breaker needed. Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation Training (817)619-2466 (Fax) Work: [EMAIL PROTECTED]http://www.hti.com Home: [EMAIL PROTECTED] http://web2.airmail.net/sjbaker1
RE: [oglbase-discuss] Vote results: 1 YES, 2 A
On Tue, 4 Apr 2000, Michael Gold wrote: If I were tasked with interpreting the results, I would note that at least one person who voted for (a) preferred (b). So (c) wins, 6-5-1. Yes - but that person voted (a) *specifically* to avoid (c) - so to use that tactical vote as a way to get (c) would be WRONG. Look, it's a tied decision - someone had to decide - they did - let's move on. I actually think (b) is the best compromise, and I don't think anyone on either side of the fence would strongly object to it. But *nobody* voted for it. How about if the 12 people who voted, and nobody else, re-vote with an order of preference? I would hate to overlook a good compromise just because people were too polarized on this issue. If you vote on this first tally, please respond ASAP with your ranking. I disagree with re-voting - let's get this thing done and over with. (Yes, I know it came out the way I wanted - but you'll just have to take my word for it that I would have given up if it had come out the other way). Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation Training (817)619-2466 (Fax) Work: [EMAIL PROTECTED]http://www.hti.com Home: [EMAIL PROTECTED] http://web2.airmail.net/sjbaker1
Re: [oglbase-discuss] Vote results: 1 YES, 2 A
In your message of 3 April 2000 you write: Vote summary: Vote 1 Vote 2 Who YES NO A B C Jon Leech x x Stuart Anderson x x Mark Kilgardx x Michael Goldx x Brian Paul x x Allen Akin x x Steve Baker x x Ron Bielaskix x David Blythex x Brett Johnson x x Leath Mullerx x Thomas Roellx x --- --- --- --- 12 0 6 0 6 Foo. We're tied for choices (2A) and (2C). This must be resolved. After contemplating the merits of another month of debate, I choose to resolve it pragmatically: by noting that all of the people voting who are actually involved with a shipping Linux OpenGL or Mesa implementation today, voted the same way - in favor of (A). That suffices to break the tie in favor of (A). I think that is not suffient to break the tie. But there is another intresting observation. A lot of people voted 2A for tactical reasons, but would really loved to have voted for 2B. I would now be intrested why the 2C voters think that having a -DGL_INCLUDE_NO_EXTENSIONS type define is preferrable over a -DGL_INCLUDE_EXTENSIONS type define. Looking throu all the discussions I only found two type of comments, that it really makes sence to include glext.h automatically, and that a define is needed for for somehow enabling/disabling the inclusion. There were also comments regarding breaking source compatibility by uncoditionally including glext.h (or including it by default). As within a normal jury, I would like to hear more arguments that it makes sence to go via 2C. - Thomas -- Thomas Roell /\ An imperfect plan executed violently Xi Graphics / \/\ _ is far superior to a perfect plan. [EMAIL PROTECTED] / / \ \ / Oelch! \ \ George Patton
Re: [oglbase-discuss] Vote results: 1 YES, 2 A
On Tue, Apr 04, 2000 at 09:51:52AM -0600, Thomas Roell wrote: | ... I would now be intrested | why the 2C voters think that having a -DGL_INCLUDE_NO_EXTENSIONS type | define is preferrable over a -DGL_INCLUDE_EXTENSIONS type | define. ... I asked "What changes do I have to make to my build environment and to my source code in order to get the extensions support I need, in each of the three cases?" 2C required the minimum effort for the maximum compatibility (for the situations that I believed were important). 2A and 2B required roughly equivalent changes -- I would have to determine whether I'm building in an oglbase environment, define a symbol accordingly, and modify the source code to conditionally include glext.h. Given that the effort is about the same, I'd slightly prefer 2A, since it's more compatible with the way things are done currently under Windows. So my preference order was 2C, 2A, 2B. Allen
Re: [oglbase-discuss] Vote results: 1 YES, 2 A
Michael Gold wrote: ...snip... This thing doesn't need to go on for another month as Jon fears, but I personally don't mind a couple more days to reach a compromise solution, or at least a less arbitrary tie-breaker. As one of the 143 who did not vote, I would like to emphasis that respect and open-mindedness will make the decision more palatable. There are different needs and sometimes a good decision is to agree-to-disagree. The goal is to move forward ;-) -- Richard A. Hecker "if it isn't source, it isn't software" brought to you courtesy of NASA
RE: [oglbase-discuss] Vote results: 1 YES, 2 A
It should be also clear that using option c is no guarantee for
forcing an application programmer to update the source-code to be
compliant with the standard, as the following code (as it is today)
might still compile and work (if the libGL.so exports the right
symbols):
#ifdef WIN32
(*wglGetProcAddress("glPointParameterfEXT"))(...);
#else
glPointParameterfEXT(...);
#endif
With options (b) or (c) you should get a warning when compiling for oglbase
since the prototype for glPointParametersfEXT would not be defined, assuming
we did what you proposed in gl.h
#if something
#include GL/glext.h
#else
#define GL_EXT_point_parameters 1
extern void glPointParameterfEXT(...);
#endif
This is one of the major advantages of (b) over (a).
RE: [oglbase-discuss] Vote results: 1 YES, 2 A
On Tue, 4 Apr 2000, Thomas Roell wrote:
#ifdef GL_EXT_point_parameters
#ifdef WIN32
pfn = wglGetProcAddress("glPointParameterfEXT");
#else
#ifdef GLX_ARB_get_proc_address
pfn = glXGetProcAddressARB("glPointParameterfEXT");
#else
pfn = glPointParameterfEXT;
#endif
#endif
#endif
I think there are some things that we can put in place to help minimize code
like this (no offense 8-)). I don't think that we can figure it out in just a
couple of days, which is why I voted for A. Let's get what we have out there,
and start getting some practical experience.
My comment to Jon was that I predict a version 1.1 in the near future becasue
despite everyones best effort, there will be something we missed. Likewise,
a coherent technique for minimizing the code changes required can also be
developed for 1.1.
What I am envisioning is a set of prototypes defined that will allow
existing code to do the right thing, and only require a little header
file adjustments (ie include glext.h or not), and a single block of code
surrounded by the same conditional that is used to indicate the need or
absence of glext.h.
Stuart
Stuart R. Anderson [EMAIL PROTECTED]
Metro Link Incorporated South Carolina Office
4711 North Powerline Road129 Secret Cove Drive
Fort Lauderdale, Florida 33309 Lexington, SC 29072
voice: 954.938.0283x496 voice: 803.951.3630
fax: 954.938.1982 SkyTel: 800.405.3401
http://www.metrolink.com/
