Re: New Ada binding to OpenGL

[David Holm <david@realityrift.com>]

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