Why is nv exporting gl 1.x versions above 1.1 in their windows drivers? Also, why isn’t the ext_vertex_array thrown out of nv docs when ext_polygon_offset is? What’s going on?
I thought that above gl 1.1 on windows we got to use the extensions despite any improvements to their gl core counterparts. wglGetProcAddress() suppose to only return extensions not gl core functions. Though getting at core functions also work(as far as I remember) for some strange reason. Thanks.
No, wglGetProcAddress is supposed to return extension functions AND core functions above 1.1.
EXT_vertex_array is not thrown out because there could be very old GL programs around that were written when this functionality was not in the core and that depend on this extension. Strictly speaking, an extension should never be thrown out, no matter if its in the core now…
I see. Still kind of strange that poly offset is not documented in nv/ati docs. Do folks bother about using gl core? It’s probably more trouble then it’s worth, imo. I remember ati sat on the gl 1.3 for like ages while nv was at 1.4 already. So the only sensible way to me is to use extensions and forget about the core unless one wants d3d like headache. Thoughts?
So basically, we have to check ext. string and not rely on gl version alone. For example the arb_multisample is void for gf1/2 eventhough driver for this card exposes gl 1.5 which is well above 1.3 what’s needed for this extension. If I relied on gl version alone then something icky 
would happen.
Ok, one last thing. I think ihvs should mirror the sgi docs and expose all the extensions that gl core is made out of. That way since I can’t depend on gl version w/o also querying ext. string, I would know which extension to query by looking up sgi specs rather than playing a detective and crossreferencing ihv docs as in example of SGIS_texture_edge_clamp which sgi adopts and makes it into core, yet my nv driver doesn’t expose this extension and it exposes ext_texture_edge_clamp instead which isn’t listed as the one that’s being adopted in the gl core. Weird, huh?
I dont bother checking core version, I just check to see if the extensions are available.
The last time I had a look at the core spec, it was in some ghastly font, so I dont bother.
Originally posted by Nutty:
I dont bother checking core version, I just check to see if the extensions are available.
Agreed.
The last time I had a look at the core spec, it was in some ghastly font, so I dont bother.
You should download a newer rev. The font is much nicer (it’s truly scalable now) and bookmarks and cross-section links have been added. Much easier to navigate and read than the 1.2.1 spec
what is ugly so that the multi-texture description is gone in the newer spec. Actually the whole multi-texture description is hard to find in a “readable state” as that older spec doc is really ugly to read, and on SGI they dont have the .txt for the ARB/SGIS_multitexture extension anymore…
however some older nvidia paper had a nice description of its functionality
I’ve also noticed that those sgi exe docs aren’t being updated while ihv ones are. So that’s something to note.
Ok, so you guys are using gl_arb_blah to see if the ext. string has that extension and then if it does you actually retrieve gl core function w/o the arb affix? I always got the arb affixed function out but now I’m rethinking this whole ordeal and would rather use gl core because of some of these following extensions that have changed a bit when migrated to the gl core. Also, I noticed that lately ext extensions made it to the core before being promoted to arb status first. Seems to me like that arb thing they had going since gl 1.2 kind of deteriorated. I mean what’s the point if you going to grab ‘ext’ and put it into the core anyways.
Ok, these exts have changed a bit when migrated to the core:
gl 1.1
ext_vertex_array
ext_polygon_offset
ext_blend_logic_op
ext_texture
ext_texture_object
gl 1.2
ext_packed_pixels
gl 1.3
arb_multisample
gl 1.4
ext_texture_lod_bias
I think there should be a separate glGetStringCore() to see if a core functionality is supported for the gpu. I can’t rely on checking gl version only because some features are not supported(not emulated) for my card. Also, it would reduce the confusion of using an extension name to see if core functionality is supported. Kind of strange the way it’s now.
Ok, so what do you think about me checking gl version + extensions(that made it to core along ihv ones) then grabbing function pointer with a name that omits the ‘arb’ or ‘ext’ or ‘ihv’ moniker in the name. I should then be getting the core function not the extension, right? Thanks.
I just checked, the value from wglGetProcAddy() is not null when a function isn’t supported. This spells trouble. What name do I use when I want core gl function? I can’t use sgis_texture_edge_clamp since my driver doesn’t publish it(this ext. is in sgi core gl specs as being the one that the core is based on). Is it safe to use ext_texture_edge_clamp instead and then get gl core function w/o the ext affix? Or do I get back extension function instead? Thanks, an am sorry for asking these questions which would never surface if I stuck to my “use extensions only policy” but I would like to use the core instead to get the improvements that were done to those extensions. Thanks.
If you want a core GL func, you use the unadorned name, but with the “gl” prefix. For example, glTexImage3D().
You can assume that that function will be available if the correct version of OpenGL is supported (i e, scanf(versionString, “%d.%d”) returns >= 1.3 in this case).
Note that GeForce2 doesn’t support 3D texture, so the extension is not exposed, but it does support a version of GL that requires 3D texture support, so getting glTexImage3D and all the other 3D texture stuff will work. It’ll just work very slowly (software rasterization).
See the problem is that you can’t rely on gl version alone. Take for example arb_multisample or its gl core equivalent(some functions that you can get out of the driver). My gfx card driver publishes gl 1.4 but not this extension which is 1.3. If I relied on gl version I would get back valid addy but not the core function I don’t think. You see, the driver doesn’t return nulled addy for features my card doesn’t support. So therefore I would have to query the extension string as well. But what if the extension name isn’t published by the driver? Like in sgis_texture_edge_clamp case? Can I use ext_texture_edge_clamp instead(which is published by my driver)? Would I still get the core function or the extension?(assuming ext prefix isn’t used in getprocaddy()).
OOps! forgot to say that I appreciate your comments:)
Ok, it seems that nv forgot to put sw/em in their gl docs for arb_multisample so I can rely on gl version after all. It was just a fluke in the docs and partly my own thinking. Thanks all for all your help.
