New Ada binding to OpenGL

New Ada binding to OpenGL

[David Holm]

Hi,
as the original binding to OpenGL seems to be pretty dead (the only places 
to find it is in AdaSDL and GtkAda) I started a new project.
My bindings are not based on the old ones. The current version is based on 
MesaLib 5.0.
At the moment there are only thin bindings but the idea is to implement a 
thick binding as soon as the thin one works as it should.

The binding is located here:
http://adaopengl.sourceforge.net/

As I'm going away today and won't have much computer access until 
wednesday/thursday I released a preview version (0.1). Please look through 
it and send constructive feedback to me. Also check the Readme before 
mailing me as it contains some implementation notes I scribbled down.

//David Holm

Re: New Ada binding to OpenGL

[Joachim Schr�er]

Hello,

first of all it's good to see that I'm not the only one left doing Ada and
OpenGL
(also see my pretty old page www.adapower.com/schroer ).
A few remarks concerning your binding:

1) For writing plattform independend OpenGL applications besides GL and GLU
a binding to GLUT should be included.

2) I would prefer not to call the main package Opengl but instead use a name
more related to the original C headers like gl or gl_h.
(A personal reason: All my OpenGL applications and classes are in children
of a package called Opengl. There then are children like
with Win32.Gl; package Opengl.Gl renames Win32.GL;

3) Generally I would not add anything to the binding or alter the binding
generator output more than necessary. It is a thin binding and should
represent the original C binding as far as possible (so you can use the C
based literature). The only requirements: The binding should work and be
platform independed (see remarks below).

4) The subprograms taking system.address parameters are superfluous and
represent a not very Adalike style. It is very staightforward to call a
function with access parameter mode or with a general access type. Simply
declare arrays of aliased variables and pass
The_Array(The_Array'First)'Unchecked_Access. Take the following example to
call
procedure glClipPlane(plane : GLENUM;

                                  equation: access GLDOUBLE); --
./GL/gl.h:791



package Opengl.Clip_Planes is

-- Plane coefficients -----------------------------------------------


A : constant := 1; B : constant := 2; C : constant := 3; D : constant := 4;

-- Plane-type and simple clip-plane constants -----------------------

type Plane is array(A .. D) of aliased Gl.Gldouble;

...


and then in the implementation

procedure Enable(The_Plane : in Plane) is

begin

  Counter := Counter + 1;

  if Counter <= Clip_Plane_Indices'Last then

    Gl.Glclipplane(Plane     => Clip_Plane_Indices(Counter),

                          Equation => The_Plane(A)'Unchecked_Access);

    Gl.Glenable(Clip_Plane_Indices(Counter));

...

5) It's very important to use pure constants for all the integer values as
you did. I saw bindings using typed constants, often of type glenum. As in
Win32 a lot of these types are derived from types in package win32 I expect
problems when now porting from Windows to Linux.

6) A question: Are there problems expected using this binding when running
OpenGL without Mesa being installed say on windows using the old dlls and
archives OpenGL32.dll / Glu32.dll / Glut32.dll,  libOpenGL32.a / libGlu32.a
/ libGlut32.a.
Will my application link and run with headers for OpenGL 1.2 or newer
with underlying binary libs for OpenGL 1.1? (Of course the application does
only use 1.1 features). I could try but maybe someone knows...

Best regards
    Joachim Schroer

"David Holm" <david@realityrift.com> schrieb im Newsbeitrag
news:dAbP9.3047$FF4.185223@newsb.telia.net...
> Hi,
> as the original binding to OpenGL seems to be pretty dead (the only places
> to find it is in AdaSDL and GtkAda) I started a new project.
> My bindings are not based on the old ones. The current version is based on
> MesaLib 5.0.
> At the moment there are only thin bindings but the idea is to implement a
> thick binding as soon as the thin one works as it should.
>
> The binding is located here:
> http://adaopengl.sourceforge.net/
>
> As I'm going away today and won't have much computer access until
> wednesday/thursday I released a preview version (0.1). Please look through
> it and send constructive feedback to me. Also check the Readme before
> mailing me as it contains some implementation notes I scribbled down.
>
> //David Holm

Re: New Ada binding to OpenGL

[Joachim Schr�er]

Hello,

I forgot one thing: You should announce your work in the OpenGL newsgroup
too:

comp.graphics.api.opengl

Joachim Schroer

Re: New Ada binding to OpenGL

[David Holm]

Hi,
thanks for the great feedback.

Joachim Schr�er wrote:

> Hello,
> 
> first of all it's good to see that I'm not the only one left doing Ada and
> OpenGL
> (also see my pretty old page www.adapower.com/schroer ).
> A few remarks concerning your binding:
> 
> 1) For writing plattform independend OpenGL applications besides GL and
> GLU a binding to GLUT should be included.

The idea was to include a GLUT binding with the first release but it slipped 
my mind. I was never a big fan of GLUT but I'm changing my mind on that 
point.
I will get on it right away.

> 2) I would prefer not to call the main package Opengl but instead use a
> name more related to the original C headers like gl or gl_h.
> (A personal reason: All my OpenGL applications and classes are in children
> of a package called Opengl. There then are children like
> with Win32.Gl; package Opengl.Gl renames Win32.GL;

I had a tough time deciding here. gl_h was used by the old OpenGL binding 
and I wanted both that one and mine to be able to coexist.
Most, if not all, Ada packages have longer names such as Ada.Text_IO, 
System.Address and so on, so I didn't like using the very short "gl" name.
I'm still not sure what to do here, OpenGL seemed to be the most Ada-ish.
I'm calling the thick(er) binding AdaGL, which I'm working on.

> 3) Generally I would not add anything to the binding or alter the binding
> generator output more than necessary. It is a thin binding and should
> represent the original C binding as far as possible (so you can use the C
> based literature). The only requirements: The binding should work and be
> platform independed (see remarks below).

I totally agree.
 
> 4) The subprograms taking system.address parameters are superfluous and
> represent a not very Adalike style. It is very staightforward to call a
> function with access parameter mode or with a general access type. Simply
> declare arrays of aliased variables and pass
> The_Array(The_Array'First)'Unchecked_Access. Take the following example to
> call
> procedure glClipPlane(plane : GLENUM;
> 
>                                   equation: access GLDOUBLE); --
> ./GL/gl.h:791
> 
> 
> 
> package Opengl.Clip_Planes is
> 
> -- Plane coefficients -----------------------------------------------
> 
> 
> A : constant := 1; B : constant := 2; C : constant := 3; D : constant :=
> 4;
> 
> -- Plane-type and simple clip-plane constants -----------------------
> 
> type Plane is array(A .. D) of aliased Gl.Gldouble;
> 
> ...
> 
> 
> and then in the implementation
> 
> procedure Enable(The_Plane : in Plane) is
> 
> begin
> 
>   Counter := Counter + 1;
> 
>   if Counter <= Clip_Plane_Indices'Last then
> 
>     Gl.Glclipplane(Plane     => Clip_Plane_Indices(Counter),
> 
>                           Equation => The_Plane(A)'Unchecked_Access);
> 
>     Gl.Glenable(Clip_Plane_Indices(Counter));
> 
> ...

Thank you, this is very helpful to me. I had no idea how to solve this issue 
and then I found some post somewhere that mentioned using System.Address, 
the reply to that post was that it was not a very good idea but I couldn't 
find an alternate solution.
I've been looking for a guide or something on creating bindings from C code 
that would discuss issues like this one but never found any so I ended up 
with groups.google.com and alot of guesswork.
Will look at this right after the GLUT binding =).
 
> 5) It's very important to use pure constants for all the integer values as
> you did. I saw bindings using typed constants, often of type glenum. As in
> Win32 a lot of these types are derived from types in package win32 I
> expect problems when now porting from Windows to Linux.

Yeah, I've noticed this myself. In this case cbind selected the correct type 
automatically though ;).
 
> 6) A question: Are there problems expected using this binding when running
> OpenGL without Mesa being installed say on windows using the old dlls and
> archives OpenGL32.dll / Glu32.dll / Glut32.dll,  libOpenGL32.a /
> libGlu32.a / libGlut32.a.

I hope not, I'm not using windows though so I can't be sure. Continued 
below...

> Will my application link and run with headers for OpenGL 1.2 or newer
> with underlying binary libs for OpenGL 1.1? (Of course the application
> does only use 1.1 features). I could try but maybe someone knows...

I was hoping that the symbols specified by the pragmas would only be 
expanded if you include them in your application. This might be compiler 
specific but it seems the logical way to do it. In which case it should 
work with OpenGL 1.1 to 1.4 and non-Mesa libraries.

Thanks again for the feedback
//David Holm
 
> Best regards
>     Joachim Schroer
> 
> "David Holm" <david@realityrift.com> schrieb im Newsbeitrag
> news:dAbP9.3047$FF4.185223@newsb.telia.net...
>> Hi,
>> as the original binding to OpenGL seems to be pretty dead (the only
>> places to find it is in AdaSDL and GtkAda) I started a new project.
>> My bindings are not based on the old ones. The current version is based
>> on MesaLib 5.0.
>> At the moment there are only thin bindings but the idea is to implement a
>> thick binding as soon as the thin one works as it should.
>>
>> The binding is located here:
>> http://adaopengl.sourceforge.net/
>>
>>
>> //David Holm

Re: New Ada binding to OpenGL

[David Holm]

Joachim Schr�er wrote:

> 4) The subprograms taking system.address parameters are superfluous and
> represent a not very Adalike style. It is very staightforward to call a
> function with access parameter mode or with a general access type. Simply
> declare arrays of aliased variables and pass
> The_Array(The_Array'First)'Unchecked_Access. Take the following example to
> call
> procedure glClipPlane(plane : GLENUM;
> 
>                                   equation: access GLDOUBLE); --
> ./GL/gl.h:791
> 
> 
> 
> package Opengl.Clip_Planes is
> 
> -- Plane coefficients -----------------------------------------------
> 
> 
> A : constant := 1; B : constant := 2; C : constant := 3; D : constant :=
> 4;
> 
> -- Plane-type and simple clip-plane constants -----------------------
> 
> type Plane is array(A .. D) of aliased Gl.Gldouble;
> 
> ...
> 
> 
> and then in the implementation
> 
> procedure Enable(The_Plane : in Plane) is
> 
> begin
> 
>   Counter := Counter + 1;
> 
>   if Counter <= Clip_Plane_Indices'Last then
> 
>     Gl.Glclipplane(Plane     => Clip_Plane_Indices(Counter),
> 
>                           Equation => The_Plane(A)'Unchecked_Access);
> 
>     Gl.Glenable(Clip_Plane_Indices(Counter));
> 
> ...
> 

How can I pass null addresses this way? With System.Address I could use 
GLNULL : System.Address renames System.Null_Address;

//David

Re: New Ada binding to OpenGL

[Joachim Schr�er]

Hello,

to pass null simply write something like
Gl.Glclipplane(Plane => 1, Equation => null);

But why do you want to pass null access values.

I expect some kind of error in the C code then.

I will have a look for books were Ada/C coding is documented.

I thing, the Ada95 rationale is a good reference. I will give you links
later.

    J. Schr�er

"David Holm" <david@realityrift.com> schrieb im Newsbeitrag
news:V54Q9.3365$FF4.203703@newsb.telia.net...
> Joachim Schr�er wrote:
>
> > 4) The subprograms taking system.address parameters are superfluous and
> > represent a not very Adalike style. It is very staightforward to call a
> > function with access parameter mode or with a general access type.
Simply
> > declare arrays of aliased variables and pass
> > The_Array(The_Array'First)'Unchecked_Access. Take the following example
to
> > call
> > procedure glClipPlane(plane : GLENUM;
> >
> >                                   equation: access GLDOUBLE); --
> > ./GL/gl.h:791
> >
> >
> >
> > package Opengl.Clip_Planes is
> >
> > -- Plane coefficients -----------------------------------------------
> >
> >
> > A : constant := 1; B : constant := 2; C : constant := 3; D : constant :=
> > 4;
> >
> > -- Plane-type and simple clip-plane constants -----------------------
> >
> > type Plane is array(A .. D) of aliased Gl.Gldouble;
> >
> > ...
> >
> >
> > and then in the implementation
> >
> > procedure Enable(The_Plane : in Plane) is
> >
> > begin
> >
> >   Counter := Counter + 1;
> >
> >   if Counter <= Clip_Plane_Indices'Last then
> >
> >     Gl.Glclipplane(Plane     => Clip_Plane_Indices(Counter),
> >
> >                           Equation => The_Plane(A)'Unchecked_Access);
> >
> >     Gl.Glenable(Clip_Plane_Indices(Counter));
> >
> > ...
> >
>
> How can I pass null addresses this way? With System.Address I could use
> GLNULL : System.Address renames System.Null_Address;
>
> //David

Re: New Ada binding to OpenGL

[Bobby D. Bryant]

On Mon, 30 Dec 2002 21:50:20 +0100, Joachim Schr�er wrote:

> 3) Generally I would not add anything to the binding or alter the
> binding generator output more than necessary. It is a thin binding and
> should represent the original C binding as far as possible (so you can
> use the C based literature). The only requirements: The binding should
> work and be platform independed (see remarks below).

Some of us would greatly prefer thick bindings.  IMO GtkAda is the
paradigm for how this sort of thing should be done.

Sure is a lot of work for something as big as GTK+ or OpenGL, though.

Bobby Bryant
Austin, Texas

Re: New Ada binding to OpenGL

[David Holm]

Joachim Schr�er wrote:

> Hello,
> 
> to pass null simply write something like
> Gl.Glclipplane(Plane => 1, Equation => null);
> 
> But why do you want to pass null access values.
> 
> I expect some kind of error in the C code then.
> 
> I will have a look for books were Ada/C coding is documented.
> 
> I thing, the Ada95 rationale is a good reference. I will give you links
> later.
> 
>     J. Schr�er
> 

Yeah, you were correct. I got errors in the C code.
The thing is that for instance, glXCreateContext takes a C NULL pointer when 
you want to create a new context that is not a subcontext to an existing 
one.
I have not yet managed to find a solution to how to handle this in Ada as I 
get a segfault in libGL when I do it (which is odd since I have a C 
application that passes a C-NULL here without any problems). In this case I 
had an overloaded function which took System.Address, so I never passed a 
null through an access variable.

I found the rationale on www.adahome.org, so no need to send a link.

//David Holm

Re: New Ada binding to OpenGL

[Joachim Schr�er]

Of course you need thick bindings.
When writing greater applications you should encapsulate a
lowlevel library like OpenGL by a general OO framework.
(I've done somethink like this, see www.adapower.com/schroer ,
but that is not documented in detail.)
What I meant is, the (generated) thin binding should be close to
the original. What you build on top of it is another thing.

    J. Schr�er

"Bobby D. Bryant" <bdbryant@mail.utexas.edu> schrieb im Newsbeitrag
news:pan.2003.01.03.21.57.57.596399@mail.utexas.edu...
> On Mon, 30 Dec 2002 21:50:20 +0100, Joachim Schr�er wrote:
>
> > 3) Generally I would not add anything to the binding or alter the
> > binding generator output more than necessary. It is a thin binding and
> > should represent the original C binding as far as possible (so you can
> > use the C based literature). The only requirements: The binding should
> > work and be platform independed (see remarks below).
>
> Some of us would greatly prefer thick bindings.  IMO GtkAda is the
> paradigm for how this sort of thing should be done.
>
> Sure is a lot of work for something as big as GTK+ or OpenGL, though.
>
> Bobby Bryant
> Austin, Texas

Re: New Ada binding to OpenGL

[David Holm]

chris.danx wrote:

> 
> I've passed a C-null value to a c funtion from Ada using GNAT before,
> just wish I could remember how.  Surely someone else has done it too?
> Did you try just "null", the ada word?
> 
> There's also something about a C Null_Pointer in the Ref. Manual,
> section B.3.1, which might be what your looking for, though I've not
> used it and am not sure if that's its purpose.
> 

It is working now. It turned out it wasn't the null at all but the function 
call above it that failed and returned a null, which I never detected.

//David Holm

Re: New Ada binding to OpenGL

[Brian Gaffney]

David Holm <david@realityrift.com> wrote in message news:<N73Q9.3354$FF4.203172@newsb.telia.net>...
> Hi,
> thanks for the great feedback.
> 
> Joachim Schr�er wrote:
. . .
> > 2) I would prefer not to call the main package Opengl but instead use a
> > name more related to the original C headers like gl or gl_h.
> > (A personal reason: All my OpenGL applications and classes are in children
> > of a package called Opengl. There then are children like
> > with Win32.Gl; package Opengl.Gl renames Win32.GL;
> 
> I had a tough time deciding here. gl_h was used by the old OpenGL binding 
> and I wanted both that one and mine to be able to coexist.
> Most, if not all, Ada packages have longer names such as Ada.Text_IO, 
> System.Address and so on, so I didn't like using the very short "gl" name.
> I'm still not sure what to do here, OpenGL seemed to be the most Ada-ish.
> I'm calling the thick(er) binding AdaGL, which I'm working on.
> 
David,
   Since in your original post you stated:
> >> The binding is located here:
> >> http://adaopengl.sourceforge.net/
I take it your project name is AdaOpenGL.  This seems like a good
candidate for a main package name.  It would allow people to identify
your project from the package, the package from your project, and
would help reduce namespace conflicts (at least for people who know of
your project).

Re: New Ada binding to OpenGL

[David Holm]

On 8 Jan 2003 12:20:22 -0800
Brian.Gaffney@myrealbox.com (Brian Gaffney) wrote:

> David Holm <david@realityrift.com> wrote in message
> news:<N73Q9.3354$FF4.203172@newsb.telia.net>...
> David,
>    Since in your original post you stated:
> > >> The binding is located here:
> > >> http://adaopengl.sourceforge.net/
> I take it your project name is AdaOpenGL.  This seems like a good
> candidate for a main package name.  It would allow people to identify
> your project from the package, the package from your project, and
> would help reduce namespace conflicts (at least for people who know of
> your project).

Yeah, I guess.
I have a thin binding and I'm working on a thick binding. Which one should I call AdaOpenGL and
what should I call the other?

Re: New Ada binding to OpenGL

[Bobby D. Bryant]

On Wed, 08 Jan 2003 23:47:25 +0000, David Holm wrote:

> On 8 Jan 2003 12:20:22 -0800
> Brian.Gaffney@myrealbox.com (Brian Gaffney) wrote:

>> I take it your project name is AdaOpenGL.  This seems like a good
>> candidate for a main package name.  It would allow people to identify
>> your project from the package, the package from your project, and would
>> help reduce namespace conflicts (at least for people who know of your
>> project).
> 
> Yeah, I guess.
> I have a thin binding and I'm working on a thick binding. Which one
> should I call AdaOpenGL and what should I call the other?

When it's done the thick binding is what most people will use, so IMO
that's the one that should have the most straightforward name --
presumably AdaOpenGL.

Or actually, I'd like to see that as the name of the _kit_.  The actual
package name should simply be OpenGL, so that people's source code could
refer to -

	with OpenGL.Whatever;

There's no reason to import the identifier "Ada" into the Ada namespace.

Or better yet, simply GL, GLU, GLX, etc., -

	with GLX;
	...
	GLX.Choose_Visual( blah-de-blah);
	...

Again, take your cue for what the fine folk did with GtkAda.  The name of
the _product_ is "GtkAda", but the names of the Ada _packages_ are Glib,
GDK, GTK, etc.

They do have a package called GtkAda, but that's to identify stuff that's
actually new with GtkAda rather than bindings of the GTK+ stuff.

-- 
Bobby Bryant
Austin, Texas

Re: New Ada binding to OpenGL

[Brian Gaffney]

"Bobby D. Bryant" <bdbryant@mail.utexas.edu> wrote in message news:<pan.2003.01.09.09.55.17.192487@mail.utexas.edu>...
> On Wed, 08 Jan 2003 23:47:25 +0000, David Holm wrote:
> 
> > On 8 Jan 2003 12:20:22 -0800
> > Brian.Gaffney@myrealbox.com (Brian Gaffney) wrote:
>  
> >> I take it your project name is AdaOpenGL.  This seems like a good
> >> candidate for a main package name.  It would allow people to identify
> >> your project from the package, the package from your project, and would
> >> help reduce namespace conflicts (at least for people who know of your
> >> project).
> > 
> > Yeah, I guess.
> > I have a thin binding and I'm working on a thick binding. Which one
> > should I call AdaOpenGL and what should I call the other?
> 
> When it's done the thick binding is what most people will use, so IMO
> that's the one that should have the most straightforward name --
> presumably AdaOpenGL.

I was going to say I like the previously posted idea of AdaGL for the
thick binding, but thinking about it I would prefer if they were kept
together, so users know they're related.  I'd suggest AdaOpenGL.* for
the thick binding and AdaOpenGL.OpenGL.* for the thin (or maybe
AdaOpenGL.Thin, but I think that's ugly).  Users could use 'use' to
simplify the references to shorter package names.

> 
> Or actually, I'd like to see that as the name of the _kit_.  The actual
> package name should simply be OpenGL, so that people's source code could
> refer to -
> 
> 	with OpenGL.Whatever;
> 
> There's no reason to import the identifier "Ada" into the Ada namespace.

That's exactly the problem that was originally brought up:  everybody
with an OpenGL binding would do this.  I don't like this, since it
would only make sense if (1) there were only one binding to OpenGL, or
(2) all bindings to OpenGL used the same specification.  Otherwise
there's no benefit to calling them all the same thing, and it gets
very confusing (Which OpenGL library did the author mean?  How do I
use different OpenGL libraries on one computer?)

> 
> Or better yet, simply GL, GLU, GLX, etc., -
> 
> 	with GLX;
> 	...
> 	GLX.Choose_Visual( blah-de-blah);
> 	...
> 

I like this even less, since (unless I know something about AdaOpenGL,
or OpenGL in general) I have no way of knowing that GL, GLU, and GLX
are related (without looking into their files).  This, to me, defeats
one of the major benefits of hierachical package names.  We might as
well be programming in C:-)

> Again, take your cue for what the fine folk did with GtkAda.  The name of
> the _product_ is "GtkAda", but the names of the Ada _packages_ are Glib,
> GDK, GTK, etc.

Again, how do I know these packages are related?  Without looking into
the source, how do I know Glib is related to GTK/GDK and not related
to GL/GLU/GLX or something else?

I can see benefits to the library (binding) creator in doing this,
especially if the (original) library is evolving.  However, I think it
impedes code readablility, especially if more than one such library is
involved.

> 
> They do have a package called GtkAda, but that's to identify stuff that's
> actually new with GtkAda rather than bindings of the GTK+ stuff.