www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Configuring DerelictGL3

reply Entity325 <lonewolf325 gmail.com> writes:
Updating my dev environment to the latest version of DMD, which 
means I updated to the latest versions of all of the Derelict 
libraries I use. Everything seems to be mostly in order(changed 
all the old references to "import derelict.opengl3.gl" to "import 
derelict.opengl"), except I'm getting a bunch of missing 
references that I can't for the life of me figure out what I'm 
doing wrong.

||=== Build: testbench in Materium D (compiler: Digital Mars D 
Compiler) ===|
materium\core\display.d|366|Error: undefined identifier 
`glTranslatef`|
materium\core\display.d|371|Error: undefined identifier 
`glEnableClientState`|
materium\core\display.d|376|Error: undefined identifier 
`glEnableClientState`|
materium\core\display.d|452|Error: undefined identifier 
`glDisableClientState`|
materium\core\display.d|455|Error: undefined identifier 
`glDisableClientState`|
materium\core\display.d|517|Error: undefined identifier 
`glShadeModel`|
materium\core\display.d|1379|Error: undefined identifier 
`glMatrixMode`|
materium\core\display.d|1380|Error: undefined identifier 
`glLoadIdentity`|
materium\core\display.d|1390|Error: undefined identifier 
`glOrtho`|
materium\core\display.d|1404|Error: undefined identifier 
`glFrustum`|
materium\core\display.d|1410|Error: undefined identifier 
`glMatrixMode`|
materium\core\display.d|1411|Error: undefined identifier 
`glLoadIdentity`|
||=== Build failed: 12 error(s), 0 warning(s) (0 minute(s), 3 
second(s)) ===|

I've been searching for about a day and I thought I might be 
trying to use deprecated functionality, but attempting to load 
the deprecated functions according to the documentation page did 
a whole lot of nothing, and I can't imagine things like 
"glEnable/DisableClientState" are deprecated.

I'm in the middle of adding shader support to the project I'm 
working on, finally bringing it out of the OpenGL 1.1-era dark 
ages and into the present day, but otherwise everything was 
working pretty well before the update.
Jun 06 2018
parent reply Rene Zwanenburg <renezwanenburg gmail.com> writes:
On Wednesday, 6 June 2018 at 23:26:23 UTC, Entity325 wrote:

 I can't imagine things like "glEnable/DisableClientState" are 
 deprecated.


They are. All the missing symbols are indeed deprecated.


 attempting to load the deprecated functions according to the 
 documentation page did a whole lot of nothing


Could you post the exact code you used? I'm not using the old 
functions, but that should work.
Jun 06 2018
parent reply Entity325 <lonewolf325 gmail.com> writes:
On Wednesday, 6 June 2018 at 23:43:34 UTC, Rene Zwanenburg wrote:

 On Wednesday, 6 June 2018 at 23:26:23 UTC, Entity325 wrote:

 I can't imagine things like "glEnable/DisableClientState" are 
 deprecated.


 They are. All the missing symbols are indeed deprecated.


Oh, I see where my confusion came from. I was getting 
glEnableClientState confused with glVertexAttribArray, and 
assumed glShadeModel was relevant to shaders, and not just to the 
built-in lighting model used.

...It's been a while since I touched this code.


 attempting to load the deprecated functions according to the 
 documentation page did a whole lot of nothing


 Could you post the exact code you used? I'm not using the old 
 functions, but that should work.


The actual source file all those calls are made in weighs in at 
over 1000 lines, and is mostly not related to the problem I'm 
having here.

Anyway.

I added the line, "mixin glContext!(GLVersion.gl33);" after the 
import statement. I didn't do anything with the context because I 
assumed SDL2 handled that, and creating my own would likely break 
the code.

I'll work a bit with the testing project I put together (which is 
a little easier to experiment on than a 1000+ line fully featured 
display module created by a madman) and report back on my results.
Jun 06 2018
parent reply Mike Parker <aldacron gmail.com> writes:
On Thursday, 7 June 2018 at 02:47:12 UTC, Entity325 wrote:



 I added the line, "mixin glContext!(GLVersion.gl33);" after the 
 import statement. I didn't do anything with the context because 
 I assumed SDL2 handled that, and creating my own would likely 
 break the code.


You aren't mixing in the deprecated symbols. From the 
documentation [1]:

"glFreeFuncs takes an optional paramter that will include 
deprecated types and function pointer declarations. This is false 
by default, but can be enabled with, e.g., mixin 
glFreeFuncs(GLVersion.gl33, true);."

So step-by-step:

1. Set version=DerelictGL3_CustomFreeFuncs on the command line 
(via dub's "versions" directive).

2. Create a module specifically for importing DerelictGL, e.g. 
mygl.d, and add this:

module mygl;
public import derelict.opengl;
mixin glFreeFuncs!(GLVersion.gl33, true);

3. In any  module where you need opengl, import mygl instead of 
derelict.opengl.

With this, Derelict will attempt to load all OpenGL functions, 
including the deprecated ones, up to 3.3. You'll just need to 
make sure you have the proper context created to support them.

FYI, I'm working on a new bindings package that's  nogc and 
-betterC comaptible (Derelict being neither). I've taken a 
completely different approach there, making everything 
configurable via commandline versions. For anyone interested in 
seeing what it looks like, I set up a github group a while back 
and have the loader package and the SDL bindings up now (though 
not yet in the dub repository). I've got most of OpenGL and GLFW 
done and will upload them in the not-too-distant future, to be 
followed by ports of other commonly-used Derelict packages. I'll 
push everything to the dub repo when I'm ready to formally make 
the announcement. It's best to consider the Derelict packages in 
maintenance mode, though I plan to keep supporting them for a 
long while to come.

[1]: http://derelictorg.github.io/packages/gl3/#using-derelictgl3
[2]: https://github.com/BindBC



 Jun 06 2018



  parent reply Entity325 <lonewolf325 gmail.com>  writes:


Thanks for the help (and sorry for the slow reply, it took longer 
to get everything tested and configured than I would have 
liked... sorry if this is frowned upon on this forum...)

I do have an odd bug, however, and I'm not sure how to go any 
further with it.

So I'm using the standard process:
DerelictGL3.load();
glContext = SDL_GL_CreateContext(sdlWindow);
GLVersion glVersion = DerelictGL3.reload();

About 1/3 of the time, the program hangs on the 3rd line and 
never gets past it.

Currently tracking whether admittedly odd things I'm doing with 
threads might be the culprit. I have a growing suspicion they 
might be.

Looking forward to the BindBC release. I assume it's more or less 
intended to be a drop-in replacement for Derelict, with normal 
allowances for version-to-version updating, but more stable.



 Jul 18 2018



  parent reply Mike Parker <aldacron gmail.com>  writes:


On Thursday, 19 July 2018 at 00:27:58 UTC, Entity325 wrote:


 So I'm using the standard process:
 DerelictGL3.load();
 glContext = SDL_GL_CreateContext(sdlWindow);
 GLVersion glVersion = DerelictGL3.reload();

 About 1/3 of the time, the program hangs on the 3rd line and 
 never gets past it.

 Currently tracking whether admittedly odd things I'm doing with 
 threads might be the culprit. I have a growing suspicion they 
 might be.


Are you doing all of that in the main thread, or a separate one?


 Looking forward to the BindBC release. I assume it's more or 
 less intended to be a drop-in replacement for Derelict, with 
 normal allowances for version-to-version updating, but more 
 stable.


The loader is not a drop-in replacement. Different function 
names, different error-handling mechanism, different compile-time 
configuration. And it has nothing to do with stability. The 
Derelict packages are quite stable. The whole point of BindBC is 
to make the loader fully  nogc and -betterC compatible while 
simultaneously making maintenance more sensible than what 
Derelict evolved into.



 Jul 19 2018



  parent  Entity325 <lonewolf325 gmail.com>  writes:


On Thursday, 19 July 2018 at 09:41:34 UTC, Mike Parker wrote:


 Are you doing all of that in the main thread, or a separate one?


It's all on a separate thread, but I checked every single 
reference I could find after posting yesterday, and the OGL 
context is never referenced outside of the thread which created 
it(I actually remember jumping through several hoops when 
building my display handler to ensure this). The problem hadn't 
cropped up before updating to the latest versions of DMD and 
Derelict, even when spawning 3 separate contexts for 3 separate 
windows when I was initially testing. (which wouldn't be causing 
the problem this time around either, since I'm only working with 
one window right now)



 Jul 19 2018