I’ve compiled together several glext.h files in order to get the most enumerants, and I’ve got this:
#define GL_MAX_TEXTURES_SGIS 0x835D
#define GL_MAX_TEXTURES_SGIS 0x83C3
One value came from the NVidia GL SDK, the other from its ATI counterpart.
Why are these values different and what is the right one ?
Thanks,
Julien.
Hummm… Is this an implementation bug or what ?
In fact NVidia and ATI do not expose the same tokens of SGIS_multitexture:
// NVidia tokens:
#define GL_SELECTED_TEXTURE_SGIS 0x835C
#define GL_MAX_TEXTURES_SGIS 0x835D
#define GL_TEXTURE0_SGIS 0x835E
#define GL_TEXTURE1_SGIS 0x835F
#define GL_TEXTURE2_SGIS 0x8360
#define GL_TEXTURE3_SGIS 0x8361// Now ATI ones:
#define TEXTURE0_SGIS 0x835E
#define TEXTURE1_SGIS 0x835F
#define GL_SELECTED_TEXTURE_SGIS 0x83C0
#define GL_SELECTED_TEXTURE_COORD_SET_SGIS 0x83C1
#define GL_SELECTED_TEXTURE_TRANSFORM_SGIS 0x83C2
#define GL_MAX_TEXTURES_SGIS 0x83C3
#define GL_MAX_TEXTURE_COORD_SETS_SGIS 0x83C4
#define GL_TEXTURE_ENV_COORD_SET_SGIS 0x83C5
#define GL_TEXTURE0_SGIS 0x83C6
#define GL_TEXTURE1_SGIS 0x83C7
#define GL_TEXTURE2_SGIS 0x83C8
#define GL_TEXTURE3_SGIS 0x83C9
#define GL_TEXTURE4_SGIS 0x83CA
#define GL_TEXTURE5_SGIS 0x83CB
#define GL_TEXTURE6_SGIS 0x83CC
#define GL_TEXTURE7_SGIS 0x83CD
#define GL_TEXTURE8_SGIS 0x83CE
#define GL_TEXTURE9_SGIS 0x83CF
#define GL_TEXTURE10_SGIS 0x83D0
#define GL_TEXTURE11_SGIS 0x83D1
#define GL_TEXTURE12_SGIS 0x83D2
#define GL_TEXTURE13_SGIS 0x83D3
#define GL_TEXTURE14_SGIS 0x83D4
#define GL_TEXTURE15_SGIS 0x83D5
#define GL_TEXTURE16_SGIS 0x83D6
#define GL_TEXTURE17_SGIS 0x83D7
#define GL_TEXTURE18_SGIS 0x83D8
#define GL_TEXTURE19_SGIS 0x83D9
#define GL_TEXTURE20_SGIS 0x83DA
#define GL_TEXTURE21_SGIS 0x83DB
#define GL_TEXTURE22_SGIS 0x83DC
#define GL_TEXTURE23_SGIS 0x83DD
#define GL_TEXTURE24_SGIS 0x83DE
#define GL_TEXTURE25_SGIS 0x83DF
#define GL_TEXTURE26_SGIS 0x83E0
#define GL_TEXTURE27_SGIS 0x83E1
#define GL_TEXTURE28_SGIS 0x83E2
#define GL_TEXTURE29_SGIS 0x83E3
#define GL_TEXTURE30_SGIS 0x83E4
#define GL_TEXTURE31_SGIS 0x83E5
What values must I use in my driver-independant software ? Can’t I rely on SGI’s multitexture extension if ARB & EXT are not available ?
Too bad one can’t rely on the extension name…
Julien.
[This message has been edited by deepmind (edited 03-06-2002).]
Ok, this really puzzles me as well, but I’ll blatantly state now that every recent gl driver supporting the SGIS extension will also support the ARB extension.
(funny thing is that the ARB enumerant is 0x84E2)
Originally posted by zeckensack:
[b]Ok, this really puzzles me as well, but I’ll blatantly state now that every recent gl driver supporting the SGIS extension will also support the ARB extension.
(funny thing is that the ARB enumerant is 0x84E2)[/b]
Yes but the purpose of supporting SGIS_multitexture is to do multitexturing on drivers which do not provide {ARB|EXT}_multitexture. I think of “old” SGI graphic stations, and other architectures with only GL 1.1 drivers.
Julien, who just dropped multitexturing support for pre 1.2 .
Where did you find the nVidia header for SGIS_multitexture ?
I could only find SGIS_multitexture in the ATI header files, it’s missing in the nVidia SDK and extension PDF. it’s also missing in the SGI extension registry.
SGIS_multitexture is legacy anyway, you should use ARB_multitexture instead.
Originally posted by opla:
Where did you find the nVidia header for SGIS_multitexture ?
I found it in NVidia headers (1.0.2314 on Linux).
Originally posted by opla:
SGIS_multitexture is legacy anyway, you should use ARB_multitexture instead.
Direct3D8’s wrapper exposes a GL1.1 driver which is extended with SGIS_multitexture. It’s sad I have to drop multitexturing support on this platform.
Julien.
This is, shall I say, a bizarre extension.
It’s not in the extension registry – which means that I don’t know whether any given spec for it is the right or wrong spec.
At the risk of telling you that the emperor has no clothes, let me say the following:
Neither set of enumerants that I saw a list of #define’s for above matches the extension spec that I have.
If this hasn’t already scared you enough, let me make myself completely clear: run far, far away from this extension! PLEASE don’t use it!
I’ll add that I haven’t even told you some of the other frightening things about SGIS_multitexture.
Direct3D8’s wrapper exposes a GL1.1 driver which is extended with SGIS_multitexture. It’s sad I have to drop multitexturing support on this platform.
Then blame Microsoft. SGIS_multitexture is deprecated, obsolete, whatever you may call it. Even the extension registry dropped it. That’s what happens to extensions that get promoted to ARB status with the same functionality. If anything, this is just another effort by Microsoft to obfuscate its OpenGL support.
Originally posted by mcraighead:
[b]I’ll add that I haven’t even told you some of the other frightening things about SGIS_multitexture.
- Matt[/b]
Do tell!!! 
[This message has been edited by GPSnoopy (edited 03-06-2002).]
Originally posted by zeckensack:
Then blame Microsoft. SGIS_multitexture is deprecated, obsolete, whatever you may call it.
It is not deprecated nor obsolete in GL 1.1, as ARB_ extensions do not exist. Neither a version of a library can be qualified as “obsolete”: GL1.1 has gone unsupported, which is quite different.
I can blame M$ since they did a wrapper. Perhaps GL1.2 was too complex to wrap in a decent time, but once again it does prove their interest in GL.
I only hope future windows updates will upgrade it to GL1.2, then 1.3, then… dooh that old post about D3D10 and GL2.1 fusionning, again )
Julien.
It is not deprecated nor obsolete in GL 1.1, as ARB_ extensions do not exist. Neither a version of a library can be qualified as “obsolete”: GL1.1 has gone unsupported, which is quite different.
Microsoft had a choice here. ARB extensions were kind of introduced with the release of gl1.2 but that does not mean that they require that version. A gl1.1 implementation can expose them.
Especially for something as basic and as frequently used as multitexturing, this is just another slap in the face for the OpenGL community. Heck, the whole concept of having that wrapper is scary. People would do best to ignore it altogether and to spread the word on how to permanently deactivate it. That may be a good thing to include in every OpenGL program. Detect XP, detect wrapper, kill wrapper.
This is all just politics. Programmers don’t need this kind of nonsense.
Direct3D8’s wrapper exposes a GL1.1 driver which is extended with SGIS_multitexture. It’s sad I have to drop multitexturing support on this platform.
did you try this Direct3D8’s wrapper ?
I tested it and submitted the report to delphi3d and I can tell you that it exposes both
check yourself at http://www.delphi3d.net/hardware/viewreport.php?report=243
and here http://www.fraps.com/q3-d3d.gif
