Re: Glad and WGL
On Thursday, 14 January 2016 at 02:35:28 UTC, Josh Phillips wrote: On Wednesday, 13 January 2016 at 20:08:55 UTC, Dav1d wrote: Link with opengl32.lib How? Everywhere I looked it says this cannot be done due to conflicting formats between the dmd compiler and the windows one. Welcome to D and Windows. You can use GDC or LDC or try http://wiki.dlang.org/Installing_DMD_on_64-bit_Windows_7_(COFF-compatible) Or you find an OMF opengl32.lib OR you make your own with implib and coff2omf http://www.digitalmars.com/ctg/implib.html http://www.digitalmars.com/ctg/coff2omf.html I dont really remember how that worked.
Re: Glad and WGL
On Thursday, 14 January 2016 at 09:25:50 UTC, Dav1d wrote: On Thursday, 14 January 2016 at 02:35:28 UTC, Josh Phillips wrote: On Wednesday, 13 January 2016 at 20:08:55 UTC, Dav1d wrote: Link with opengl32.lib How? Everywhere I looked it says this cannot be done due to conflicting formats between the dmd compiler and the windows one. Welcome to D and Windows. You can use GDC or LDC or try http://wiki.dlang.org/Installing_DMD_on_64-bit_Windows_7_(COFF-compatible) Or you find an OMF opengl32.lib OR you make your own with implib and coff2omf http://www.digitalmars.com/ctg/implib.html http://www.digitalmars.com/ctg/coff2omf.html I dont really remember how that worked. There is also objconv: http://www.agner.org/optimize/ I found in an older code: echo "implib /s opengl32.lib opengl32.dll && exit" | cmd So maybe `implib /s opengl32.lib opengl32.dll` is enough. Would like to help you more, but I didnt need to deal with this shit lately (luckily) and forgot most of this mess.
Re: Anyone using glad?
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: Glad and WGL
On Wednesday, 13 January 2016 at 18:34:14 UTC, Josh Phillips
wrote:
So I started using Glad but I can't get WGL to work with it,
though I think this is more of a Win32 issue than WGL.
wndclass.lpfnWndProc =
Gives me an error no matter what:
Error: cannot implicitly convert expression (& WndProc) of type
int function(void* hWnd, uint message, uint wParam, int lParam)
to extern (Windows) int function(void*, uint, uint, int) nothrow
I think the error has to do with the nothrow but I tried making
the function empty
extern(Windows)
LRESULT WndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM
lParam)
{
return 0;
}
And still got the same exact error. Any ideas/help?
Your function isnt marked nothrow.
Re: Anyone using glad?
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: Glad and WGL
On Wednesday, 13 January 2016 at 19:05:30 UTC, Josh Phillips wrote: On Wednesday, 13 January 2016 at 18:37:09 UTC, Adam D. Ruppe wrote: [...] Oh wow that's easy. They should really make that more clear in the dlang reference. They way it sounds there made me think that if a function doesn't throw any errors it automatically is 'nothrow' [...] Link with opengl32.lib
Re: Output range of ranges to single buffer
On Wednesday, 13 January 2016 at 21:15:03 UTC, Jacob Carlborg
wrote:
Is it possible to somehow output a range of ranges to a single
string buffer? For example, converting an array of integers to
a string with the same representation as the source code.
[...]
std.format can do it. From the site:
import std.stdio;
void main()
{
writefln("My items are %(%s %).", [1,2,3]);
writefln("My items are %(%s, %).", [1,2,3]);
}
Re: Anyone using glad?
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?
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?
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?
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?
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?
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: issue porting C++/glm/openGL to D/gl3n/openGL
On Sunday, 10 January 2016 at 05:47:01 UTC, WhatMeWorry wrote: On Sunday, 10 January 2016 at 04:37:43 UTC, Mike Parker wrote: On Sunday, 10 January 2016 at 02:51:57 UTC, WhatMeWorry wrote: Is gl3n not a direct replacement for glm? From the very top of the gl3n github page: "OpenGL Maths for D (not glm for D)." So, no, it is not. You might want to start with the glm documentaion [1]. [1] http://dav1dde.github.io/gl3n/ Thanks. Bummer. I really like gl3n, but glm/opengl is used almost exclusively in all the modern opengl code (tutorials) I've seen, so this might be a deal breaker. As the author of Derelict do you have any ideas of how much work is involved with getting glm to work with D? Want to do a DerelictGLM :) I bought your excellent book as a xmas present for myself so looks like I'll be reading chapter 9. gl3n has most features of GLM just the syntax is different and a few other things. gl3n then operates on row-major matrices only (Extrawurst wanted to work on a column-major version), which isn't a big issue for your usual GL, you just need to tell OpenGL that it is in row-major format when uploading it. iirc GLM is a header only library so you can't simply interface it from D you would need to port every function, that's what I basically did in gl3n only that I started from scratch and made my own API etc. So you can use gl3n as a glm replacement it just has a different syntax and a few semantics are different. --- Regarding some functions not showing up on the website, that's because the ddoc generator doesn't want to go into some static if() or version() blocks. A known bug.
Re: Anyone using glad?
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?
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).
Re: why adding extern(C) cause a runtime error?
On Saturday, 11 July 2015 at 01:22:14 UTC, mzf wrote:
win7 x86 dmd2.067.1 ok
ubuntu x64 dmd2.067.1 error
-
import std.stdio;
import std.socket;
extern(C)
void recv()
{
writeln(recv...);
}
extern(C)
void send()
{
writeln(send...);
}
int main(string[] argv)
{
//copy from std.socket unittest
immutable ubyte[] data = [1, 2, 3, 4];
auto pair = socketPair();
scope(exit) foreach (s; pair) s.close();
pair[0].send(data);
auto buf = new ubyte[data.length];
pair[1].receive(buf);
assert(buf == data);
return 0;
}
--
send...
recv...
core.exception.AssertError@a.d(27): Assertion failure
./a() [0x43d61f]
./a(_Dmain+0xcc) [0x43d1bc]
./a(_D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv+0x1f)
[0x4400fb]
./a(void rt.dmain2._d_run_main(int, char**, extern (C) int
function(char[][])*).tryExec(scope void delegate())+0x2a)
[0x44004e]
./a(void rt.dmain2._d_run_main(int, char**, extern (C) int
function(char[][])*).runAll()+0x30) [0x4400b4]
./a(void rt.dmain2._d_run_main(int, char**, extern (C) int
function(char[][])*).tryExec(scope void delegate())+0x2a)
[0x44004e]
./a(_d_run_main+0x1dc) [0x43ffc8]
./a(main+0x17) [0x43d637]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)
[0x7f5fabd8fec5]
You basically overwrite the C send(2) and recv(2) functions
with your code (the actual symbols, the linker will yours instead
the real ones). So std.socket doesn't call the C functions but
yours. Yours obviously don't send and receive data. If you really
want to overwrite these functions you might be able to call the
original ones via dlsym.
