Why is test/testgles2.c's way of getting functions not part of SDL_opengles2.h (along with SDL_gles2func.h)?

I saw using test/testgles2.c’s code recommended for loading GL functions in here: OpenGL ES2 support on Windows

… and it seems to me like an approach that would be needed by a lot of SDL2 users. So why not throw in some code like the following into SDL_opengles2.h, and add in SDL_gles2funcs.h into the public include folder?

typedef struct SDL_gles2funcs {
    #define SDL_PROC(ret,func,params) ret (APIENTRY *func) params;
    #include "SDL_gles2funcs.h"
    #undef SDL_PROC
} SDL_gles2funcs;  // based on SDL2's test/testgles2.c

static SDL_gles2funcs *SDL_GL_LoadES2Funcs() {
    SDL_gles2funcs *data = SDL_malloc(sizeof(*data));
    if (!data) {
        return NULL;
    memset(data, 0, sizeof(*data));

    #define __SDL_NOGETPROCADDR__
    #define __SDL_NOGETPROCADDR__
    #define __SDL_NOGETPROCADDR__

    #if defined __SDL_NOGETPROCADDR__
    #define SDL_PROC(ret,func,params) data->func=func;
    #define SDL_PROC(ret,func,params) \
        do { \
            data->func = SDL_GL_GetProcAddress(#func); \
            if ( ! data->func ) { \
                SDL_SetError("Couldn't load GLES2 function %s: %s", \
                             #func, SDL_GetError()); \
                SDL_free(data); \
                return NULL; \
            } \
        } while ( 0 );
    #endif /* __SDL_NOGETPROCADDR__ */

    #include "SDL_gles2funcs.h"
    #undef SDL_PROC
    return data;
}  // also based on SDL2's test/testgles2.c

This would allow doing this entire process via a simple:

_glcontext = SDL_GL_CreateContext(mainwindow);  // as usual

SDL_gles2funcs *_gl = SDL_GL_LoadES2Funcs();  // new function

Wouldn’t that save many people a lot of time? Or am I missing something why this isn’t part of the SDL_opengles2.h headers already? I’m just wondering, why make people copy it manually from test/testgles2.c such that the code can become outdated, and people can make mistakes adapting it, …?

If SDL2 devs want to include the above code as-is, I don’t need credit/attribution/any copyright… or anything for the minor changes I did (if they qualify for copyright anyway as trivial as they are) so go ahead and do so if you want.

It will be great if the SDL developers add this feature to the public interface.

1 Like

There are a bunch of libraries already out there that do this, here are a bunch of examples:


So the SDL has its own function for getting GL functions, but instead I have to use both SDL and a third-party library. Right?

There’s https://gen.glad.sh/ for example, and the generated loader code is even Public Domain/CC0 (=> even less restrictions than zlib).

I’m not sure integrating something like this into SDL would make much sense, as you’d need separate loaders for OpenGL vs OpenGL ES and maybe even different versions of those, and it’d have to handle all the extensions as well etc. You might even need different headers - IIRC some OpenGL functions have different signatures in “normal” OpenGL vs ES

I think generating a glad loader that suits your needs and using it with SDL is quite workable.

1 Like

But SDL already has functionality for loading GL, GLES, and GLES2 functions. How do you think GL/GLES render works in SDL?