Re: glad OpenGL loader generator
Am 13.08.2013 19:38, schrieb David: glad now supports also EGL, GLX and WGL You can add GLES to the list TODO: * GLES loader * lazy loading * debugging (tracing function calls and error-checks with glGetError) * helperfunctions like gladGetErrorString(GLenum) or gladEnumToString(GLenum) etc.
Re: glad OpenGL loader generator
On Tuesday, 13 August 2013 at 10:41:49 UTC, David wrote: Am 13.08.2013 05:51, schrieb evilrat: On Monday, 12 August 2013 at 13:45:46 UTC, David wrote: Did you confuse gles2 (GL ES 2.0) with gl3n? Or did you speak of glamour, which has indeed gl3n interaction, which can be turned on with -version=gl3n: make DCFLAGS+=-version=gl3n. But I recommend you to include gl3n and glamour as submodule or if you don't use git, simply the sources. This makes your code independent of a systemwide installation and it's only a few files. glad is a replacement for Derelicts GL bindings. Soon it will also provide a EGL support (which should already work), WGL and GLX. no no, i don't want use other opengl bindings right now, derelict just fine, but i need some good(public available) math lib to put in my examples, and the problem is that gl3n compiles as 32 bit(-m32) on OS X(i use it because i don't have PC and i don't know when i would have it) by default and there seems no way to remove this misbehavior :( This shouldn't happen and doesn't happen for me. Easiest way to use gl3n (and also what I recommend) is to use it as git submodule or simply copy the sources into your project and integrate it into your buildsystem. Works well with dub. Dead simple too.
Re: glad OpenGL loader generator
Am 13.08.2013 05:51, schrieb evilrat: On Monday, 12 August 2013 at 13:45:46 UTC, David wrote: Did you confuse gles2 (GL ES 2.0) with gl3n? Or did you speak of glamour, which has indeed gl3n interaction, which can be turned on with -version=gl3n: make DCFLAGS+=-version=gl3n. But I recommend you to include gl3n and glamour as submodule or if you don't use git, simply the sources. This makes your code independent of a systemwide installation and it's only a few files. glad is a replacement for Derelicts GL bindings. Soon it will also provide a EGL support (which should already work), WGL and GLX. no no, i don't want use other opengl bindings right now, derelict just fine, but i need some good(public available) math lib to put in my examples, and the problem is that gl3n compiles as 32 bit(-m32) on OS X(i use it because i don't have PC and i don't know when i would have it) by default and there seems no way to remove this misbehavior :( This shouldn't happen and doesn't happen for me. Easiest way to use gl3n (and also what I recommend) is to use it as git submodule or simply copy the sources into your project and integrate it into your buildsystem.
Re: glad OpenGL loader generator
On Tuesday, 13 August 2013 at 10:41:49 UTC, David wrote: This shouldn't happen and doesn't happen for me. Easiest way to use gl3n (and also what I recommend) is to use it as git submodule or simply copy the sources into your project and integrate it into your buildsystem. ok thanks, i'll try later.
Re: glad OpenGL loader generator
glad now supports also EGL, GLX and WGL
Re: glad OpenGL loader generator
Am 12.08.2013 07:06, schrieb evilrat: On Monday, 5 August 2013 at 21:42:59 UTC, David wrote: glad - is an OpenGL loader (with experimental gles support, --api=gles2) ... i looked at this on github and see an option to build with gl3n, then i see what it is, and looks like gl3n is a 'must have' for my simple tasks. but for some reason it only builds with -m32 on OS X, i can't see where it puts this flag in makefile and why do the hell it inserts this. can you help explain how to get rid off this? Mh, there is no option to interact with gl3n, gl3n is completly independent from glad/glamour/derelict. Did you confuse gles2 (GL ES 2.0) with gl3n? Or did you speak of glamour, which has indeed gl3n interaction, which can be turned on with -version=gl3n: make DCFLAGS+=-version=gl3n. But I recommend you to include gl3n and glamour as submodule or if you don't use git, simply the sources. This makes your code independent of a systemwide installation and it's only a few files. glad is a replacement for Derelicts GL bindings. Soon it will also provide a EGL support (which should already work), WGL and GLX.
Re: glad OpenGL loader generator
On Monday, 12 August 2013 at 13:45:46 UTC, David wrote: Did you confuse gles2 (GL ES 2.0) with gl3n? Or did you speak of glamour, which has indeed gl3n interaction, which can be turned on with -version=gl3n: make DCFLAGS+=-version=gl3n. But I recommend you to include gl3n and glamour as submodule or if you don't use git, simply the sources. This makes your code independent of a systemwide installation and it's only a few files. glad is a replacement for Derelicts GL bindings. Soon it will also provide a EGL support (which should already work), WGL and GLX. no no, i don't want use other opengl bindings right now, derelict just fine, but i need some good(public available) math lib to put in my examples, and the problem is that gl3n compiles as 32 bit(-m32) on OS X(i use it because i don't have PC and i don't know when i would have it) by default and there seems no way to remove this misbehavior :(
Re: glad OpenGL loader generator
On Monday, 5 August 2013 at 21:42:59 UTC, David wrote: glad - is an OpenGL loader (with experimental gles support, --api=gles2) ... i looked at this on github and see an option to build with gl3n, then i see what it is, and looks like gl3n is a 'must have' for my simple tasks. but for some reason it only builds with -m32 on OS X, i can't see where it puts this flag in makefile and why do the hell it inserts this. can you help explain how to get rid off this?
Re: glad OpenGL loader generator
On Tue, 2013-08-06 at 02:00 +0200, David wrote: Am 06.08.2013 01:11, schrieb Land: I really like the sound of this. I'll try it out tomorrow. glad to hear that ;) (to join w0rp with glad jokes) I guess you will just have to play Cream's I'm so glad as a theme tune. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: glad OpenGL loader generator
Am 06.08.2013 16:32, schrieb David: I posted it also on reddit, maybe it draws some attention: http://www.reddit.com/r/programming/comments/1jt9m5/multilanguage_opengl_loader_generator_based_on/ Interesting it seems like it was deleted, but I don't know why? ... Ok
Re: glad OpenGL loader generator
On Tuesday, 6 August 2013 at 16:47:52 UTC, David wrote: Am 06.08.2013 16:32, schrieb David: I posted it also on reddit, maybe it draws some attention: http://www.reddit.com/r/programming/comments/1jt9m5/multilanguage_opengl_loader_generator_based_on/ Interesting it seems like it was deleted, but I don't know why? ... Ok It's still there (also in /r/opengl). And the last comment was 2 hours ago.
glad OpenGL loader generator
glad - is an OpenGL loader (with experimental gles support, --api=gles2)
which is generated 1:1 from the OpenGL official spec
(https://cvs.khronos.org/svn/repos/ogl/trunk/doc/registry/public/api/gl.xml).
It has at the moment a backend for three languages (frontend parses,
backend generates code, like constants and function pointers).
https://github.com/Dav1dde/glad
What are the advantages over e.g. Derelict?
* supports *every* opengl extension
* always up to date
* (basically) never incorrect bindings
* easy to maintain
* easy API, 3 functions
* allows you to use your own loader
And the more important:
* provides an easy way to check if extension X is loaded
`enforce(GL_EXT_Cg_shader)` (same works for OpenGL versions
`enforce(GL_VERSION_3_2)`)
* glad generates loaders exactly for your needs. If you only need a
OpenGL 3.2 core profile with two extensions, glad can generate exactly
this code. Making your binding small, without overhead.
What your code might look like with glad:
import glad.gl; // imports all constants and functions, including extensions
import glad.loader : gladInit, gladTerminate, gladLoadGL;
void main() {
gladInit();
scope(exit) gladTerminate();
/* setup OpenGL context with e.g. glfw */
auto glv = gladLoadGL();
enforce(glv.major == 3 glv.minor == 2);
// or: enforce(GL_VERSION_3_2);
enforce(GL_EXT_texture_filter_anisotropic);
/* done, use OpenGL here */
}
gladInit() and gladTerminate() are not needed if you provide your own
loader, e.g. you use SDL:
void main() {
/* setup OpenGL context with SDL */
auto glv = gladLoadGL(SDL_GL_GetProcAddress);
enforce(glv.major == 3 glv.minor == 2);
/* done, use OpenGL here */
}
A fully blown OpenGL 4.4 compatability, all extensions loader:
https://github.com/Dav1dde/glad/tree/d
But I really recommend generating your own loader/binding for your exact
needs!
python main.py --generator=d
--extensions=GL_EXT_texture_filter_anisotropic --out-path=build
A example in C:
https://github.com/Dav1dde/glad/blob/master/example/c/simple.c (to show
glad is not rocket science!)
--- Slightly Offtopic, why Derelict/Dynamic linking is bad
glad was mainly written to have an easy backend to support multiple
languages at a time, but also to get rid of Derelict as a dependency.
(warn: dynamic/static linking rant)
OpenGL was the only reason I still used Derelict, now I could get rid of
another relativly big dependency. Don't get me wrong Derelict is great,
but dynamic loading isn't! Unfortunatly you have to dynamically load OpenGL.
Why is dynamic loading a problem?
Well static linking has several important advantages:
* slightly faster startup times
* easier to distribute
* no DLL hell like on windows! with all it's DLLs, it's a mess!
https://en.wikipedia.org/wiki/DLL_hell
If you depend on a system-wide installation of a library you get another
problem Windows might have a different DLL than Ubuntu a .so or
Archlinux or Debian old stable, so you have to ship your DLLs with you
or depend on a specific version, which makes distribution a lot harder.
You might say, but on Windows, I can't statically link because dmc
doesn't really work (e.g. Makefiles not supporting DM Make), objconv
(another dependency next to the C compiler) etc... Well on Windows you
can still use an import library. Which brings us to the next advantage.
You don't need two separate librarys for one and the same binding (one
which works like a C-Header and one with a ton of function pointers and
loader code attached).
Re: glad OpenGL loader generator
I'm glad you invested time in glad. I'll probably try it out soon enough.
Re: glad OpenGL loader generator
It looks like your D backend generates string literals with literal null bytes--this is unnecessary as string literals are already null terminated. (Documented here: http://dlang.org/interfaceToC.html (see final bullet under Calling C Functions) Also, it looks like loading each extension requires scanning all available extension names, e.g. loading 25 extensions requires 25 linear scans of the extension list. You might consider caching and sorting if the number of extensions requested is more than a handful.
Re: glad OpenGL loader generator
Am 06.08.2013 00:17, schrieb Justin Whear: It looks like your D backend generates string literals with literal null bytes--this is unnecessary as string literals are already null terminated. (Documented here: http://dlang.org/interfaceToC.html (see final bullet under Calling C Functions) This is (was) on purpose. I should probably change that now, since it will confuse people. I had for a short time a mess in the generators and tried to use the D generator to build for another language too, which required the explicit \0 and .ptr Also, it looks like loading each extension requires scanning all available extension names, e.g. loading 25 extensions requires 25 linear scans of the extension list. You might consider caching and sorting if the number of extensions requested is more than a handful. I was thinking of that, too, but caching the OpenGL call to glGetStringi, I don't think you can prevent the linear searches.
Re: glad OpenGL loader generator
I really like the sound of this. I'll try it out tomorrow.
Re: glad OpenGL loader generator
Am 06.08.2013 00:33, schrieb Justin Whear:
On Tue, 06 Aug 2013 00:21:46 +0200, David wrote:
I was thinking of that, too, but caching the OpenGL call to
glGetStringi, I don't think you can prevent the linear searches.
Why not something like this for the GL_VERSION = 3 codepath in has_ext?
---
static auto availableExts;
if (availableExts.empty)
{
int num;
glGetIntegerv(GL_NUM_EXTENSIONS, num);
availableExts = new string[](num);
foreach (i, ref extName; availableExts)
extName = (cast(const(char)*)glGetStringi(GL_EXTENSIONS, i)).idup;
availableExts.sort();
}
// Use binary search
return assumeSorted(availableExts).contains(ext);
---
Thanks, I will definitly look into improving it (when I wake up ;))
Re: glad OpenGL loader generator
Am 06.08.2013 01:11, schrieb Land: I really like the sound of this. I'll try it out tomorrow. glad to hear that ;) (to join w0rp with glad jokes)
Re: glad OpenGL loader generator
On 8/6/13, David d...@dav1d.de wrote: Thanks, I will definitly look into improving it (when I wake up ;)) You should know better than to code when you're sleepwalking! glad works great for me, I've tested it on Win7 x64. Great project!
