GLEW_VERSION_2_0 and others all seem to be 0

[devel-chm]

I think something is missing. These routines do appear to be defined so you can get the values with no undefined sub messages. The values seem to always be zero. This makes it difficult to check for OpenGL functionality. This is for OpenGL::Modern 0.02

[wchristian]

At a guess: Their value is captured before createcontext, so glew can't actually tell you what the GL version is?

[devel-chm]

I haven't had time to look at the code, but could it be the inlineable sub constants modification? The AUTOLOAD code seems reasonable and since it happens at runtime, it should pick up the actual values. As the OpenGL constants are all determined by the specification, generating them from the spec ahead of time should be fine.

…

On Tue, Feb 14, 2017 at 8:23 AM, Christian Walde (Mithaldu) < ***@***.***> wrote: At a guess: Their value is captured before createcontext, so glew can't actually tell you what the GL version is? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#38 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAwNefdnZiuheXregws_YBX7obcgpbV7ks5rcarVgaJpZM4MAYme> .

[wchristian]

Those constants are not generated from spec. They are set in glewContextInit in https://raw.githubusercontent.com/devel-chm/OpenGL-Modern/master/src/glew.c

GLEW_VERSION_2_0   = GLEW_VERSION_2_1   == GL_TRUE || ( major == 2               ) ? GL_TRUE : GL_FALSE;

and are otherwise defaulted to false:

GLboolean __GLEW_VERSION_2_0 = GL_FALSE;

So reading them before a context is initiated should be an error.

[devel-chm]

I was referring to the OpenGL constants, GL_* not the GLEW constants, GLEW_*
The OpenGL constants are set by the specification whether or not a system supports any specific functionality.

[wchristian]

Oh, might want to edit that title then. :)

[wchristian]

Or be a little more specific as to what code you consider to be broken, because on rereading this i'm confused as to what you're saying.

C:\Users\Mithaldu>perl -E "use strict; use warnings; use OpenGL::Modern ':all'; say 'v'.GL_VERSION_2_0()"
v1

C:\Users\Mithaldu>perl -E "use strict; use warnings; use OpenGL::Modern ':all'; say 'v'.GL_VERSION_4_5()"
v1

[devel-chm]

The missing/incorrect ones are GLEW_VERSION_M_N which are the ones to check if a particular OpenGL version is available.

[wchristian]

Alright, then these should, for all practical purposes, NEVER be constants. This is due to them being set at the time a context is created, which means even if their value is fetched late, it can change if the process switches to rendering on a different graphics card. (Which might not be that uncommon, even my 4 year old laptop has two.)

[devel-chm]

I think they will work if they were to use the AUTOLOAD implementation to have them defined post-glewInit. There are other issues with the current bindings that would need to be addressed to handle multiple contexts and the situations that might come up with features available.

[wchristian]

AUTOLOAD would still preclude changing their values at a later point.

[devel-chm]

On Fri, Feb 17, 2017 at 9:25 AM, Christian Walde (Mithaldu) < ***@***.***> wrote: AUTOLOAD would still preclude changing their values at a later point.

No, it wouldn't. In the eventuality that we need that capability, then a new call to glewInit could clear or replace the existing values.

[wchristian]

By what mechanism would you change them?

[devel-chm]

My current plan is to just have XS routines that return the value of the GLEW parameter values.
generate-XS.pl ignores those at the moment. It shouldn't be hard to add this to the code. I'll keep you posted.

[wchristian]

Haha, alright, that sounds perfectly fine. :)

…

On Fri, Feb 17, 2017, 20:32 devel-chm ***@***.***> wrote: My current plan is to just have XS routines that return the value of the GLEW parameter values. generate-XS.pl ignores those at the moment. It shouldn't be hard to add this to the code. I'll keep you posted. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#38 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAKtazT_DZHIAbQSRDjD9Wj4Znb9JnbRks5rdfXAgaJpZM4MAYme> .

[devel-chm]

The implementation is complete. Please follow up with any further problems in issue #46, thanks.