Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Page 1 of 2 12 LastLast
Results 1 to 10 of 12

Thread: What is PFNGLACTIVETEXTUREARBPROC?

  1. #1
    Member Regular Contributor
    Join Date
    Mar 2015
    Posts
    296

    Question What is PFNGLACTIVETEXTUREARBPROC?

    Many tabout texture will incluse this pointer PFNGLACTIVETEXTUREARBPROC lActiveTextureARB = NULL;,
    It seems a callback function, What is its meaning?

  2. #2
    Member Regular Contributor
    Join Date
    Mar 2015
    Posts
    296
    Its prototype function is
    void ( APIENTRY * glActiveTextureARB)( GLenum texture );
    thus PFNGLACTIVETEXTUREARBPROC should be APIENTRY.

  3. #3
    Member Regular Contributor
    Join Date
    Mar 2015
    Posts
    296
    this stucture seems to use for windows.

  4. #4
    Senior Member OpenGL Guru Dark Photon's Avatar
    Join Date
    Oct 2004
    Location
    Druidia
    Posts
    4,567
    See:

    * glActiveTexture

    The ARB suffix is from ancient times (1990s) when the extension ARB_multitexture was needed to get access to this function pointer, and you had to fetch the function pointers with {glX,wgl}GetProcAddress.

    Now this is just a legacy compatibility shim you've long been able to ignore. Just use the core symbol glActiveTexture() and forget about it.

  5. #5
    Member Regular Contributor
    Join Date
    Mar 2015
    Posts
    296
    Quote Originally Posted by Dark Photon View Post
    See:

    * glActiveTexture

    The ARB suffix is from ancient times (1990s) when the extension ARB_multitexture was needed to get access to this function pointer, and you had to fetch the function pointers with {glX,wgl}GetProcAddress.
    ze
    Now this is just a legacy compatibility shim you've long been able to ignore. Just use the core symbol glActiveTexture() and forget about it.
    arb is an orginazition, which made the regulars. the doc told that.
    you mean this command with arb suffix will be abandoned for good?
    thank

  6. #6
    Member Regular Contributor
    Join Date
    Mar 2015
    Posts
    296
    This is content from the page, but no any information on FNGLACTIVETEXTUREARBPROC glActiveTextureARB
    Parameterstexture
    Specifies which texture unit to make active. The number
    of texture units is implementation dependent, but must
    be at least 80. texture must be
    one of
    GL_TEXTUREi,
    where i ranges from zero to the value
    of
    GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS
    minus one. The initial value is
    GL_TEXTURE0.
    Description
    glActiveTexture selects which texture unit subsequent texture state calls will
    affect. The number of texture units an implementation supports is
    implementation dependent, but must be at least 80.

  7. #7
    Member Regular Contributor
    Join Date
    Mar 2015
    Posts
    296
    Here is the glActiveTextureARB , but no information on FNGLACTIVETEXTUREARBPROC
    http://www.xfree86.org/current/glAct...ARB.3.html#toc

    eqn not supported
    Parameters

    texture
    Specifies which texture unit to make active. The number of texture units is implementation dependent, but must be at least two. texture must be one of GL_TEXTURE$i$_ARB, where 0 <= $ i $ < GL_MAX_TEXTURE_UNITS_ARB, which is an implementation-dependent value. The initial value is GL_TEXTURE0_ARB.

    Description
    glActiveTextureARB selects which texture unit subsequent texture state calls will affect. The number of texture units an implementation supports is implementation dependent, but must be at least 2.

    Vertex arrays are client-side GL resources, which are selected by the glClientActiveTextureARB routine.

  8. #8
    Member Regular Contributor
    Join Date
    Mar 2015
    Posts
    296
    At last we find it which was defined by SGI in head file of glext.h

    typedef void (APIENTRY * PFNGLPOINTPARAMETERFARBPROC)(GLenum pname,
    GLfloat param);
    typedef void (APIENTRY * PFNGLPOINTPARAMETERFVARBPROC)(GLenum pname,
    const GLfloat *params);

    then we can use to define a pointer.
    share it for all out there.

  9. #9
    Senior Member OpenGL Guru
    Join Date
    Jun 2013
    Posts
    2,999
    The PFN* names are typedefs for function pointers. They're used for declaring variables (or structure fields) which will hold a function pointer returned from wglGetProcAddress(), glXGetProcAddress, or similar.

    On Windows, opengl32.dll only exports the symbols from the OpenGL 1.1 API. Any other function (i.e. those from later versions or from extensions) can only be accessed by using wglGetProcAddress() to obtain a function pointer.

    On Linux, libGL.so typically exports symbols for all functions which were known at the time that it was generated. So the set of exported symbols will depend upon the version of the library, with later versions exporting more symbols than earlier versions. If an executable or library imports a symbol which doesn't exist in the system's libGL, the program will fail to execute. If you want to write code which uses newer functions where available, but will still run on older systems, it's necessary to access those functions via glXGetProcAddress() (after checking that both the client library and the X server support the corresponding version or extension) so that the symbol doesn't become a hard dependency.

    Libraries such as GLEW exist to deal with this automatically in a cross-platform manner.

  10. #10
    Member Regular Contributor
    Join Date
    Mar 2015
    Posts
    296
    Quote Originally Posted by GClements View Post
    The PFN* names are typedefs for function pointers. They're used for declaring variables (or structure fields) which will hold a function pointer returned from wglGetProcAddress(), glXGetProcAddress, or similar.

    On Windows, opengl32.dll only exports the symbols from the OpenGL 1.1 API. Any other function (i.e. those from later versions or from extensions) can only be accessed by using wglGetProcAddress() to obtain a function pointer.

    On Linux, libGL.so typically exports symbols for all functions which were known at the time that it was generated. So the set of exported symbols will depend upon the version of the library, with later versions exporting more symbols than earlier versions. If an executable or library imports a symbol which doesn't exist in the system's libGL, the program will fail to execute. If you want to write code which uses newer functions where available, but will still run on older systems, it's necessary to access those functions via glXGetProcAddress() (after checking that both the client library and the X server support the corresponding version or extension) so that the symbol doesn't become a hard dependency.

    Libraries such as GLEW exist to deal with this automatically in a cross-platform manner.
    Thank you very much for the excellent answer.
    I wonder why they use so long word with capital letter? very hard to recognize. very hard to memory

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •