sokol-zig icon indicating copy to clipboard operation
sokol-zig copied to clipboard

Binding OpenGL functions at run-time.

Open stephenmartindale opened this issue 9 months ago • 1 comments

In light of #110 being resolved and in light of the existence of excellent things like https://github.com/castholm/zigglgen I feel it is only logical to wonder: is it or would it be possible to support runtime binding (late binding) for gl…() functions in sokol_gfx.h?

A working example which simply defers to the SDL's SDL_GL_GetProcAddress() (which, coincidentally, is precisely what I would want to do) can be seen at: https://github.com/castholm/zig-examples/blob/master/opengl-hexagon/main.zig

If this is already supported, I'll be delighted to learn so. I have failed to discover the mechanism and only observed that, currently, setting .dont_link_system_libs = true, and not linking to OpenGL at build-time results in linker errors. I'd like to be able to build without linking OpenGL and, instead, supply a table of procedures at runtime.

stephenmartindale avatar Apr 20 '25 16:04 stephenmartindale

The Windows backend already uses its own GL loader, since the Windows SDK doesn't come with uptodate GL support.

On other platforms a GL loaders isn't needed since the system SDKs provide the GL headers, and the GL DLLs are part of the system.

You can compile with the define SOKOL_EXTERNAL_GL_LOADER which (from the documentation):

indicates that you're using your own GL loader, in this case sokol_gfx.h will not include any platform GL headers and disable the integrated Win32 GL loader

...e.g. in that case you'll need to use a GL loader like flextgl to provide the GL headers and GL function wrappers (and some GL loader runtime init function dynamically loads the GL DLL, looks up the functions, puts those into a function table and provides GL API shim functions which are indirected through the function table).

Check the multiwindow-glfw.c sample in sokol-samples for an example (https://github.com/floooh/sokol-samples/blob/master/glfw/multiwindow-glfw.c), e.g. you'll need to include the GL loader headers before including the sokol_gfx.h implementation:

#include "flextgl33/flextGL.h"
#define SOKOL_IMPL
#define SOKOL_GLCORE
#define SOKOL_EXTERNAL_GL_LOADER
#include "sokol_gfx.h"

...and configure flextGL like this (should probably be updated to GL version 4.1):

https://github.com/floooh/sokol-samples/tree/master/glfw/flextgl33

...but I wonder what your actual use case is that isn't handled by the default behaviour? Why do you need your own GL loader?

I'd like to be able to build without linking OpenGL and, instead, supply a table of procedures at runtime.

The function table is only one half, the other is a matching GL header (and with SOKOL_EXTERNAL_GL_LOADER delegates all that to the user, e.g. you're expected to include a '3rd-party' GL header before including the sokol implementation - so that sokol-gfx doesn't need to worry about where the custom GL headers are located), and the 'function table' is created by the external GL loader (sokol-gfx doesn't need the function table since the GL loader provides GL function shims which do the function table lookup).

PS: also the whole 'bring your own GL loader' scenario is only really tested if you use sokol_gfx.h without sokol_app.h.

floooh avatar Apr 21 '25 09:04 floooh