Re: Anyone using glad?

[Jason Jeffory via Digitalmars-d-learn]

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 bytesD

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 
...
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.
0x002b in ?? ()
(gdb) bt full
#0  0x002b 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: 

Re: Anyone using glad?

[Dav1d via Digitalmars-d-learn]

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.

Re: Anyone using glad?

[Dav1d via Digitalmars-d-learn]

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 bytesD

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

Re: Anyone using glad?

[Jason Jeffory via Digitalmars-d-learn]

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...)

Re: Anyone using glad?

[Jason Jeffory via Digitalmars-d-learn]

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!

Re: Anyone using glad?

[Dav1d via Digitalmars-d-learn]

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

Re: Anyone using glad?

[Dav1d via Digitalmars-d-learn]

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.

Re: Anyone using glad?

[Jason Jeffory via Digitalmars-d-learn]

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 bytesD

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.

Re: Anyone using glad?

[Jason Jeffory via Digitalmars-d-learn]

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?

Re: Anyone using glad?

[Jason Jeffory via Digitalmars-d-learn]

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)_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, );
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, );
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, , null);
glCompileShader(vsh);
glAttachShader(program, vsh);
// Fragment Shader
auto fsh = glCreateShader(GL_FRAGMENT_SHADER);
auto fshSrc = minimalFragmentShader.toStringz;
glShaderSource(fsh, 1, , 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)
  

Re: Anyone using glad?

[Dav1d via Digitalmars-d-learn]

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?

Re: Anyone using glad?

[ParticlePeter via Digitalmars-d-learn]

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

Re: Anyone using glad?

[Mike Parker via Digitalmars-d-learn]

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.

Re: Anyone using glad?

[Dav1d via Digitalmars-d-learn]

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.

Re: Anyone using glad?

[Dav1d via Digitalmars-d-learn]

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!

Re: Anyone using glad?

[Dav1d via Digitalmars-d-learn]

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.

Re: Anyone using glad?

[Jason Jeffory via Digitalmars-d-learn]

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?

Re: Anyone using glad?

[Jason Jeffory via Digitalmars-d-learn]

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, _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)_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, _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);
}

Anyone using glad?

[Jason Jeffory via Digitalmars-d-learn]

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.

Re: Anyone using glad?

[Jason Jeffory via Digitalmars-d-learn]

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).

Re: Anyone using glad?

[rsw0x via Digitalmars-d-learn]

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.

Re: Anyone using glad?

[Jason Jeffory via Digitalmars-d-learn]

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!

Re: Anyone using glad?

[Dav1d via Digitalmars-d-learn]

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!

Re: Anyone using glad?

[Dav1d via Digitalmars-d-learn]

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).