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.

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.

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.

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

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.

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.

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)