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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 #0 0x0000002b in ?? () 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 #0 0x0000002b in ?? () 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
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
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
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
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
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
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
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
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