search

KhronosGroup / OpenGL-Registry

OpenGL, OpenGL ES, and OpenGL ES-SC API and Extension Registry
678 stars 274 forks source link

GL_LUMINANCE is missing from glext.h #577

Closed hikari-no-yume closed 1 year ago

hikari-no-yume commented 1 year ago

I believe this is a legacy (compatibility profile) feature, so it makes sense it's not in gl.h glcorearb.h [edit: I wrote the wrong filename when I posted this], but it seems to be missing from glext.h too? Is this a mistake?

pdaniell-nv commented 1 year ago

GL_LUMINANCE should be defined in gl.h. Where did you get your gl.h from?

hikari-no-yume commented 1 year ago

@pdaniell-nv Oh, my apologies, I wrote the wrong filename. The OpenGL ES header file gl.h does have this, but the problem I noticed was in the OpenGL (non-ES) headers, which are split between glcorearb.h and glext.h.

pdaniell-nv commented 1 year ago

There is also a gl.h for OpenGL, and that file is typically provided by the platform. On Windows it's in the Windows SDK.

hikari-no-yume commented 1 year ago

I see, but it's not in this repository, right?

Is it the case that glcorearb.h and glext.h are not supposed to include the compatibility profile then?

pdaniell-nv commented 1 year ago

Right, it's not in this repository. I forget the history of the gl.h file, but there is a reason it's organized like this. I think for OpenGL 1.0 the gl.h represents all the functions the application can link against without having to do wglGetProcAddress to dynamically load them. Since this was very much platform dependent it didn't make sense to define a potentially conflicting gl.h in the OpenGL repo.

hikari-no-yume commented 1 year ago

Ah, I see. I guess GL_LUMINANCE was included in the very first version of OpenGL and therefore it would be in gl.h. I just had a misconception that this extra hesder wasn't required.

Thanks, I guess this is not a bug then.

oddhack commented 1 year ago

Right, it's not in this repository. I forget the history of the gl.h file, but there is a reason it's organized like this. I think for OpenGL 1.0 the gl.h represents all the functions the application can link against without having to do wglGetProcAddress to dynamically load them. Since this was very much platform dependent it didn't make sense to define a potentially conflicting gl.h in the OpenGL repo.

Historically during the OpenGL-D3D wars, Microsoft stopped doing updates of their ICD after OpenGL 1.1, including the gl.h shipped with it. Since it was impossible for the ARB to publish a gl.h which would get deployed on Windows, we created glext.h, and to avoid conflicts with the platform gl.h, it only included new extension and OpenGL 1.2 and later version interfaces. Later when compatibility mode happened, glcorearb.h was created for people using only the core profile, and we could include the 1.0 / 1.1 APIs there, but GL_LUMINANCE Is not in the core profile so doesn't appear there.