www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Anyone using glad?

reply Jason Jeffory <JasonJeffory doodle.com> writes:
Seems like it is a very nice way to get into openGL from D.

http://glad.dav1d.de/

I generated the bindings for all the latest versions of the 
various specifications.
Does anyone have any tutorials that use this library effectively?

There's this

https://github.com/Dav1dde/glamour

But not sure what it is(diff between it and glad). Says it's a 
wrapper to OpenGL... but does it use the glad generated bindings?

It looks like I'd prefer this to derelict because it seems like 
it is a automatically generated binding... which means future 
extensibility and no "extra" stuff.

Would be nice if it works with dub. How could I use it easily 
with dub as a local library? (create a dependency from a local 
file location)

Thanks.
Jan 10 2016
next sibling parent reply Dav1d <d dav1d.de> writes:
On Sunday, 10 January 2016 at 21:30:32 UTC, Jason Jeffory wrote:

 Seems like it is a very nice way to get into openGL from D.

 http://glad.dav1d.de/

 I generated the bindings for all the latest versions of the 
 various specifications.
 Does anyone have any tutorials that use this library 
 effectively?

 There's this

 https://github.com/Dav1dde/glamour

 But not sure what it is(diff between it and glad). Says it's a 
 wrapper to OpenGL... but does it use the glad generated 
 bindings?

 It looks like I'd prefer this to derelict because it seems like 
 it is a automatically generated binding... which means future 
 extensibility and no "extra" stuff.

 Would be nice if it works with dub. How could I use it easily 
 with dub as a local library? (create a dependency from a local 
 file location)

 Thanks.


Hey,

I am the guy behind glad, you are most likely looking for: 
https://github.com/Dav1dde/glad#d
Instead of downloading the glad sources and installing Python you 
can use the website http://glad.dav1d.de/
(If I have time I will write more documentation and also have it 
on the website)

glad is just another way to load your OpenGL functions (kinda 
like Derelict does it), the main difference is, it exactly allows 
you to generate the feature set you need, if you're in doubt, you 
can also just generate everything.

Another difference is, it uses the official XML-Specification 
files, so it is always up to date and doesn't need to be 
maintained. This also means it can can generate files for 
EGL/GLES/WGL and GLX.

Glad itself is a library which happens to include a D generator 
'backend', that allows you to extend it and make a more advanced 
loader (e.g. introduce another layer and automatically check 
glGetError, see C/C++ Debug), but for your normal use the 
included generator is good enough.

Usage:

Basically you download the zip, add the source files to your 
project and build system and call gladLoadGL() (check the return 
value, `enforce(gladLoadGL())`) after creating a context. This 
will use the internal loader, if you use glfw you can pass 
glfwGetProcAddress to gladLoadGL(), if you use SDL you can use 
SDL_GL_GetProcAddress: `gladLoadGL(x => glfwGetProcAddress(x))`.

Then you can just go ahead and call the imported gl functions.

Why no dub?:

Well why would you want to use dub? Just generate the files and 
copy them into your source.

----

I also wrote glamour, glamour is just a library which abstracts 
the the OpenGL API and has some glue code for gl3n (maths), SDL 
(texture loading), glad/Derelict (for gl).
Jan 10 2016
parent reply Jason Jeffory <JasonJeffory doodle.com> writes:
On Sunday, 10 January 2016 at 21:53:45 UTC, Dav1d wrote:

 On Sunday, 10 January 2016 at 21:30:32 UTC, Jason Jeffory wrote:

 Seems like it is a very nice way to get into openGL from D.

 http://glad.dav1d.de/

 I generated the bindings for all the latest versions of the 
 various specifications.
 Does anyone have any tutorials that use this library 
 effectively?

 There's this

 https://github.com/Dav1dde/glamour

 But not sure what it is(diff between it and glad). Says it's a 
 wrapper to OpenGL... but does it use the glad generated 
 bindings?

 It looks like I'd prefer this to derelict because it seems 
 like it is a automatically generated binding... which means 
 future extensibility and no "extra" stuff.

 Would be nice if it works with dub. How could I use it easily 
 with dub as a local library? (create a dependency from a local 
 file location)

 Thanks.


 Hey,

 I am the guy behind glad, you are most likely looking for: 
 https://github.com/Dav1dde/glad#d
 Instead of downloading the glad sources and installing Python 
 you can use the website http://glad.dav1d.de/
 (If I have time I will write more documentation and also have 
 it on the website)

 glad is just another way to load your OpenGL functions (kinda 
 like Derelict does it), the main difference is, it exactly 
 allows you to generate the feature set you need, if you're in 
 doubt, you can also just generate everything.

 Another difference is, it uses the official XML-Specification 
 files, so it is always up to date and doesn't need to be 
 maintained. This also means it can can generate files for 
 EGL/GLES/WGL and GLX.

 Glad itself is a library which happens to include a D generator 
 'backend', that allows you to extend it and make a more 
 advanced loader (e.g. introduce another layer and automatically 
 check glGetError, see C/C++ Debug), but for your normal use the 
 included generator is good enough.

 Usage:

 Basically you download the zip, add the source files to your 
 project and build system and call gladLoadGL() (check the 
 return value, `enforce(gladLoadGL())`) after creating a 
 context. This will use the internal loader, if you use glfw you 
 can pass glfwGetProcAddress to gladLoadGL(), if you use SDL you 
 can use SDL_GL_GetProcAddress: `gladLoadGL(x => 
 glfwGetProcAddress(x))`.

 Then you can just go ahead and call the imported gl functions.

 Why no dub?:

 Well why would you want to use dub? Just generate the files and 
 copy them into your source.

 ----

 I also wrote glamour, glamour is just a library which abstracts 
 the the OpenGL API and has some glue code for gl3n (maths), SDL 
 (texture loading), glad/Derelict (for gl).



Cool, it looks really well done. I spend several hours 
researching and looking at various approaches. It was basically 
Derelict stuff or a lot of things that didn't look well done. I 
was wishing there was something that would automatically do 
it(looked into htod, swift, etc)... then I stumbled across your 
work!!! Was exactly what I wanted!

glfw is separate or have you done something with it(is it wgl?)?

I'm basically trying to get a minimal setup running on winx64. I 
don't want a lot of hassle that other "solutions" seem to have(no 
derelict, sdl, etc...). I know there has to be some windows 
stuff(glfw) haven't yet found a solution for it(haven't really 
looked yet).
Jan 10 2016
parent reply Dav1d <d dav1d.de> writes:
On Sunday, 10 January 2016 at 22:37:28 UTC, Jason Jeffory wrote:

 On Sunday, 10 January 2016 at 21:53:45 UTC, Dav1d wrote:

 On Sunday, 10 January 2016 at 21:30:32 UTC, Jason Jeffory 
 wrote:

 [...]


 Hey,

 I am the guy behind glad, you are most likely looking for: 
 https://github.com/Dav1dde/glad#d
 Instead of downloading the glad sources and installing Python 
 you can use the website http://glad.dav1d.de/
 (If I have time I will write more documentation and also have 
 it on the website)

 glad is just another way to load your OpenGL functions (kinda 
 like Derelict does it), the main difference is, it exactly 
 allows you to generate the feature set you need, if you're in 
 doubt, you can also just generate everything.

 Another difference is, it uses the official XML-Specification 
 files, so it is always up to date and doesn't need to be 
 maintained. This also means it can can generate files for 
 EGL/GLES/WGL and GLX.

 Glad itself is a library which happens to include a D 
 generator 'backend', that allows you to extend it and make a 
 more advanced loader (e.g. introduce another layer and 
 automatically check glGetError, see C/C++ Debug), but for your 
 normal use the included generator is good enough.

 Usage:

 Basically you download the zip, add the source files to your 
 project and build system and call gladLoadGL() (check the 
 return value, `enforce(gladLoadGL())`) after creating a 
 context. This will use the internal loader, if you use glfw 
 you can pass glfwGetProcAddress to gladLoadGL(), if you use 
 SDL you can use SDL_GL_GetProcAddress: `gladLoadGL(x => 
 glfwGetProcAddress(x))`.

 Then you can just go ahead and call the imported gl functions.

 Why no dub?:

 Well why would you want to use dub? Just generate the files 
 and copy them into your source.

 ----

 I also wrote glamour, glamour is just a library which 
 abstracts the the OpenGL API and has some glue code for gl3n 
 (maths), SDL (texture loading), glad/Derelict (for gl).



 Cool, it looks really well done. I spend several hours 
 researching and looking at various approaches. It was basically 
 Derelict stuff or a lot of things that didn't look well done. I 
 was wishing there was something that would automatically do 
 it(looked into htod, swift, etc)... then I stumbled across your 
 work!!! Was exactly what I wanted!

 glfw is separate or have you done something with it(is it wgl?)?

 I'm basically trying to get a minimal setup running on winx64. 
 I don't want a lot of hassle that other "solutions" seem to 
 have(no derelict, sdl, etc...). I know there has to be some 
 windows stuff(glfw) haven't yet found a solution for it(haven't 
 really looked yet).


I would recommend using glfw for a context/window, there is a 
binding in Deimos https://github.com/D-Programming-Deimos/glfw - 
You need to either compile it yourself or just download the pre 
compiled package from the website and get the .lib file 
(http://www.glfw.org/).

There is also an abstraction I wrote once: 
https://github.com/Dav1dde/glwtf not sure if it still works, it 
*should*.
But even without the abstraction, getting a window and context up 
with glfw is really easy (documentation is really good! 
http://www.glfw.org/documentation.html). There is also a C++ 
example using glad: 
https://github.com/Dav1dde/glad/blob/master/example/c%2B%2B/hellowindow2.cpp
which can easily be ported to D.

Basically all you need is glfw and glad to get started!
Jan 10 2016
parent reply Jason Jeffory <JasonJeffory doodle.com> writes:
On Sunday, 10 January 2016 at 23:14:33 UTC, Dav1d wrote:

 On Sunday, 10 January 2016 at 22:37:28 UTC, Jason Jeffory wrote:

 [...]


 I would recommend using glfw for a context/window, there is a 
 binding in Deimos https://github.com/D-Programming-Deimos/glfw 
 - You need to either compile it yourself or just download the 
 pre compiled package from the website and get the .lib file 
 (http://www.glfw.org/).

 There is also an abstraction I wrote once: 
 https://github.com/Dav1dde/glwtf not sure if it still works, it 
 *should*.
 But even without the abstraction, getting a window and context 
 up with glfw is really easy (documentation is really good! 
 http://www.glfw.org/documentation.html). There is also a C++ 
 example using glad: 
 https://github.com/Dav1dde/glad/blob/master/example/c%2B%2B/hellowindow2.cpp
which can easily be ported to D.

 Basically all you need is glfw and glad to get started!


OK, I'll give it a try. What about GLUT and WGL? Whats the 
difference between them all and glfw? Are all these just OS 
helpers to reduce the boilerplate code?

Also, how hard would it be to support cgl? (mac bindings)

Thanks!
Jan 10 2016
next sibling parent reply Jason Jeffory <JasonJeffory doodle.com> writes:
Ok. So I tried it out and having some issues ;/ got it basically 
to compile but 2 problems:


1. I have to get dub to include the lib, not a big deal, 
shouldn't be issue if I can get the right lib in. (not sure if I 
have to do all that conversion just or not, and glfw has several 
libs for different VS versions and such... not sure what that's 
all about).

2. I had to commend out the following code dealing with the 
keyboard callback:

	// Set the required callback functions
	//glfwSetKeyCallback(window, &key_callback);

gives the error

function app.key_callback (GLFWwindow* window, int key, int 
scancode, int action, int mode) is not callable using argument 
types ()

I tried with and without address passing. I can cast though

glfwSetKeyCallback(window, cast(GLFWkeyfun)&key_callback);

works(no errors, at least), and if that's correct, leaves only 
the lib issue.



alternate thing I tried but gladLoadGL undefined
	//(gladLoadGL()); // optionally you can pass a loader to this 
function
	//writefln("OpenGL Version %d.%d loaded", GLVersion.major, 
GLVersion.minor);





import std.stdio;

import glad.gl.all;
import deimos.glfw.glfw3;



// Window dimensions
const GLuint WIDTH = 800, HEIGHT = 600;

void main()
{

	glfwInit();
	// Set all the required options for GLFW
	glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 3);
	glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 3);
	glfwWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE);
	glfwWindowHint(GLFW_RESIZABLE, GL_FALSE);

	// Create a GLFWwindow object that we can use for GLFW's 
functions
	GLFWwindow* window = glfwCreateWindow(WIDTH, HEIGHT, 
"LearnOpenGL", null, null);
	glfwMakeContextCurrent(window);
	if (window == null)
	{
		writeln("Failed to create GLFW window");
		glfwTerminate();
		return;
	}
	
	// Set the required callback functions
	//glfwSetKeyCallback(window, &key_callback);

	//(gladLoadGL()); // optionally you can pass a loader to this 
function
	//writefln("OpenGL Version %d.%d loaded", GLVersion.major, 
GLVersion.minor);

	/*
	if (!gladLoadGLLoader(cast(GLADloadproc) glfwGetProcAddress))
	{
		writeln("Failed to initialize OpenGL context");
		return;
	}*/
	
	// Define the viewport dimensions
	glViewport(0, 0, WIDTH, HEIGHT);
	
	// Game loop
	while (!glfwWindowShouldClose(window))
	{
		// Check if any events have been activated (key pressed, mouse 
moved etc.) and call corresponding response functions
		glfwPollEvents();
		
		// Render
		// Clear the colorbuffer
		glClearColor(0.2f, 0.3f, 0.3f, 1.0f);
		glClear(GL_COLOR_BUFFER_BIT);
		
		// Swap the screen buffers
		glfwSwapBuffers(window);
	}
	
	// Terminates GLFW, clearing any resources allocated by GLFW.
	glfwTerminate();
	return;
}


// Is called whenever a key is pressed/released via GLFW
void key_callback(GLFWwindow* window, int key, int scancode, int 
action, int mode)
{
	writeln(key);
	if (key == GLFW_KEY_ESCAPE && action == GLFW_PRESS)
		glfwSetWindowShouldClose(window, GL_TRUE);
}
Jan 10 2016
parent reply Dav1d <d dav1d.de> writes:
On Monday, 11 January 2016 at 01:46:11 UTC, Jason Jeffory wrote:

 Ok. So I tried it out and having some issues ;/ got it 
 basically to compile but 2 problems:


 1. I have to get dub to include the lib, not a big deal, 
 shouldn't be issue if I can get the right lib in. (not sure if 
 I have to do all that conversion just or not, and glfw has 
 several libs for different VS versions and such... not sure 
 what that's all about).


I don't remember what lib you need, there were some linking 
issues on windows iirc, if it doesn't work using Derelict for 
glfw might be easier (another possible issue: the deimos bindings 
are outdated).




 alternate thing I tried but gladLoadGL undefined
 	//(gladLoadGL()); // optionally you can pass a loader to this 
 function
 	//writefln("OpenGL Version %d.%d loaded", GLVersion.major, 
 GLVersion.minor);


gladLoadGLLoader does not exist in the D version, the D thing 
would be gladLoadGL(myLoaderHere), this function takes a delegate 
not a function as argument!
Jan 11 2016
parent reply Jason Jeffory <JasonJeffory doodle.com> writes:
On Monday, 11 January 2016 at 10:01:11 UTC, Dav1d wrote:

 On Monday, 11 January 2016 at 01:46:11 UTC, Jason Jeffory wrote:

 Ok. So I tried it out and having some issues ;/ got it 
 basically to compile but 2 problems:


 1. I have to get dub to include the lib, not a big deal, 
 shouldn't be issue if I can get the right lib in. (not sure if 
 I have to do all that conversion just or not, and glfw has 
 several libs for different VS versions and such... not sure 
 what that's all about).


 I don't remember what lib you need, there were some linking 
 issues on windows iirc, if it doesn't work using Derelict for 
 glfw might be easier (another possible issue: the deimos 
 bindings are outdated).




 alternate thing I tried but gladLoadGL undefined
 	//(gladLoadGL()); // optionally you can pass a loader to this 
 function
 	//writefln("OpenGL Version %d.%d loaded", GLVersion.major, 
 GLVersion.minor);


 gladLoadGLLoader does not exist in the D version, the D thing 
 would be gladLoadGL(myLoaderHere), this function takes a 
 delegate not a function as argument!


but as I said,

source\app.d(35,3): Error: undefined identifier 'gladLoadGL'
source\app.d(36,42): Error: undefined identifier 'GLVersion'
source\app.d(36,59): Error: undefined identifier 'GLVersion'
dmd failed with exit code 1.

I'm using deimos, but is that a glad function or some other 
function supposedly by deimos?
Jan 11 2016
parent reply Dav1d <d dav1d.de> writes:
On Monday, 11 January 2016 at 16:30:58 UTC, Jason Jeffory wrote:

 On Monday, 11 January 2016 at 10:01:11 UTC, Dav1d wrote:

 [...]


 but as I said,

 source\app.d(35,3): Error: undefined identifier 'gladLoadGL'
 source\app.d(36,42): Error: undefined identifier 'GLVersion'
 source\app.d(36,59): Error: undefined identifier 'GLVersion'
 dmd failed with exit code 1.

 I'm using deimos, but is that a glad function or some other 
 function supposedly by deimos?



Looks like a minor issue, just import glad.gl.loader.
Jan 11 2016
parent reply Jason Jeffory <JasonJeffory doodle.com> writes:
So, I finally got it to work by abandoning demios and static 
linking. Derelict + dynamic linking worked with only about a min 
of problems(copying the proper dll to the correct place). I'd 
prefer static linking but I can deal with that later.

My current problem is: 1. The code doesn't work as expected: It 
should show a type of triangle on the display, instead the whole 
display is colored, probably user error as I cobbled together 
some tutorial code. 2*. I get an access violation when exiting 
the program. I have no idea how, why, or where this is 
happening(except, obviously towards the end of the program... 
probably a cleanup issue).

Any ideas? Thanks.



Here is the full code:


import std.stdio;
import std.string;
import std.conv;

import glad.gl.all;
import glad.gl.loader;
import derelict.glfw3.glfw3;
import std.exception;


immutable string minimalVertexShader = `
#version 120
attribute vec2 position;
void main(void)
{
     gl_Position = vec4(position, 0, 1);
}
`;

immutable string minimalFragmentShader = `
#version 120
void main(void)
{
     gl_FragColor = vec4(1.0, 0.0, 0.0, 1.0);
}
`;


// Window dimensions
const GLuint WIDTH = 800, HEIGHT = 600;

void main()
{
	DerelictGLFW3.load();
	
	glfwInit();
	
	// Set all the required options for GLFW
	glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 3);
	glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 3);
	glfwWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE);
	glfwWindowHint(GLFW_RESIZABLE, GL_FALSE);

	
	// Create a GLFWwindow object that we can use for GLFW's 
functions
	GLFWwindow* window = glfwCreateWindow(WIDTH, HEIGHT, 
"LearnOpenGL", null, null);
	glfwMakeContextCurrent(window);
	if (window == null)
	{
		writeln("Failed to create GLFW window");
		glfwTerminate();
		return;
	}
	
	// Set the required callback functions
	glfwSetKeyCallback(window, cast(GLFWkeyfun)&key_callback);

	enforce(gladLoadGL()); // optionally you can pass a loader to 
this function
	writefln("OpenGL Version %d.%d loaded", GLVersion.major, 
GLVersion.minor);
	
	
	// Define the viewport dimensions
	glViewport(0, 0, WIDTH, HEIGHT);

	float[] vertices = [ -0.1, -0.1,  0.1, -0.1,  -1, 1,  1, -0.1];
	ushort[] indices = [0, 1, 2, 3];
	uint vbo, ibo;
	// Create VBO
	glGenBuffers(1, &vbo);
	glBindBuffer(GL_ARRAY_BUFFER, vbo);
	glBufferData(GL_ARRAY_BUFFER, vertices.length * float.sizeof, 
vertices.ptr, GL_STATIC_DRAW);
	glBindBuffer(GL_ARRAY_BUFFER, 0);
	
	// Create IBO
	glGenBuffers(1, &ibo);
	glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, ibo);
	glBufferData(GL_ELEMENT_ARRAY_BUFFER, indices.sizeof, 
indices.ptr, GL_STATIC_DRAW);
	glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, 0);
	
	// Program
	auto program = glCreateProgram();
	// Vertex Shader
	auto vsh = glCreateShader(GL_VERTEX_SHADER);
	auto vshSrc = minimalVertexShader.toStringz;
	glShaderSource(vsh, 1, &vshSrc, null);
	glCompileShader(vsh);
	glAttachShader(program, vsh);
	// Fragment Shader
	auto fsh = glCreateShader(GL_FRAGMENT_SHADER);
	auto fshSrc = minimalFragmentShader.toStringz;
	glShaderSource(fsh, 1, &fshSrc, null);
	glCompileShader(fsh);
	glAttachShader(program, fsh);
	
	glLinkProgram(program);
	glUseProgram(program);
	
	auto position = glGetAttribLocation(program, "position");



	// Game loop
	while (!glfwWindowShouldClose(window))
	{
		// Check if any events have been activated (key pressed, mouse 
moved etc.) and call corresponding response functions
		glfwPollEvents();
		
		// Render
		// Clear the colorbuffer
		glClearColor(0f, 0f, 0f, 1.0f);
		glClear(GL_COLOR_BUFFER_BIT);


		glClearColor(1, 0.9, 0.8, 1);
		glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
		glBindBuffer(GL_ARRAY_BUFFER, vbo);
		glEnableVertexAttribArray(position);
		glVertexAttribPointer(position, 2, GL_FLOAT, GL_FALSE, 2 * 
float.sizeof, null);
		glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, ibo);
		glDrawElements(GL_TRIANGLE_STRIP, 4, GL_UNSIGNED_SHORT, null);
		glDisableVertexAttribArray(position);


		// Swap the screen buffers
		glfwSwapBuffers(window);
	}
	
	// Terminates GLFW, clearing any resources allocated by GLFW.
	glfwTerminate();
	return;

}

// Is called whenever a key is pressed/released via GLFW
void key_callback(GLFWwindow* window, int key, int scancode, int 
action, int mode)
{
	write("Key Pressed = ");
	writeln(key);
	if (key == GLFW_KEY_ESCAPE && action == GLFW_PRESS)
		glfwSetWindowShouldClose(window, GL_TRUE);
}



OpenGL Version 3.3 loaded
57

object.Error (0): Access Violation
----------------
0x00000001
Program exited with code 1
Jan 12 2016
next sibling parent reply Dav1d <d dav1d.de> writes:
On Tuesday, 12 January 2016 at 19:16:51 UTC, Jason Jeffory wrote:

 So, I finally got it to work by abandoning demios and static 
 linking. Derelict + dynamic linking worked with only about a 
 min of problems(copying the proper dll to the correct place). 
 I'd prefer static linking but I can deal with that later.


Yup, that's a little bit annoying on Windows (also as mentioned 
before the deimos bindings weren't updated in a while, might 
contribute to your issue).


 My current problem is: 1. The code doesn't work as expected: It 
 should show a type of triangle on the display, instead the 
 whole display is colored, probably user error as I cobbled 
 together some tutorial code. 2*. I get an access violation when 
 exiting the program. I have no idea how, why, or where this is 
 happening(except, obviously towards the end of the program... 
 probably a cleanup issue).


What does a debugger say? Where is it coming from?
Jan 12 2016
parent reply Jason Jeffory <JasonJeffory doodle.com> writes:
On Tuesday, 12 January 2016 at 20:48:37 UTC, Dav1d wrote:

 On Tuesday, 12 January 2016 at 19:16:51 UTC, Jason Jeffory 
 wrote:

 So, I finally got it to work by abandoning demios and static 
 linking. Derelict + dynamic linking worked with only about a 
 min of problems(copying the proper dll to the correct place). 
 I'd prefer static linking but I can deal with that later.


 Yup, that's a little bit annoying on Windows (also as mentioned 
 before the deimos bindings weren't updated in a while, might 
 contribute to your issue).


 My current problem is: 1. The code doesn't work as expected: 
 It should show a type of triangle on the display, instead the 
 whole display is colored, probably user error as I cobbled 
 together some tutorial code. 2*. I get an access violation 
 when exiting the program. I have no idea how, why, or where 
 this is happening(except, obviously towards the end of the 
 program... probably a cleanup issue).


 What does a debugger say? Where is it coming from?



It doesn't I put a break point on the glfwTerminate() and what 
visual studio/d shows is something in the "import 
derelict.glfw3.glfw3;" statement.


Well, a BP on on glfwTerminate is never reached. Hence it must be 
before that. The loop should work fine because it works already. 
One would think it is the while (!glfwWindowShouldClose(window)), 
but using just a global variable still causes the exception.

Hence the logical place the except should be occurring is

glfwPollEvents();

If I remove it and just use a counter and exit after while, then 
there is no exception. Hence, it must be glfwPollEvents();

But what can I do about that? Must be an issue with Derelict or 
glfw! Since Derelict is just bindings, it suggests glfw. But what 
possibly could be wrong?
Jan 12 2016
parent reply Dav1d <d dav1d.de> writes:
On Wednesday, 13 January 2016 at 06:30:44 UTC, Jason Jeffory 
wrote:

 On Tuesday, 12 January 2016 at 20:48:37 UTC, Dav1d wrote:

 On Tuesday, 12 January 2016 at 19:16:51 UTC, Jason Jeffory 
 wrote:

 [...]


 Yup, that's a little bit annoying on Windows (also as 
 mentioned before the deimos bindings weren't updated in a 
 while, might contribute to your issue).


[...]


 What does a debugger say? Where is it coming from?



 It doesn't I put a break point on the glfwTerminate() and what 
 visual studio/d shows is something in the "import 
 derelict.glfw3.glfw3;" statement.


 Well, a BP on on glfwTerminate is never reached. Hence it must 
 be before that. The loop should work fine because it works 
 already. One would think it is the while 
 (!glfwWindowShouldClose(window)), but using just a global 
 variable still causes the exception.

 Hence the logical place the except should be occurring is

 glfwPollEvents();

 If I remove it and just use a counter and exit after while, 
 then there is no exception. Hence, it must be glfwPollEvents();

 But what can I do about that? Must be an issue with Derelict or 
 glfw! Since Derelict is just bindings, it suggests glfw. But 
 what possibly could be wrong?


That's not correct.
Build a debug build and check the stacktrace which should be 
printed, if not open gdb or any other debugger and set a 
breakpoint on the exception. Iirc you can break on _d_throw and 
check the stacktrace, then you know where it actually is coming 
from.
Jan 13 2016
parent reply Jason Jeffory <JasonJeffory doodle.com> writes:
On Wednesday, 13 January 2016 at 16:04:32 UTC, Dav1d wrote:

 On Wednesday, 13 January 2016 at 06:30:44 UTC, Jason Jeffory 
 wrote:

 On Tuesday, 12 January 2016 at 20:48:37 UTC, Dav1d wrote:

 On Tuesday, 12 January 2016 at 19:16:51 UTC, Jason Jeffory 
 wrote:

 [...]


 Yup, that's a little bit annoying on Windows (also as 
 mentioned before the deimos bindings weren't updated in a 
 while, might contribute to your issue).


[...]


 What does a debugger say? Where is it coming from?



 It doesn't I put a break point on the glfwTerminate() and what 
 visual studio/d shows is something in the "import 
 derelict.glfw3.glfw3;" statement.


 Well, a BP on on glfwTerminate is never reached. Hence it must 
 be before that. The loop should work fine because it works 
 already. One would think it is the while 
 (!glfwWindowShouldClose(window)), but using just a global 
 variable still causes the exception.

 Hence the logical place the except should be occurring is

 glfwPollEvents();

 If I remove it and just use a counter and exit after while, 
 then there is no exception. Hence, it must be glfwPollEvents();

 But what can I do about that? Must be an issue with Derelict 
 or glfw! Since Derelict is just bindings, it suggests glfw. 
 But what possibly could be wrong?


 That's not correct.
 Build a debug build and check the stacktrace which should be 
 printed, if not open gdb or any other debugger and set a 
 breakpoint on the exception. Iirc you can break on _d_throw and 
 check the stacktrace, then you know where it actually is coming 
 from.


Either I don't get what you are talking about, or VS doesn't do 
what you think it does.

When I run the program, this is the stack trace. VS pops up with 
an "Exception has been thrown" window and it highlights the 
"import derelict.glfw3.glfw3;" line. I can't get any further than 
that. It is a debug build. But the except is not coming directly 
from the test.d code.

  	user32.dll!74d94790	
  	user32.dll!74d94527	
  	opengl32.dll!5946caa3	
  	user32.dll!74db4923	
  	user32.dll!74d94790	
  	user32.dll!74d94091	
  	user32.dll!74d93e50	
  	glfw3.dll!59525797	
  	glfw3.dll!5952792c	
  
	test.exe!_D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv() +
0x1b bytes	D
  	test.exe!_D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZv() + 
0x23 bytes	D
  	test.exe!__d_run_main() + 0x20c bytes	D

	test.exe!__entrypoint.main() Line 7 + 0x11 bytes	D


  	test.exe!_mainCRTStartup() + 0xa9 bytes	D


I'm not sure what you are expecting to happen. I can't step in to 
anything to see more detail and the lines that VS is showing 
where the problem is, is not steppable. It maybe a weird issue 
with VisualD. I will try gbd for windows, but have to install it 
and learn how to use it.
Jan 13 2016
parent reply Dav1d <d dav1d.de> writes:
On Wednesday, 13 January 2016 at 17:43:54 UTC, Jason Jeffory 
wrote:

 On Wednesday, 13 January 2016 at 16:04:32 UTC, Dav1d wrote:

 On Wednesday, 13 January 2016 at 06:30:44 UTC, Jason Jeffory 
 wrote:

 [...]


 That's not correct.
 Build a debug build and check the stacktrace which should be 
 printed, if not open gdb or any other debugger and set a 
 breakpoint on the exception. Iirc you can break on _d_throw 
 and check the stacktrace, then you know where it actually is 
 coming from.


 Either I don't get what you are talking about, or VS doesn't do 
 what you think it does.

 When I run the program, this is the stack trace. VS pops up 
 with an "Exception has been thrown" window and it highlights 
 the "import derelict.glfw3.glfw3;" line. I can't get any 
 further than that. It is a debug build. But the except is not 
 coming directly from the test.d code.

  	user32.dll!74d94790	
  	user32.dll!74d94527	
  	opengl32.dll!5946caa3	
  	user32.dll!74db4923	
  	user32.dll!74d94790	
  	user32.dll!74d94091	
  	user32.dll!74d93e50	
  	glfw3.dll!59525797	
  	glfw3.dll!5952792c	
  
 	test.exe!_D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv() +
0x1b bytes	D
  	test.exe!_D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZv() 
 + 0x23 bytes	D
  	test.exe!__d_run_main() + 0x20c bytes	D

	test.exe!__entrypoint.main() Line 7 + 0x11 bytes	D


  	test.exe!_mainCRTStartup() + 0xa9 bytes	D


 I'm not sure what you are expecting to happen. I can't step in 
 to anything to see more detail and the lines that VS is showing 
 where the problem is, is not steppable. It maybe a weird issue 
 with VisualD. I will try gbd for windows, but have to install 
 it and learn how to use it.


Yup that trace looks like a glfw issue not sure what causes it... 
that stacktrace on the other hand isn't really that helpful, it 
doesn't show what function call caused it only that it happens 
somewhere in glfw then possibly the driver.

I never used the VS debugger .. so no idea if you're doing it 
wrong or VS is simply not capable of debugging it.

Psudeo gdb session:


 r


/* crashes here */

 bt full


Or if an exception is thrown


 b _d_throw
 r
 bt full
Jan 13 2016
parent reply Jason Jeffory <JasonJeffory doodle.com> writes:
On Wednesday, 13 January 2016 at 18:40:39 UTC, Dav1d wrote:

 On Wednesday, 13 January 2016 at 17:43:54 UTC, Jason Jeffory 
 wrote:

 On Wednesday, 13 January 2016 at 16:04:32 UTC, Dav1d wrote:

 On Wednesday, 13 January 2016 at 06:30:44 UTC, Jason Jeffory 
 wrote:

 [...]


 That's not correct.
 Build a debug build and check the stacktrace which should be 
 printed, if not open gdb or any other debugger and set a 
 breakpoint on the exception. Iirc you can break on _d_throw 
 and check the stacktrace, then you know where it actually is 
 coming from.


 Either I don't get what you are talking about, or VS doesn't 
 do what you think it does.

 When I run the program, this is the stack trace. VS pops up 
 with an "Exception has been thrown" window and it highlights 
 the "import derelict.glfw3.glfw3;" line. I can't get any 
 further than that. It is a debug build. But the except is not 
 coming directly from the test.d code.

  	user32.dll!74d94790	
  	user32.dll!74d94527	
  	opengl32.dll!5946caa3	
  	user32.dll!74db4923	
  	user32.dll!74d94790	
  	user32.dll!74d94091	
  	user32.dll!74d93e50	
  	glfw3.dll!59525797	
  	glfw3.dll!5952792c	
  
 	test.exe!_D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv() +
0x1b bytes	D
  	test.exe!_D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZv() 
 + 0x23 bytes	D
  	test.exe!__d_run_main() + 0x20c bytes	D

	test.exe!__entrypoint.main() Line 7 + 0x11 bytes	D


  	test.exe!_mainCRTStartup() + 0xa9 bytes	D


 I'm not sure what you are expecting to happen. I can't step in 
 to anything to see more detail and the lines that VS is 
 showing where the problem is, is not steppable. It maybe a 
 weird issue with VisualD. I will try gbd for windows, but have 
 to install it and learn how to use it.


 Yup that trace looks like a glfw issue not sure what causes 
 it... that stacktrace on the other hand isn't really that 
 helpful, it doesn't show what function call caused it only that 
 it happens somewhere in glfw then possibly the driver.

 I never used the VS debugger .. so no idea if you're doing it 
 wrong or VS is simply not capable of debugging it.

 Psudeo gdb session:


 r


 /* crashes here */

 bt full


 Or if an exception is thrown


 b _d_throw
 r
 bt full





I don't know ;/ The SIGSEGV happens when I hit a key to exit the 
program.



This binary was built by Equation Solution 
<http://www.Equation.com>...
Reading symbols from test.exe...(no debugging symbols 
found)...done.
(gdb) r
Starting program: B:\Software\test\test.exe
[New Thread 8660.0x1310]
warning: `C:\Windows\SYSTEM32\ntdll.dll': Shared library 
architecture i386:x86-64 is not compatible with target 
architecture i386.
warning: `C:\Windows\system32\wow64.dll': Shared library 
architecture i386:x86-64 is not compatible with target 
architecture i386.
warning: `C:\Windows\system32\wow64win.dll': Shared library 
architecture i386:x86-64 is not compatible with target 
architecture i386.
warning: Could not load shared library symbols for 
WOW64_IMAGE_SECTION.
Do you need "set solib-search-path" or "set sysroot"?
warning: Could not load shared library symbols for 
WOW64_IMAGE_SECTION.
Do you need "set solib-search-path" or "set sysroot"?
warning: Could not load shared library symbols for NOT_AN_IMAGE.
Do you need "set solib-search-path" or "set sysroot"?
warning: Could not load shared library symbols for NOT_AN_IMAGE.
Do you need "set solib-search-path" or "set sysroot"?
warning: `C:\Windows\system32\wow64cpu.dll': Shared library 
architecture i386:x86-64 is not compatible with target 
architecture i386.
[New Thread 8660.0x1160]
[New Thread 8660.0xe00]
[New Thread 8660.0x2068]
[New Thread 8660.0xb58]
[New Thread 8660.0x231c]
[New Thread 8660.0x1b3c]
[New Thread 8660.0x21bc]
[Thread 8660.0xb58 exited with code 0]
[New Thread 8660.0x2488]
[Thread 8660.0x1b3c exited with code 0]
[New Thread 8660.0x27cc]
[New Thread 8660.0x237c]
[Thread 8660.0x237c exited with code 0]
[Thread 8660.0x27cc exited with code 0]
[New Thread 8660.0x2088]
[New Thread 8660.0x241c]
OpenGL Version 3.3 loaded
Key Pressed = 32 <------------------ I hit a key to exit and the 
SIGSEGV happens

Program received signal SIGSEGV, Segmentation fault.
0x0000002b in ?? ()
(gdb) bt full

No symbol table info available.
Cannot access memory at address 0x44
(gdb) b _d_throw
Function "_d_throw" not defined.
Make breakpoint pending on future shared library load? (y or [n]) 
y
Breakpoint 1 (_d_throw) pending.
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: B:\Software\test\test.exe
[New Thread 8408.0x1a5c]
warning: `C:\Windows\SYSTEM32\ntdll.dll': Shared library 
architecture i386:x86-64 is not compatible with target 
architecture i386.
warning: `C:\Windows\system32\wow64.dll': Shared library 
architecture i386:x86-64 is not compatible with target 
architecture i386.
warning: `C:\Windows\system32\wow64win.dll': Shared library 
architecture i386:x86-64 is not compatible with target 
architecture i386.
warning: Could not load shared library symbols for 
WOW64_IMAGE_SECTION.
Do you need "set solib-search-path" or "set sysroot"?
warning: Could not load shared library symbols for 
WOW64_IMAGE_SECTION.
Do you need "set solib-search-path" or "set sysroot"?
warning: Could not load shared library symbols for NOT_AN_IMAGE.
Do you need "set solib-search-path" or "set sysroot"?
warning: Could not load shared library symbols for NOT_AN_IMAGE.
Do you need "set solib-search-path" or "set sysroot"?
warning: `C:\Windows\system32\wow64cpu.dll': Shared library 
architecture i386:x86-64 is not compatible with target 
architecture i386.
[New Thread 8408.0x1cb8]
[New Thread 8408.0x2454]
[New Thread 8408.0x268c]
[New Thread 8408.0x164]
[New Thread 8408.0x2150]
[New Thread 8408.0x2398]
[Thread 8408.0x2398 exited with code 0]
[New Thread 8408.0x2314]
[New Thread 8408.0x1ff8]
[Thread 8408.0x164 exited with code 0]
[New Thread 8408.0x238]
[New Thread 8408.0x2190]
[Thread 8408.0x2314 exited with code 0]
[Thread 8408.0x1ff8 exited with code 0]
[New Thread 8408.0x27ac]
[New Thread 8408.0x22a4]
OpenGL Version 3.3 loaded
Key Pressed = 36

Program received signal SIGSEGV, Segmentation fault.
0x0000002b in ?? ()
(gdb) bt full

No symbol table info available.
Cannot access memory at address 0x4a
(gdb)




I tried some online walkthrough's and I'd get the same issue... 
basically `in ??`, which I have no idea what it means and it is 
not informative. I can put a try/catch and catch the exception to 
avoid the error... obviously not an ideal solution.
Jan 13 2016
parent reply Jason Jeffory <JasonJeffory doodle.com> writes:
What I can't seem to figure out why

try { loop }
catch
{

}

catches the exception but

try { loop }
catch (Throwable t) // Only diff
{

}

doesn't ;/ Probably my ignorance about D, but I was hoping to get 
some info about the exception this way(line number, etc...)
Jan 13 2016
parent reply Dav1d <d dav1d.de> writes:
On Wednesday, 13 January 2016 at 19:20:40 UTC, Jason Jeffory 
wrote:

 What I can't seem to figure out why

 try { loop }
 catch
 {

 }

 catches the exception but

 try { loop }
 catch (Throwable t) // Only diff
 {

 }

 doesn't ;/ Probably my ignorance about D, but I was hoping to 
 get some info about the exception this way(line number, etc...)


This is not an exception you should catch at all. Also pretty 
sure this wont work with 64bit binaries.
D does realize a segmentation fault, access to invalid memory, 
that's nothing a program should simply catch and then silently 
ignore, the issue causing it needs to be addressed.

Also why doesn't your key_callback not to be extern(C), I thought 
that was required.

'Reading symbols from test.exe...(no debugging symbols 
found)...done.', you arent gonna get any useful information 
without debug symbols. Also additionally use a glfw debug build.
Jan 13 2016
parent reply Jason Jeffory <JasonJeffory doodle.com> writes:
On Wednesday, 13 January 2016 at 20:13:49 UTC, Dav1d wrote:

 On Wednesday, 13 January 2016 at 19:20:40 UTC, Jason Jeffory 
 wrote:

 What I can't seem to figure out why

 try { loop }
 catch
 {

 }

 catches the exception but

 try { loop }
 catch (Throwable t) // Only diff
 {

 }

 doesn't ;/ Probably my ignorance about D, but I was hoping to 
 get some info about the exception this way(line number, etc...)


 This is not an exception you should catch at all. Also pretty 
 sure this wont work with 64bit binaries.
 D does realize a segmentation fault, access to invalid memory, 
 that's nothing a program should simply catch and then silently 
 ignore, the issue causing it needs to be addressed.


It was for testing purposes and to try and figure out what is 
going on.


 Also why doesn't your key_callback not to be extern(C), I 
 thought that was required.


The app never exits with extern(C), it doesn't crash though.


 'Reading symbols from test.exe...(no debugging symbols 
 found)...done.', you arent gonna get any useful information 
 without debug symbols. Also additionally use a glfw debug build.


Why aren't the debug symbols added in a debug build? Makes no 
sense!

I don't have a debug build of glfw.

...

After an few hours of fucking with cmake, turns out it had a bug. 
Updated it and worked. Pretty much through with this crap. I'm 
not going to waste any more time screwing with the dysfunctional 
approach that software design is taking. I appreciate your help. 
See you on the flip side! Have fun crawling through the sewers of 
"modern" programming!
Jan 13 2016
parent Dav1d <d dav1d.de> writes:
On Wednesday, 13 January 2016 at 22:51:45 UTC, Jason Jeffory 
wrote:

 After an few hours of fucking with cmake, turns out it had a 
 bug. Updated it and worked. Pretty much through with this crap. 
 I'm not going to waste any more time screwing with the 
 dysfunctional approach that software design is taking. I 
 appreciate your help. See you on the flip side! Have fun 
 crawling through the sewers of "modern" programming!


Welcome to Windows
Jan 13 2016
prev sibling parent Mike Parker <aldacron gmail.com> writes:
On Tuesday, 12 January 2016 at 19:16:51 UTC, Jason Jeffory wrote:

 So, I finally got it to work by abandoning demios and static 
 linking. Derelict + dynamic linking worked with only about a 
 min of problems(copying the proper dll to the correct place).


Every operating system has a well-defined search path for dynamic 
libraries. On Windows, the first location searched is the 
directory in which the executable resides. That's usually the 
simplest place to put it. When working with dub, I usually set a 
targetPath directive to "bin" in the configuration, so my project 
tree looks something like this:

- project
--bin
--source
--dub.sdl

Then I dump all of the DLLs I need in the bin directory. On other 
platforms, it's customary for libraries to be installed in 
standard system paths,  but on windows all but "system" libraries 
(such as the Win32 libs and OpenGL) are usually shipped with the 
app.

Derelict allows you to specify the path to the libraries you need 
to load. So you can, for example, put your glfw3.dll in a 
subdirectory off of the bin directory, or change the name. Then 
you would load it, for example, like so:

DerelictGLFW3.load("dlls/glfw3_32.dll");

In this case, it doesn't matter which compiler or linker was used 
to build the DLL. It could have been built with GCC, VC, or DMC.  
The COFF/OMF issue disappears here.
Jan 12 2016
prev sibling next sibling parent Dav1d <d dav1d.de> writes:
On Monday, 11 January 2016 at 00:46:38 UTC, Jason Jeffory wrote:

 On Sunday, 10 January 2016 at 23:14:33 UTC, Dav1d wrote:

 [...]


 OK, I'll give it a try. What about GLUT and WGL? Whats the 
 difference between them all and glfw? Are all these just OS 
 helpers to reduce the boilerplate code?

 Also, how hard would it be to support cgl? (mac bindings)

 Thanks!


GLUT ist dead and WGL is the windows API which you could use but 
is relativly low level. glfw is a cross platform toolkit (kinda 
like GLUT) which takes care of WGL (and other platforms) and 
gives you a nice API.
Jan 11 2016
prev sibling parent ParticlePeter <ParticlePeter gmx.de> writes:
On Monday, 11 January 2016 at 00:46:38 UTC, Jason Jeffory wrote:
...

 OK, I'll give it a try. What about GLUT and WGL? Whats the 
 difference between them all and glfw? Are all these just OS 
 helpers to reduce the boilerplate code?


These kind of questions are best clarified on the OpenGL wiki.
https://www.opengl.org/wiki/Main_Page

Especially these (Glad is explained there as well):
https://www.opengl.org/wiki/Getting_Started
https://www.opengl.org/wiki/OpenGL_Loading_Library
https://www.opengl.org/wiki/Related_toolkits_and_APIs
Jan 12 2016
prev sibling parent rsw0x <anonymous anonymous.com> writes:
On Sunday, 10 January 2016 at 21:30:32 UTC, Jason Jeffory wrote:

 Seems like it is a very nice way to get into openGL from D.

 http://glad.dav1d.de/

 I generated the bindings for all the latest versions of the 
 various specifications.
 Does anyone have any tutorials that use this library 
 effectively?

 There's this

 https://github.com/Dav1dde/glamour

 But not sure what it is(diff between it and glad). Says it's a 
 wrapper to OpenGL... but does it use the glad generated 
 bindings?

 It looks like I'd prefer this to derelict because it seems like 
 it is a automatically generated binding... which means future 
 extensibility and no "extra" stuff.

 Would be nice if it works with dub. How could I use it easily 
 with dub as a local library? (create a dependency from a local 
 file location)

 Thanks.


I preferred glad over derelict when I did some opengl work with D 
because it was easier to just include only the functions I 
wanted. Derelict made much bigger binaries, not sure how much in 
part that was to the whole kitchen sink approach or the derelict 
utility itself.

However, both are great and work fine. Their analogues in C/C++ 
would be function pointer loaders like glew for derelict or 
opengl binding generators like glLoadGen(and glad, it's 
multi-language — I actually preferred it for C++ too) for glad.
Bye.
Jan 10 2016