* ANN: OpenGLAda 0.3 and OpenCLAda 0.1 released @ 2013-11-14 21:37 Felix Krause 2013-11-20 16:49 ` Marius Amado-Alves 2013-11-22 14:06 ` Marius Amado-Alves 0 siblings, 2 replies; 12+ messages in thread From: Felix Krause @ 2013-11-14 21:37 UTC (permalink / raw) These are quite thick Ada bindings for the OpenGL and OpenCL APIs. OpenGLAda also contains additional wrappers for GLFW 2/3, SOIL and FTGL. The two wrappers are interoperable (you can use the cl_gl extension of OpenCL to transfer data between OpenGLAda and OpenCLAda). Some online documentation, including overviews of what the wrappers add to the bare C APIs, is available at http://flyx.github.io/OpenGLAda/ http://flyx.github.io/OpenCLAda/ Releases are available as tags of the GitHub repositories: https://github.com/flyx/OpenGLAda/tags https://github.com/flyx/OpenCLAda/tags -- Felix Krause http://flyx.org/ ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: ANN: OpenGLAda 0.3 and OpenCLAda 0.1 released 2013-11-14 21:37 ANN: OpenGLAda 0.3 and OpenCLAda 0.1 released Felix Krause @ 2013-11-20 16:49 ` Marius Amado-Alves 2013-11-20 20:13 ` Felix Krause 2013-11-21 0:53 ` Shark8 2013-11-22 14:06 ` Marius Amado-Alves 1 sibling, 2 replies; 12+ messages in thread From: Marius Amado-Alves @ 2013-11-20 16:49 UTC (permalink / raw) Congrats for this good effort. I took a look at this "thick" binding, in hopes... It's still the state machine paradigm of OpenGL, with the matrix stacks, global state, etc. Assembler language. I wonder: could we not "rectify" this with a (truly) thick binding (without incurring significant performance penalty)? Matrices as normal objects? Maybe compatible with Ada.Real_Arrays? Impossible dream? Thanks. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: ANN: OpenGLAda 0.3 and OpenCLAda 0.1 released 2013-11-20 16:49 ` Marius Amado-Alves @ 2013-11-20 20:13 ` Felix Krause 2013-11-21 0:53 ` Shark8 1 sibling, 0 replies; 12+ messages in thread From: Felix Krause @ 2013-11-20 20:13 UTC (permalink / raw) On 2013-11-20 16:49:03 +0000, Marius Amado-Alves said: > Congrats for this good effort. > I took a look at this "thick" binding, in hopes... > It's still the state machine paradigm of OpenGL, with the matrix > stacks, global state, etc. Assembler language. The matrix stack has already been deprecated with OpenGL 3. One should use uniform shader variables instead. But yes, on the whole it's still state-based OpenGL. > I wonder: could we not "rectify" this with a (truly) thick binding > (without incurring significant performance penalty)? I tried it when I wrote the first version of the texture handling wrapper: I tried to implement it in a way that one can change properties of textures directly without binding them to a target. The problem is, such a radical change of API semantics would need to be reflected in all areas, and the resulting API would be completely incompatible with the original one of OpenGL. This is why I finally decided against it. Such an API would need to be well documented and it's a hurdle for programmers who know OpenGL in C or other languages. > Matrices as normal objects? > Maybe compatible with Ada.Real_Arrays? Generic_Real_Arrays may be suitable. The only things needed for this to be an acceptable OpenGL data source are some representation pragmas, which could be applied by deriving the Real_Array and Real_Matrix types (copying the data around should rather be avoided for performance reasons). I'll have a look at it. -- Felix Krause http://flyx.org/ ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: ANN: OpenGLAda 0.3 and OpenCLAda 0.1 released 2013-11-20 16:49 ` Marius Amado-Alves 2013-11-20 20:13 ` Felix Krause @ 2013-11-21 0:53 ` Shark8 1 sibling, 0 replies; 12+ messages in thread From: Shark8 @ 2013-11-21 0:53 UTC (permalink / raw) On Wednesday, November 20, 2013 9:49:03 AM UTC-7, Marius Amado-Alves wrote: > Congrats for this good effort. > > I took a look at this "thick" binding, in hopes... > Impossible dream? No, I don't think it's impossible. I do think that getting out of the low-level requires a bit more work/thought than most are willing to put into the problem. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: ANN: OpenGLAda 0.3 and OpenCLAda 0.1 released 2013-11-14 21:37 ANN: OpenGLAda 0.3 and OpenCLAda 0.1 released Felix Krause 2013-11-20 16:49 ` Marius Amado-Alves @ 2013-11-22 14:06 ` Marius Amado-Alves 2013-11-22 16:59 ` Felix Krause 1 sibling, 1 reply; 12+ messages in thread From: Marius Amado-Alves @ 2013-11-22 14:06 UTC (permalink / raw) Giving it a try on Windows. Needs GLFW, which needs CMake, so I installed all these. Now how do I make OpelGLAda aware of the GLFW installation? Thanks. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: ANN: OpenGLAda 0.3 and OpenCLAda 0.1 released 2013-11-22 14:06 ` Marius Amado-Alves @ 2013-11-22 16:59 ` Felix Krause 2013-11-25 15:28 ` Marius Amado-Alves 0 siblings, 1 reply; 12+ messages in thread From: Felix Krause @ 2013-11-22 16:59 UTC (permalink / raw) On 2013-11-22 14:06:29 +0000, Marius Amado-Alves said: > Giving it a try on Windows. > Needs GLFW, which needs CMake, so I installed all these. > Now how do I make OpelGLAda aware of the GLFW installation? > Thanks. If you're using AdaCore's GNAT, put the GLFW binaries into the "lib" folder of your GNAT installation (e.g. C:\GNAT\2013\lib). You can use the precompiled Windows binaries that are available on the GLFW site: http://www.glfw.org/download.html (Use the ones in the lib-mingw folder of the package). If you compiled it yourself, make sure it has the right architecture (AdaCore's GNAT needs and produces 32bit binaries on Windows). If you're compiling from command line, you can probably also set LD_LIBRARY_PATH to point to your binaries instead of moving them into GNAT's lib folder. -- Felix Krause http://flyx.org/ ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: ANN: OpenGLAda 0.3 and OpenCLAda 0.1 released 2013-11-22 16:59 ` Felix Krause @ 2013-11-25 15:28 ` Marius Amado-Alves 2013-11-27 10:40 ` Marius Amado-Alves 0 siblings, 1 reply; 12+ messages in thread From: Marius Amado-Alves @ 2013-11-25 15:28 UTC (permalink / raw) Thanks a lot, Felix. You've put me in the right direction. The test now builds and runs successfully. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: ANN: OpenGLAda 0.3 and OpenCLAda 0.1 released 2013-11-25 15:28 ` Marius Amado-Alves @ 2013-11-27 10:40 ` Marius Amado-Alves 2013-11-29 18:51 ` Felix Krause 0 siblings, 1 reply; 12+ messages in thread From: Marius Amado-Alves @ 2013-11-27 10:40 UTC (permalink / raw) Continuing studying this. You're right, this binding is the thickiest around. Congrats again. All tests build but some e.g. gl_test-opengl3 abort with messages like """ C:\Users\ADMIN\OpenGLAda-0.3\bin\gl_test-opengl3 Error occured (VERSION_UNAVAILABLE): WGL: OpenGL profile requested but WGL_ARB_create_context_profile is unavailable raised PROGRAM_ERROR : EXCEPTION_ACCESS_VIOLATION [2013-11-27 10:31:31] process exited with status 1 (elapsed time: 00.21s) """ Thanks. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: ANN: OpenGLAda 0.3 and OpenCLAda 0.1 released 2013-11-27 10:40 ` Marius Amado-Alves @ 2013-11-29 18:51 ` Felix Krause 2013-12-02 13:56 ` Marius Amado-Alves 0 siblings, 1 reply; 12+ messages in thread From: Felix Krause @ 2013-11-29 18:51 UTC (permalink / raw) On 2013-11-27 10:40:19 +0000, Marius Amado-Alves said: > All tests build but some e.g. gl_test-opengl3 abort with messages like > """ > C:\Users\ADMIN\OpenGLAda-0.3\bin\gl_test-opengl3 > Error occured (VERSION_UNAVAILABLE): WGL: OpenGL profile requested but > WGL_ARB_create_context_profile is unavailable > > raised PROGRAM_ERROR : EXCEPTION_ACCESS_VIOLATION > [2013-11-27 10:31:31] process exited with status 1 (elapsed time: 00.21s) That's partly expected and partly a bug. Expected because it is what happens when you request an OpenGL profile version which is not supported by the driver (the OpenGL 3 test requires an OpenGL 3.2 core profile). A bug because this should raise an exception declared in GLFW rather than leading to a PROGRAM_ERROR (I'll try to fix that). The tests that use OpenGL 3 functionality request an OpenGL 3.2 core profile because that's the only way to access this functionality on OSX. Your OpenGL implementation does not seem to support OpenGL 3.2, so you're getting this error - it may support 3.0 or 3.1 which would suffice to run the tests. OpenGL profiles are a bit of a mess, you can read more about it here: http://www.opengl.org/wiki/Core_And_Compatibility_in_Contexts You can try to strip away OSX compatibility by changing the version given to GL_Test.Display_Backend.Configure_Minimum_OpenGL_Version in the tests (try 3.0 or 3.1). You might even have success with a 2.1 context as long as the 3.0 functionality is available as extensions. -- Felix Krause http://flyx.org/ ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: ANN: OpenGLAda 0.3 and OpenCLAda 0.1 released 2013-11-29 18:51 ` Felix Krause @ 2013-12-02 13:56 ` Marius Amado-Alves 2013-12-26 18:03 ` Marius Amado-Alves 0 siblings, 1 reply; 12+ messages in thread From: Marius Amado-Alves @ 2013-12-02 13:56 UTC (permalink / raw) > You can try to strip away OSX compatibility by changing the version > given to > GL_Test.Display_Backend.Configure_Minimum_OpenGL_Version > in the tests (try 3.0 or 3.1) I've got 3.1 but the only thing that worked was simply removing this call. Again your fine reply has put me in the right direction. Thanks a lot. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: ANN: OpenGLAda 0.3 and OpenCLAda 0.1 released 2013-12-02 13:56 ` Marius Amado-Alves @ 2013-12-26 18:03 ` Marius Amado-Alves 2013-12-31 12:45 ` Felix Krause 0 siblings, 1 reply; 12+ messages in thread From: Marius Amado-Alves @ 2013-12-26 18:03 UTC (permalink / raw) I am building a program that uses OpenGLAda with GLFW 3 the way it's suggested in the readme: YourProject | |-dependencies | | | +-OpenGLAda | |-your |-project |-files +-... which in my case is project | |-OpenGLAda-0.3 | |-test.adb |-test.gpr |-test.exe (result, see below) It builds and runs, but I'd like to sanitize the process. The project with "OpenGLAda-0.3/opengl-glfw"; project Test is for Main use ("test"); end Test; gives error: gl.ali not found, gl.adb must be compiled. If we tell GNAT where they are with "OpenGLAda-0.3/opengl-glfw"; project Test is for Object_Dir use "OpenGLAda-0.3/obj"; for Main use ("test"); end Test; it works, but a few problems (my poor command of the GNAT Project language no doubt): 1. Why do we have to tell GNAT the "OpenGLAda-0.3/obj" path? shouldn't the OpenGLAda project files know that? 2. The executable gets created inside that path, whereas I wanted it in the base project dir. 3. The OpenGlAda project files expect external scenario parameters; I am using command line options -X gnatmake -Ptest -Xwindowing_system=windows -Xglfw_version=3 is it possible to set these params in the project file (test.gpr)? (Two avoid having options in two places, command line, project file.) Thanks a lot. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: ANN: OpenGLAda 0.3 and OpenCLAda 0.1 released 2013-12-26 18:03 ` Marius Amado-Alves @ 2013-12-31 12:45 ` Felix Krause 0 siblings, 0 replies; 12+ messages in thread From: Felix Krause @ 2013-12-31 12:45 UTC (permalink / raw) On 2013-12-26 18:03:26 +0000, Marius Amado-Alves said: > It builds and runs, but I'd like to sanitize the process. > The project > > with "OpenGLAda-0.3/opengl-glfw"; > project Test is > for Main use ("test"); > end Test; > > gives error: gl.ali not found, gl.adb must be compiled. I also stumbled upon this problem. I don't know what's the cause, but it seems like this is a problem with gnatmake. gl.ali should be copied into OpenGLAda-0.3/lib (where GNAT searches for it), but it is not for some reason. If you compile the project with gprbuild instead, it works as expected. Perhaps someone with more knowledge about gnatmake/gprbuild can comment on that? > If we tell GNAT where they are > > with "OpenGLAda-0.3/opengl-glfw"; > project Test is > for Object_Dir use "OpenGLAda-0.3/obj"; > for Main use ("test"); > end Test; > > it works, but a few problems (my poor command of the GNAT Project > language no doubt): > > 1. > Why do we have to tell GNAT the "OpenGLAda-0.3/obj" path? shouldn't the > OpenGLAda project files know that? What happens when you do that is that GNAT does not need the gl.ali file in the OpenGLAda-0.3/lib directory, because it's available directly in the directory where the object files of your code are placed into. This is a *very* dirty hack and I don't think it's guaranteed to work. > 2. > The executable gets created inside that path, whereas I wanted it in > the base project dir. You can set "Exec_Dir", which defaults to "Object_Dir" if you don't set it. > 3. > The OpenGlAda project files expect external scenario parameters; I am > using command line options -X > gnatmake -Ptest -Xwindowing_system=windows -Xglfw_version=3 > is it possible to set these params in the project file (test.gpr)? > (Two avoid having options in two places, command line, project file.) Currently not. I admit that it was a bad decision to take the GLFW version as scenario parameter, and I will revise this in the next release. As GLFW 2 and 3 are completely incompatible, the decision which one will be used is made in the development stage, not in the compilation stage. Therefore, there should be two projects, opengl-glfw2.gpr and opengl-glfw3.gpr. On the other hand, Windowing_System is about platform independence. If you set it in your project file (you actually cannot do that, btw), your project will only compile on the platform you chose. Therefore, it is a scenario variable so that the platform can be chosen when compiling the project. -- Felix Krause http://flyx.org/ ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2013-12-31 12:45 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-11-14 21:37 ANN: OpenGLAda 0.3 and OpenCLAda 0.1 released Felix Krause 2013-11-20 16:49 ` Marius Amado-Alves 2013-11-20 20:13 ` Felix Krause 2013-11-21 0:53 ` Shark8 2013-11-22 14:06 ` Marius Amado-Alves 2013-11-22 16:59 ` Felix Krause 2013-11-25 15:28 ` Marius Amado-Alves 2013-11-27 10:40 ` Marius Amado-Alves 2013-11-29 18:51 ` Felix Krause 2013-12-02 13:56 ` Marius Amado-Alves 2013-12-26 18:03 ` Marius Amado-Alves 2013-12-31 12:45 ` Felix Krause
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox