ANN: OpenGLAda 0.3 and OpenCLAda 0.1 released

ANN: OpenGLAda 0.3 and OpenCLAda 0.1 released

[Felix Krause]

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/

Re: ANN: OpenGLAda 0.3 and OpenCLAda 0.1 released

[Marius Amado-Alves]

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.

Re: ANN: OpenGLAda 0.3 and OpenCLAda 0.1 released

[Felix Krause]

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/

Re: ANN: OpenGLAda 0.3 and OpenCLAda 0.1 released

[Shark8]

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.

Re: ANN: OpenGLAda 0.3 and OpenCLAda 0.1 released

[Marius Amado-Alves]

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.

Re: ANN: OpenGLAda 0.3 and OpenCLAda 0.1 released

[Felix Krause]

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/

Re: ANN: OpenGLAda 0.3 and OpenCLAda 0.1 released

[Marius Amado-Alves]

Thanks a lot, Felix.
You've put me in the right direction.
The test now builds and runs successfully.

Re: ANN: OpenGLAda 0.3 and OpenCLAda 0.1 released

[Marius Amado-Alves]

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.

Re: ANN: OpenGLAda 0.3 and OpenCLAda 0.1 released

[Felix Krause]

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/

Re: ANN: OpenGLAda 0.3 and OpenCLAda 0.1 released

[Marius Amado-Alves]

> 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.

Re: ANN: OpenGLAda 0.3 and OpenCLAda 0.1 released

[Marius Amado-Alves]

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.

Re: ANN: OpenGLAda 0.3 and OpenCLAda 0.1 released

[Felix Krause]

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/