Problem Initializing vertex array

[rogermc2]

I declare Vertex_Array : GL.Objects.Vertex_Arrays.Vertex_Array_Object;

then either GL.Objects.Vertex_Arrays.Initialize_Id(Vertex_Array); or Vertex_Array.Initialize_Id;

Project builds OK but running produces constraint error: raised CONSTRAINT_ERROR : erroneous memory access

I have no problems with GL.Objects.Buffers.Buffer variables which initialize_id, bind and run without error.

Context is: type tWindow is new Glfw.Windows.Window with null record; Main_Window : aliased tWindow; Main_Window_Access : access tWindow := Main_Window'Access;

Main_Window.Init(Window_Width, Window_Height, "HelloTriangle"); glfw.Windows.Context.Make_Current(Main_Window_Access);

What am I doing wrong? Regards, Roger

[flyx]

Does GL_Test.OpenGL3 (from the tests dir) work for you? Do you call Glfw.Init? I do not see any obvious error in the code lines you pasted. You may want to produce a minimal verifyable example.

[rogermc2]

I built gl_test-opengl3 but it failed with:

/Ada_Source/OpenGLAda-master/tests/gl_test-opengl3 Initialized GLFW window

raised CONSTRAINT_ERROR : erroneous memory access [2016-11-21 11:30:56] process exited with status 1, elapsed time: 02.94s

I'll prepare a minimal verifyable example. Thanks, Roger

[rogermc2]

Minimal verifyable example:

vertex_array_test.adb.txt

[rogermc2]

Some warnings that occurred: glfw-api.ads:327:39: warning: "Set_Window_User_Pointer.Pointer" involves a tagged type which does not correspond to any C type glfw-api.ads:331:13: warning: return type of "Get_Window_User_Pointer" does not correspond to C type

[rogermc2]

Debugger produced: Program received signal SIGSEGV, Segmentation fault. 0x0000000100023786 in gl.api.gen_vertex_arrays (param1=1, value=0) at /Ada_Source/OpenGLAda-master/src/gl/implementation/gl-runtime_loading.adb:429

Call stack: gl.api.gen_vertex_arrays gl.objects.vertex_arrays.initialize_id vertex_array_test

[flyx]

Well, if the OpenGL 3 test fails, that indicates either a problem with your environment or an incompatibility of OpenGLAda with your environment. Can you give details about your OS, compiler, and OpenGL implementation?

[flyx]

I dug up this article: link

It seems like the implementation of glXGetProcAddress violates the spec because it may return a non-null pointer even if a function is not available. If that is the case, OpenGLAda will assume that the function exists and call it, which leads to the error you get.

So your problem is that your OpenGL implementation does not provide vertex arrays. And OpenGLAda does not recognize this because of a non-conforming glXGetProcAddress implementation (if it did, it would simply raise a Feature_Not_Supported_Exception). There's no workaround other than updating your OpenGL implementation if possible, or not using this feature.

[rogermc2]

My system is: OSX 10.11.6 XCode 8.0 GNAT GPL 2016 (20160515-49) Copyright (C) 1996-2016, Free Software Foundation, Inc. glfw3-3.2.1

Using GL.Context: OpenGL version supported: 3. 3 Renderer: Intel HD Graphics 3000 OpenGL Engine Primary_Shading_Language_Version: 3.30

I understand that my "OpenGL implementation" is an Apple implementation. I'll look into Apple's OpenGL documentation and also the link that you provided to try and figure out if there's a way around the problem. Thanks for your explanation which clearly explains the problem. Roger

[flyx]

The OpenGL 3 test should definitely work on OSX, I developed it there. Important for OSX is to explicitly specify the desired OpenGL version of your context before initializing the window:

Glfw.Windows.Hints.Set_Minimum_OpenGL_Version (Major => 3, Minor => 2);
Glfw.Windows.Hints.Set_Forward_Compat (True);
Glfw.Windows.Hints.Set_Profile (Glfw.Windows.Context.Core_Profile);

The test does that. I will check later on my Mac whether the OpenGL 3 test is broken for OSX.

[rogermc2]

I tried including

Glfw.Windows.Hints.Set_Minimum_OpenGL_Version (Major => 3, Minor => 2);
Glfw.Windows.Hints.Set_Forward_Compat (True);
Glfw.Windows.Hints.Set_Profile (Glfw.Windows.Context.Core_Profile);

in my minimal example but it still raised CONSTRAINT_ERROR : erroneous memory access

I'm wondering if my OpenGL environment is somehow messed up?

[flyx]

You can try querying the actual context version with GL.Context.Major_Version and GL.Context.Minor_Version (they will fail if you did not get a context >= 3.x) after initializing the window. For me, it looks like OSX does deliver an old OpenGL 2 context to you (in which case GL.Context.Version_String should work).

Note that the article I linked does not apply to OSX since that does not use glXGetProcAddress – it uses CFBundleGetFunctionPointerForName instead and so it seems strange that you get that error. Did you correctly set -XWindowing_System=quartz when building?

[rogermc2]

GL.Context.Major_Version produces 3 GL.Context.Minor_Version produces 3

GL_Version : String := GL.Context.Version_String; produces: raised CONSTRAINT_ERROR : erroneous memory access presumably because my OpenGL is not version 2?

I am using GPS which produces the command line: gprbuild -d -eL -P/OpenGL_Projects/GLFW Tutorial/Vertex_Array_Minimal/vertex_array_minimal.gpr -XLIBRARY_TYPE=static -XAuto_Exceptions=enabled -XMode=debug -s Adding -XWindowing_System=quartz doesn't seem to make any difference.

[rogermc2]

Is this relevant? http://stackoverflow.com/questions/19825582/modern-opengl-with-glfw3-on-mac-osx-10-8-4-missing-glgenvertexarrays-and-glb or: http://stackoverflow.com/questions/22118518/use-of-undeclared-identifier-glgenvertexarrays-error-even-after-including-open

[rogermc2]

I built a C++ version using CodeBlocks. This returned the compilation error; use of undeclared identifier 'glGenVertexArrays'. However, it suggested 'glGenVertexArraysAPPLE' which I used. (I think I saw, while googling, a comment about Apple making this name change!) This required #include with Header and Library paths from /System/Library/Frameworks/OpenGL.framework. The minimal program then worked without complaint!

Same goes for glBindVertexArrayAPPLE!

[flyx]

glGenVertexArrays should be available on OSX with #include <OpenGL/gl3.h> (but not with #include <OpenGL/gl.h>).

But the actual problem is that a C++ version that binds directly to the function is not comparable to the Ada version. OpenGLAda uses runtime loading for all OpenGL features beyond 1.1, so a function pointer for glGenVertexArrays is queried from the OS when first calling it. To be comparable, the C++ version would need to do the same stuff OpenGLAda does in GL_Subprogram_Reference.

[flyx]

The SO questions you linked concern headers. This is not relevant for OpenGLAda, because it does not require any C headers. But it is for recreating the issue with C++, as explained above.

[flyx]

I tested it on my Mac and get the same error. So it seems like OpenGLAda currently does not work on OSX. I currently have no idea what the actual issue is, but it obviously has to do with runtime loading of function pointers.

But one thing I noticed is that ld complains that the OpenGLAda files have been built for OSX 10.12, which indicates that AdaCore's GNAT GPL may be the culprit. So I tried using this distribution which claims to be for OSX 10.11. Curiously, compiling with this GNAT version yields the same ld warnings, but the OpenGL 3 test works with it. Please check if it works for you.

[rogermc2]

All my vertex array OpenGL programs, including OpenGL 3, now work using gcc-6.1.0-x86_64-apple-darwin15-2016-bin.tar.bz2

However, I don't get the ld complaint that you mention. Regards, Roger

[flyx]

Okay, then that is unrelated.

This would be nice to be reported to AdaCore, but I don't think bug reports on the GPL version have a high priority there. So best thing to do is to

• [ ] document that OpenGLAda does not work with current GNAT GPL.

[rogermc2]

I agree, so we can close this issue now?

[flyx]

I will close it when the documentation updated happened.

[flyx]

README warns now about the problem.

[rogermc2]

Thanks for your help. Regards, Roger

On 24 Nov 2016, at 3:16 AM, flyx notifications@github.com wrote:

Closed #15.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.