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.

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

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

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?

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.

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?

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.

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.

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

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.