I’m writing an opengl 3d renderer within openfl and need glDrawBuffers().
I’ve added some native functionality already by interfacing directly with SDL within a native extension, but when attempting to call any valid SDL_GL_GetProcAddress() functions I get a segfault.
Does anyone have any experience calling “unsupported” opengl functions, or even just glDrawBuffers in native? I am currently dev’ing within Linux if it makes any difference.
I’m not 100% sure what road we should take when walking the line between what’s cross-platform and available (sticking to the WebGL API, for example) but also allowing methods that are specific only to one GL implementation.
You could take a look at implementing in Lime directly, though we’d need to decide if we expose it, and how. Another method might be to use HXCPP meta tags, to try and inject a call to GL directly:
I think the only thing is that we dynamically reference GL, in case it is not available on the system. Including GL.h might trigger a compile error, not sure, but could be an interesting solution.
Actually, if you’re doing a native extension already, doesn’t a standard GL call work, since the API is global?
Lime seems to load GL @ runtime, rather than linking against it (so no, it’s not globally accessible).
I’ve settled on this for now in linux:
void *opengl = dlopen("libGL.so.1", RTLD_NOW|RTLD_GLOBAL)?:dlopen("libGL.so", RTLD_NOW|RTLD_GLOBAL);
glDrawBuffers = (PFNGLDRAWBUFFERSPROC) dlsym(opengl, "glDrawBuffers");
That inline cpp is very useful, thanks! 
I was looking for that yesterday to see if there was such a thing, but couldn’t find it.
glDrawBuffers is in WebGL (well, v2. There are extensions for accessing it in v1)
I guess there are 2 main options for supporting more of gl:
I would opt for both.
I’ll probably look at doing this myself when my renderer is done, if nobody else has approached it.
In this case, I think it would make sense to make it available, perhaps we could consider a format where the returned GL context could be a version with more features available. I wonder what the status is for WebGL 2 / OpenGL ES 3 adoption
Well… (each is basically a subset of the next)
So desktop - most everyone, mobile - about a third of users, html5 - nobody yet, but it is coming.
It’s hard to decide where to draw lines between “safe” calls that are supported everywhere, while not locking the door on features that are available elsewhere.
If it was not prone to encouraging features that are not available (or ending up with too funny of a hybrid API), it might make sense to expose everything under the GL class, but not under the GLRenderContext type.
This would mean that in a Lime render context, it exposes only the safe, cross-platform WebGL features, while accessing the underlying GL type directly provides access to features that are only available under some circumstances, although this begins to demand the ability to check what GL type and version is available.
Another way would be multiple GL classes, one extending the other.
It would be hard to decide what to call it, though, if we had more than one class – “GL” is pretty generic, but “GL2” sounds to me like desktop GL 2, not WebGL 2 or GLES 3, though I bet it’s better than “GLPlus” or “GLExtended” 
The numerous gl versions are a pain. If webgl numbers matched gles it’d be easier, since that’s really what we’re targetting.
Maybe call them GLES2 and GLES3?
There are desktop extensions GL_ARB_ES2_compatibility and GL_ARB_ES3_compatibility for running opengl in gles profiles (adds a few gles functions missing from desktop, and enforces the same constraints), and webgl is just a marginally smaller subset of gles. So I’d propose calling them GLES2 & 3, but only offering everything in the lowest common denominator (webgl), maybe with the extra functions available outside html5 targets.