OpenGl in ADA

OpenGl in ADA

[Anderson]

Has anyone here used OpenGL with ADA. I have used it in VB, but in ada I do
not know how to open the context window. Can anyone show me the basic start
up for opengl in ada 95 (GNAT). I have the Glut.ads and Gl.ads.

Re: OpenGl in ADA

[Pascal Obry]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1218 bytes --]


Anderson <anderson@wa.apana.org.au> a �crit dans le message :
39084b7b@news.wa.apana.org.au...
> Has anyone here used OpenGL with ADA. I have used it in VB, but in ada I
do
> not know how to open the context window. Can anyone show me the basic
start
> up for opengl in ada 95 (GNAT). I have the Glut.ads and Gl.ads.
>

You'll find some demos on my homepage.

http://perso.wanadoo.fr/pascal.obry/contrib.html

Look for OpenGL and GLUT.

Pascal.

--

--|------------------------------------------------------------
--| Pascal Obry                               Team-Ada Member |
--|                                                           |
--| EDF-DER-IPN-SID- T T I                                    |
--|                       Intranet: http://cln46gb            |
--| Bureau N-023            e-mail: p.obry@der.edf.fr         |
--| 1 Av G�n�ral de Gaulle  voice : +33-1-47.65.50.91         |
--| 92141 Clamart CEDEX     fax   : +33-1-47.65.50.07         |
--| FRANCE                                                    |
--|------------------------------------------------------------
--|
--|         http://perso.wanadoo.fr/pascal.obry
--|
--|   "The best way to travel is by means of imagination"

Opengl in Ada

[Pablo]

Does someone know any tutorial of opengl in Ada? I found thousands
opengl tutorials, but none for Ada...

Re: Opengl in Ada

[Pascal Obry]

Le 28/10/2009 18:12, Pablo a �crit :
> Does someone know any tutorial of opengl in Ada? I found thousands
> opengl tutorials, but none for Ada...

Tutorials no, but there is some OpenGL demos on my homepage.

    http://www.obry.net/contrib

Look for [GLUT for GNAT] section. Hope this helps.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|    http://www.obry.net  -  http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Opengl in Ada

[John B. Matthews]

In article <4ae886df$0$900$ba4acef3@news.orange.fr>,
 Pascal Obry <pascal@obry.net> wrote:

> Le 28/10/2009 18:12, Pablo a écrit :
> > Does someone know any tutorial of opengl in Ada? I found thousands
> > opengl tutorials, but none for Ada...
> 
> Tutorials no, but there is some OpenGL demos on my homepage.
> 
>     http://www.obry.net/contrib
> 
> Look for [GLUT for GNAT] section. Hope this helps.

I haven't built it in a while, but there are some examples here, also:

<https://sourceforge.net/projects/adaopengl/>

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

Re: Opengl in Ada

[Gautier write-only]

On 28 oct, 18:12, Pablo <pablit...@gmail.com> wrote:
> Does someone know any tutorial of opengl in Ada? I found thousands
> opengl tutorials, but none for Ada...

The good thing with opengl is that you can read a tutorial in any
language, it's the same opengl!
Only when it comes to exchange data (pictures) to and from the GL
system there are things specific to the language and bindings. In that
respect, I can only recommend *my* bindings ;-) which provide a GL.IO
with import of bmp's & tga's pictures for textures and export bmp's
for screenshots. In addition the identifiers are more Ada-like: you
write Normal(...) or GL.Normal(...) and not glnormal3d(...).
Look at the ./bindings directory in the GLOBE_3D project: http://globe3d.sf.net
Gautier

OpenGL in Ada

[Shark8]

Hello everyone,
I posted about wanting to write an OS in Ada a while ago and, as part
of that effort I've taken to translating the OpenGL API. No, I don't
mean JUST running the headers through ato-Ada converter but actually
translating the API into a more Ada-natural form.

As an example, here is the glColor-'family' of functions:
    * WINGDIAPI void APIENTRY glColor3b (GLbyte red, GLbyte green,
GLbyte blue);
    * WINGDIAPI void APIENTRY glColor3bv (const GLbyte *v);
    * WINGDIAPI void APIENTRY glColor3d (GLdouble red, GLdouble green,
GLdouble blue);
    * WINGDIAPI void APIENTRY glColor3dv (const GLdouble *v);
    * WINGDIAPI void APIENTRY glColor3f (GLfloat red, GLfloat green,
GLfloat blue);
    * WINGDIAPI void APIENTRY glColor3fv (const GLfloat *v);
    * WINGDIAPI void APIENTRY glColor3i (GLint red, GLint green, GLint
blue);
    * WINGDIAPI void APIENTRY glColor3iv (const GLint *v);
    * WINGDIAPI void APIENTRY glColor3s (GLshort red, GLshort green,
GLshort blue);
    * WINGDIAPI void APIENTRY glColor3sv (const GLshort *v);
    * WINGDIAPI void APIENTRY glColor3ub (GLubyte red, GLubyte green,
GLubyte blue);
    * WINGDIAPI void APIENTRY glColor3ubv (const GLubyte *v);
    * WINGDIAPI void APIENTRY glColor3ui (GLuint red, GLuint green,
GLuint blue);
    * WINGDIAPI void APIENTRY glColor3uiv (const GLuint *v);
    * WINGDIAPI void APIENTRY glColor3us (GLushort red, GLushort
green, GLushort blue);
    * WINGDIAPI void APIENTRY glColor3usv (const GLushort *v);
    * WINGDIAPI void APIENTRY glColor4b (GLbyte red, GLbyte green,
GLbyte blue, GLbyte alpha);
    * WINGDIAPI void APIENTRY glColor4bv (const GLbyte *v);
    * WINGDIAPI void APIENTRY glColor4d (GLdouble red, GLdouble green,
GLdouble blue, GLdouble alpha);
    * WINGDIAPI void APIENTRY glColor4dv (const GLdouble *v);
    * WINGDIAPI void APIENTRY glColor4f (GLfloat red, GLfloat green,
GLfloat blue, GLfloat alpha);
    * WINGDIAPI void APIENTRY glColor4fv (const GLfloat *v);
    * WINGDIAPI void APIENTRY glColor4i (GLint red, GLint green, GLint
blue, GLint alpha);
    * WINGDIAPI void APIENTRY glColor4iv (const GLint *v);
    * WINGDIAPI void APIENTRY glColor4s (GLshort red, GLshort green,
GLshort blue, GLshort alpha);
    * WINGDIAPI void APIENTRY glColor4sv (const GLshort *v);
    * WINGDIAPI void APIENTRY glColor4ub (GLubyte red, GLubyte green,
GLubyte blue, GLubyte alpha);
    * WINGDIAPI void APIENTRY glColor4ubv (const GLubyte *v);
    * WINGDIAPI void APIENTRY glColor4ui (GLuint red, GLuint green,
GLuint blue, GLuint alpha);
    * WINGDIAPI void APIENTRY glColor4uiv (const GLuint *v);
    * WINGDIAPI void APIENTRY glColor4us (GLushort red, GLushort
green, GLushort blue, GLushort alpha);
    * WINGDIAPI void APIENTRY glColor4usv (const GLushort *v);

which was rewritten as:
 -- Color Formats
 Procedure Color    ( red, green, blue : in Byte );
 Procedure Color    ( v : RGB_Byte_Vector );
 Procedure Color    ( red, green, blue : in double );
 Procedure Color    ( v : RGB_Double_Vector );
 Procedure Color    ( red, green, blue : in float );
 Procedure Color    ( V : RGB_Float_Vector );
 Procedure Color    ( red, green, blue : int );
 Procedure Color    ( V : RGB_Integer_Vector );
 Procedure Color    ( red, green, blue : Short );
 Procedure Color    ( V : RGB_Short_Vector );
 Procedure Color    ( red, green, blue : Unsigned_Byte );
 Procedure Color    ( v : RGB_Unsigned_Byte_Vector );
 Procedure Color    ( red, green, blue : in Unsigned_Integer );
 Procedure Color    ( v : RGB_Unsigned_Integer_Vector );
 Procedure Color    ( red, green, blue : in Unsigned_Short );
 Procedure Color    ( v : RGB_Unsigned_Short_Vector );
 Procedure Color    ( red, green, blue, alpha : in byte );
 Procedure Color    ( v: RGBA_Byte_Vector );
 Procedure Color    ( red, green, blue, alpha : in double );
 Procedure Color    ( v : RGBA_Double_Vector );
 Procedure Color    ( red, green, blue, alpha : in float );
 Procedure Color    ( v: RGBA_Float_Vector );
 Procedure Color    ( red, green, blue, alpha : in int );
 Procedure Color    ( v: RGBA_Integer_Vector );
 Procedure Color    ( red, green, blue, alpha : in short );
 Procedure Color    ( v: RGBA_Short_Vector );
 Procedure Color    ( red, green, blue, alpha : in Unsigned_Byte );
 Procedure Color    ( v: RGBA_Unsigned_Byte_Vector );
 Procedure Color    ( red, green, blue, alpha : in Unsigned_Integer );
 Procedure Color    ( v: RGBA_Unsigned_Integer_Vector );
 Procedure Color    ( red, green, blue, alpha : in Unsigned_Short );
 Procedure Color    ( v: RGBA_Unsigned_Short_Vector );

where X_Y_Vector is an array of elements of type Y and indexed on type
X.

Another thing that I've done is, to the best of my ability, used Ada's
strong typing to make passing invalid parameters less of a problem;
for example:
   Type Begin_Mode_Type is
     (	POINTS, LINES, LINE_LOOP, LINE_STRIP, TRIANGLES,
TRIANGLE_STRIP,
	TRIANGLE_FAN, QUADS, QUAD_STRIP, POLYGON
     );

    For Begin_Mode_Type use
     (	POINTS		=> GL_POINTS,
	LINES		=> GL_LINES,
	LINE_LOOP	=> GL_LINE_LOOP,
	LINE_STRIP	=> GL_LINE_STRIP,
	TRIANGLES	=> GL_TRIANGLES,
	TRIANGLE_STRIP	=> GL_TRIANGLE_STRIP,
	TRIANGLE_FAN	=> GL_TRIANGLE_FAN,
	QUADS		=> GL_QUADS,
	QUAD_STRIP	=> GL_QUAD_STRIP,
	POLYGON		=> GL_POLYGON
     );

is a type for the glBegin-wrapper which only allows the  passing of
valid "mode"-parameters. {That is, range points..polygon.}

My questions are these:
Would anyone, other than myself, find such a translation of interest?
and
When I finish, would anyone want to test it out?

Re: OpenGL in Ada

[John B. Matthews]

In article 
<68dd0333-f502-4351-9e50-4ec83bddc44e@k39g2000yqd.googlegroups.com>,
 Shark8 <onewingedshark@gmail.com> wrote:

> Would anyone, other than myself, find such a translation of interest?

I have used AdaOpenGL in the past. Is your project related in any way?

<http://adaopengl.sourceforge.net/>

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

Re: OpenGL in Ada

[anon]

In <nospam-8BBB96.10151708072010@news.aioe.org>, "John B. Matthews" <nospam@nospam.invalid> writes:
>In article 
><68dd0333-f502-4351-9e50-4ec83bddc44e@k39g2000yqd.googlegroups.com>,
> Shark8 <onewingedshark@gmail.com> wrote:
>
>> Would anyone, other than myself, find such a translation of interest?
>
>I have used AdaOpenGL in the past. Is your project related in any way?
>
><http://adaopengl.sourceforge.net/>
>
>-- 
>John B. Matthews
>trashgod at gmail dot com
><http://sites.google.com/site/drjohnbmatthews>

But the last time I downloaded the packages they needed a few 
modifications for the current GNAT and OpenGL standards that I was using.  
but it was no problem. And with these APIs packages all you would need 
to do is replace the openGL libraries calls with the actual routines.

Have fun! Let us know when it ready for testing!

Re: OpenGL in Ada

[Gautier write-only]

On Jul 7, 10:42 pm, Shark8 <onewingedsh...@gmail.com> wrote:
> Hello everyone,
> I posted about wanting to write an OS in Ada a while ago and, as part
> of that effort I've taken to translating the OpenGL API. No, I don't
> mean JUST running the headers through ato-Ada converter but actually
> translating the API into a more Ada-natural form.
...
> My questions are these:
> Would anyone, other than myself, find such a translation of interest?
> and
> When I finish, would anyone want to test it out?

You may save lots of work by looking at the GL bindings there
http://globe3d.sf.net
which are also Ada-ized (overloaded names, all useless gl* and GL_*
stripped)
Have fun,
Gautier

Re: OpenGL in Ada

[Gene]

On Jul 7, 10:42 pm, Shark8 <onewingedsh...@gmail.com> wrote:
> Hello everyone,
> I posted about wanting to write an OS in Ada a while ago and, as part
> of that effort I've taken to translating the OpenGL API. No, I don't
> mean JUST running the headers through ato-Ada converter but actually
> translating the API into a more Ada-natural form.
>
> As an example, here is the glColor-'family' of functions:
>     * WINGDIAPI void APIENTRY glColor3b (GLbyte red, GLbyte green,
> GLbyte blue);
>     * WINGDIAPI void APIENTRY glColor3bv (const GLbyte *v);
>     * WINGDIAPI void APIENTRY glColor3d (GLdouble red, GLdouble green,
> GLdouble blue);
>     * WINGDIAPI void APIENTRY glColor3dv (const GLdouble *v);
>     * WINGDIAPI void APIENTRY glColor3f (GLfloat red, GLfloat green,
> GLfloat blue);
>     * WINGDIAPI void APIENTRY glColor3fv (const GLfloat *v);
>     * WINGDIAPI void APIENTRY glColor3i (GLint red, GLint green, GLint
> blue);
>     * WINGDIAPI void APIENTRY glColor3iv (const GLint *v);
>     * WINGDIAPI void APIENTRY glColor3s (GLshort red, GLshort green,
> GLshort blue);
>     * WINGDIAPI void APIENTRY glColor3sv (const GLshort *v);
>     * WINGDIAPI void APIENTRY glColor3ub (GLubyte red, GLubyte green,
> GLubyte blue);
>     * WINGDIAPI void APIENTRY glColor3ubv (const GLubyte *v);
>     * WINGDIAPI void APIENTRY glColor3ui (GLuint red, GLuint green,
> GLuint blue);
>     * WINGDIAPI void APIENTRY glColor3uiv (const GLuint *v);
>     * WINGDIAPI void APIENTRY glColor3us (GLushort red, GLushort
> green, GLushort blue);
>     * WINGDIAPI void APIENTRY glColor3usv (const GLushort *v);
>     * WINGDIAPI void APIENTRY glColor4b (GLbyte red, GLbyte green,
> GLbyte blue, GLbyte alpha);
>     * WINGDIAPI void APIENTRY glColor4bv (const GLbyte *v);
>     * WINGDIAPI void APIENTRY glColor4d (GLdouble red, GLdouble green,
> GLdouble blue, GLdouble alpha);
>     * WINGDIAPI void APIENTRY glColor4dv (const GLdouble *v);
>     * WINGDIAPI void APIENTRY glColor4f (GLfloat red, GLfloat green,
> GLfloat blue, GLfloat alpha);
>     * WINGDIAPI void APIENTRY glColor4fv (const GLfloat *v);
>     * WINGDIAPI void APIENTRY glColor4i (GLint red, GLint green, GLint
> blue, GLint alpha);
>     * WINGDIAPI void APIENTRY glColor4iv (const GLint *v);
>     * WINGDIAPI void APIENTRY glColor4s (GLshort red, GLshort green,
> GLshort blue, GLshort alpha);
>     * WINGDIAPI void APIENTRY glColor4sv (const GLshort *v);
>     * WINGDIAPI void APIENTRY glColor4ub (GLubyte red, GLubyte green,
> GLubyte blue, GLubyte alpha);
>     * WINGDIAPI void APIENTRY glColor4ubv (const GLubyte *v);
>     * WINGDIAPI void APIENTRY glColor4ui (GLuint red, GLuint green,
> GLuint blue, GLuint alpha);
>     * WINGDIAPI void APIENTRY glColor4uiv (const GLuint *v);
>     * WINGDIAPI void APIENTRY glColor4us (GLushort red, GLushort
> green, GLushort blue, GLushort alpha);
>     * WINGDIAPI void APIENTRY glColor4usv (const GLushort *v);
>
> which was rewritten as:
>  -- Color Formats
>  Procedure Color    ( red, green, blue : in Byte );
>  Procedure Color    ( v : RGB_Byte_Vector );
>  Procedure Color    ( red, green, blue : in double );
>  Procedure Color    ( v : RGB_Double_Vector );
>  Procedure Color    ( red, green, blue : in float );
>  Procedure Color    ( V : RGB_Float_Vector );
>  Procedure Color    ( red, green, blue : int );
>  Procedure Color    ( V : RGB_Integer_Vector );
>  Procedure Color    ( red, green, blue : Short );
>  Procedure Color    ( V : RGB_Short_Vector );
>  Procedure Color    ( red, green, blue : Unsigned_Byte );
>  Procedure Color    ( v : RGB_Unsigned_Byte_Vector );
>  Procedure Color    ( red, green, blue : in Unsigned_Integer );
>  Procedure Color    ( v : RGB_Unsigned_Integer_Vector );
>  Procedure Color    ( red, green, blue : in Unsigned_Short );
>  Procedure Color    ( v : RGB_Unsigned_Short_Vector );
>  Procedure Color    ( red, green, blue, alpha : in byte );
>  Procedure Color    ( v: RGBA_Byte_Vector );
>  Procedure Color    ( red, green, blue, alpha : in double );
>  Procedure Color    ( v : RGBA_Double_Vector );
>  Procedure Color    ( red, green, blue, alpha : in float );
>  Procedure Color    ( v: RGBA_Float_Vector );
>  Procedure Color    ( red, green, blue, alpha : in int );
>  Procedure Color    ( v: RGBA_Integer_Vector );
>  Procedure Color    ( red, green, blue, alpha : in short );
>  Procedure Color    ( v: RGBA_Short_Vector );
>  Procedure Color    ( red, green, blue, alpha : in Unsigned_Byte );
>  Procedure Color    ( v: RGBA_Unsigned_Byte_Vector );
>  Procedure Color    ( red, green, blue, alpha : in Unsigned_Integer );
>  Procedure Color    ( v: RGBA_Unsigned_Integer_Vector );
>  Procedure Color    ( red, green, blue, alpha : in Unsigned_Short );
>  Procedure Color    ( v: RGBA_Unsigned_Short_Vector );
>
> where X_Y_Vector is an array of elements of type Y and indexed on type
> X.
>
> Another thing that I've done is, to the best of my ability, used Ada's
> strong typing to make passing invalid parameters less of a problem;
> for example:
>    Type Begin_Mode_Type is
>      (  POINTS, LINES, LINE_LOOP, LINE_STRIP, TRIANGLES,
> TRIANGLE_STRIP,
>         TRIANGLE_FAN, QUADS, QUAD_STRIP, POLYGON
>      );
>
>     For Begin_Mode_Type use
>      (  POINTS          => GL_POINTS,
>         LINES           => GL_LINES,
>         LINE_LOOP       => GL_LINE_LOOP,
>         LINE_STRIP      => GL_LINE_STRIP,
>         TRIANGLES       => GL_TRIANGLES,
>         TRIANGLE_STRIP  => GL_TRIANGLE_STRIP,
>         TRIANGLE_FAN    => GL_TRIANGLE_FAN,
>         QUADS           => GL_QUADS,
>         QUAD_STRIP      => GL_QUAD_STRIP,
>         POLYGON         => GL_POLYGON
>      );
>
> is a type for the glBegin-wrapper which only allows the  passing of
> valid "mode"-parameters. {That is, range points..polygon.}
>
> My questions are these:
> Would anyone, other than myself, find such a translation of interest?
> and
> When I finish, would anyone want to test it out?

Having done this a couple of times myself, you should consider the
approach of writing a specialized program that processes the OpenGL
header into a binding.  OpenGL will remain a moving target as graphics
hardware continues to evolve.  Compilers will always have their unique
quirks.  With all this room for variation, it will probably be easier
to maintain a translator than to revise the binding every time the
standard changes or grows.

Re: OpenGL in Ada

[Shark8]

On Jul 9, 9:11 am, Gene <gene.ress...@gmail.com> wrote:
> On Jul 7, 10:42 pm, Shark8 <onewingedsh...@gmail.com> wrote:
>
>
>
> > Hello everyone,
> > I posted about wanting to write an OS in Ada a while ago and, as part
> > of that effort I've taken to translating the OpenGL API. No, I don't
> > mean JUST running the headers through ato-Ada converter but actually
> > translating the API into a more Ada-natural form.
>
> > As an example, here is the glColor-'family' of functions:
> >     * WINGDIAPI void APIENTRY glColor3b (GLbyte red, GLbyte green,
> > GLbyte blue);
> >     * WINGDIAPI void APIENTRY glColor3bv (const GLbyte *v);
> >     * WINGDIAPI void APIENTRY glColor3d (GLdouble red, GLdouble green,
> > GLdouble blue);
> >     * WINGDIAPI void APIENTRY glColor3dv (const GLdouble *v);
> >     * WINGDIAPI void APIENTRY glColor3f (GLfloat red, GLfloat green,
> > GLfloat blue);
> >     * WINGDIAPI void APIENTRY glColor3fv (const GLfloat *v);
> >     * WINGDIAPI void APIENTRY glColor3i (GLint red, GLint green, GLint
> > blue);
> >     * WINGDIAPI void APIENTRY glColor3iv (const GLint *v);
> >     * WINGDIAPI void APIENTRY glColor3s (GLshort red, GLshort green,
> > GLshort blue);
> >     * WINGDIAPI void APIENTRY glColor3sv (const GLshort *v);
> >     * WINGDIAPI void APIENTRY glColor3ub (GLubyte red, GLubyte green,
> > GLubyte blue);
> >     * WINGDIAPI void APIENTRY glColor3ubv (const GLubyte *v);
> >     * WINGDIAPI void APIENTRY glColor3ui (GLuint red, GLuint green,
> > GLuint blue);
> >     * WINGDIAPI void APIENTRY glColor3uiv (const GLuint *v);
> >     * WINGDIAPI void APIENTRY glColor3us (GLushort red, GLushort
> > green, GLushort blue);
> >     * WINGDIAPI void APIENTRY glColor3usv (const GLushort *v);
> >     * WINGDIAPI void APIENTRY glColor4b (GLbyte red, GLbyte green,
> > GLbyte blue, GLbyte alpha);
> >     * WINGDIAPI void APIENTRY glColor4bv (const GLbyte *v);
> >     * WINGDIAPI void APIENTRY glColor4d (GLdouble red, GLdouble green,
> > GLdouble blue, GLdouble alpha);
> >     * WINGDIAPI void APIENTRY glColor4dv (const GLdouble *v);
> >     * WINGDIAPI void APIENTRY glColor4f (GLfloat red, GLfloat green,
> > GLfloat blue, GLfloat alpha);
> >     * WINGDIAPI void APIENTRY glColor4fv (const GLfloat *v);
> >     * WINGDIAPI void APIENTRY glColor4i (GLint red, GLint green, GLint
> > blue, GLint alpha);
> >     * WINGDIAPI void APIENTRY glColor4iv (const GLint *v);
> >     * WINGDIAPI void APIENTRY glColor4s (GLshort red, GLshort green,
> > GLshort blue, GLshort alpha);
> >     * WINGDIAPI void APIENTRY glColor4sv (const GLshort *v);
> >     * WINGDIAPI void APIENTRY glColor4ub (GLubyte red, GLubyte green,
> > GLubyte blue, GLubyte alpha);
> >     * WINGDIAPI void APIENTRY glColor4ubv (const GLubyte *v);
> >     * WINGDIAPI void APIENTRY glColor4ui (GLuint red, GLuint green,
> > GLuint blue, GLuint alpha);
> >     * WINGDIAPI void APIENTRY glColor4uiv (const GLuint *v);
> >     * WINGDIAPI void APIENTRY glColor4us (GLushort red, GLushort
> > green, GLushort blue, GLushort alpha);
> >     * WINGDIAPI void APIENTRY glColor4usv (const GLushort *v);
>
> > which was rewritten as:
> >  -- Color Formats
> >  Procedure Color    ( red, green, blue : in Byte );
> >  Procedure Color    ( v : RGB_Byte_Vector );
> >  Procedure Color    ( red, green, blue : in double );
> >  Procedure Color    ( v : RGB_Double_Vector );
> >  Procedure Color    ( red, green, blue : in float );
> >  Procedure Color    ( V : RGB_Float_Vector );
> >  Procedure Color    ( red, green, blue : int );
> >  Procedure Color    ( V : RGB_Integer_Vector );
> >  Procedure Color    ( red, green, blue : Short );
> >  Procedure Color    ( V : RGB_Short_Vector );
> >  Procedure Color    ( red, green, blue : Unsigned_Byte );
> >  Procedure Color    ( v : RGB_Unsigned_Byte_Vector );
> >  Procedure Color    ( red, green, blue : in Unsigned_Integer );
> >  Procedure Color    ( v : RGB_Unsigned_Integer_Vector );
> >  Procedure Color    ( red, green, blue : in Unsigned_Short );
> >  Procedure Color    ( v : RGB_Unsigned_Short_Vector );
> >  Procedure Color    ( red, green, blue, alpha : in byte );
> >  Procedure Color    ( v: RGBA_Byte_Vector );
> >  Procedure Color    ( red, green, blue, alpha : in double );
> >  Procedure Color    ( v : RGBA_Double_Vector );
> >  Procedure Color    ( red, green, blue, alpha : in float );
> >  Procedure Color    ( v: RGBA_Float_Vector );
> >  Procedure Color    ( red, green, blue, alpha : in int );
> >  Procedure Color    ( v: RGBA_Integer_Vector );
> >  Procedure Color    ( red, green, blue, alpha : in short );
> >  Procedure Color    ( v: RGBA_Short_Vector );
> >  Procedure Color    ( red, green, blue, alpha : in Unsigned_Byte );
> >  Procedure Color    ( v: RGBA_Unsigned_Byte_Vector );
> >  Procedure Color    ( red, green, blue, alpha : in Unsigned_Integer );
> >  Procedure Color    ( v: RGBA_Unsigned_Integer_Vector );
> >  Procedure Color    ( red, green, blue, alpha : in Unsigned_Short );
> >  Procedure Color    ( v: RGBA_Unsigned_Short_Vector );
>
> > where X_Y_Vector is an array of elements of type Y and indexed on type
> > X.
>
> > Another thing that I've done is, to the best of my ability, used Ada's
> > strong typing to make passing invalid parameters less of a problem;
> > for example:
> >    Type Begin_Mode_Type is
> >      (  POINTS, LINES, LINE_LOOP, LINE_STRIP, TRIANGLES,
> > TRIANGLE_STRIP,
> >         TRIANGLE_FAN, QUADS, QUAD_STRIP, POLYGON
> >      );
>
> >     For Begin_Mode_Type use
> >      (  POINTS          => GL_POINTS,
> >         LINES           => GL_LINES,
> >         LINE_LOOP       => GL_LINE_LOOP,
> >         LINE_STRIP      => GL_LINE_STRIP,
> >         TRIANGLES       => GL_TRIANGLES,
> >         TRIANGLE_STRIP  => GL_TRIANGLE_STRIP,
> >         TRIANGLE_FAN    => GL_TRIANGLE_FAN,
> >         QUADS           => GL_QUADS,
> >         QUAD_STRIP      => GL_QUAD_STRIP,
> >         POLYGON         => GL_POLYGON
> >      );
>
> > is a type for the glBegin-wrapper which only allows the  passing of
> > valid "mode"-parameters. {That is, range points..polygon.}
>
> > My questions are these:
> > Would anyone, other than myself, find such a translation of interest?
> > and
> > When I finish, would anyone want to test it out?
>
> Having done this a couple of times myself, you should consider the
> approach of writing a specialized program that processes the OpenGL
> header into a binding.  OpenGL will remain a moving target as graphics
> hardware continues to evolve.  Compilers will always have their unique
> quirks.  With all this room for variation, it will probably be easier
> to maintain a translator than to revise the binding every time the
> standard changes or grows.

I see what you're saying. The problem is in the specs, the moving
target you mentioned, for example the glBegin function could be
extended to take a new enumeration, say, GL_AWESOME! This disrupts the
allowable inputs for glBegin, now we have a non-contiguous range of
GL_POINTS..GL_POLYGON & GL_AWESOME..GL_AWESOME since these are
constants instead of true enumeration-types {thank you c/c++} and the
glFUNCTIONs take a 32-bit value as the "enumeration."

Basically it's the result of a) lack of foresight, and b) lazy
programming.

Re: OpenGL in Ada

[Gene]

On Jul 9, 1:38 pm, Shark8 <onewingedsh...@gmail.com> wrote:
> On Jul 9, 9:11 am, Gene <gene.ress...@gmail.com> wrote:
>
>
>
>
>
> > On Jul 7, 10:42 pm, Shark8 <onewingedsh...@gmail.com> wrote:
>
> > > Hello everyone,
> > > I posted about wanting to write an OS in Ada a while ago and, as part
> > > of that effort I've taken to translating the OpenGL API. No, I don't
> > > mean JUST running the headers through ato-Ada converter but actually
> > > translating the API into a more Ada-natural form.
>
> > > As an example, here is the glColor-'family' of functions:
> > >     * WINGDIAPI void APIENTRY glColor3b (GLbyte red, GLbyte green,
> > > GLbyte blue);
> > >     * WINGDIAPI void APIENTRY glColor3bv (const GLbyte *v);
> > >     * WINGDIAPI void APIENTRY glColor3d (GLdouble red, GLdouble green,
> > > GLdouble blue);
> > >     * WINGDIAPI void APIENTRY glColor3dv (const GLdouble *v);
> > >     * WINGDIAPI void APIENTRY glColor3f (GLfloat red, GLfloat green,
> > > GLfloat blue);
> > >     * WINGDIAPI void APIENTRY glColor3fv (const GLfloat *v);
> > >     * WINGDIAPI void APIENTRY glColor3i (GLint red, GLint green, GLint
> > > blue);
> > >     * WINGDIAPI void APIENTRY glColor3iv (const GLint *v);
> > >     * WINGDIAPI void APIENTRY glColor3s (GLshort red, GLshort green,
> > > GLshort blue);
> > >     * WINGDIAPI void APIENTRY glColor3sv (const GLshort *v);
> > >     * WINGDIAPI void APIENTRY glColor3ub (GLubyte red, GLubyte green,
> > > GLubyte blue);
> > >     * WINGDIAPI void APIENTRY glColor3ubv (const GLubyte *v);
> > >     * WINGDIAPI void APIENTRY glColor3ui (GLuint red, GLuint green,
> > > GLuint blue);
> > >     * WINGDIAPI void APIENTRY glColor3uiv (const GLuint *v);
> > >     * WINGDIAPI void APIENTRY glColor3us (GLushort red, GLushort
> > > green, GLushort blue);
> > >     * WINGDIAPI void APIENTRY glColor3usv (const GLushort *v);
> > >     * WINGDIAPI void APIENTRY glColor4b (GLbyte red, GLbyte green,
> > > GLbyte blue, GLbyte alpha);
> > >     * WINGDIAPI void APIENTRY glColor4bv (const GLbyte *v);
> > >     * WINGDIAPI void APIENTRY glColor4d (GLdouble red, GLdouble green,
> > > GLdouble blue, GLdouble alpha);
> > >     * WINGDIAPI void APIENTRY glColor4dv (const GLdouble *v);
> > >     * WINGDIAPI void APIENTRY glColor4f (GLfloat red, GLfloat green,
> > > GLfloat blue, GLfloat alpha);
> > >     * WINGDIAPI void APIENTRY glColor4fv (const GLfloat *v);
> > >     * WINGDIAPI void APIENTRY glColor4i (GLint red, GLint green, GLint
> > > blue, GLint alpha);
> > >     * WINGDIAPI void APIENTRY glColor4iv (const GLint *v);
> > >     * WINGDIAPI void APIENTRY glColor4s (GLshort red, GLshort green,
> > > GLshort blue, GLshort alpha);
> > >     * WINGDIAPI void APIENTRY glColor4sv (const GLshort *v);
> > >     * WINGDIAPI void APIENTRY glColor4ub (GLubyte red, GLubyte green,
> > > GLubyte blue, GLubyte alpha);
> > >     * WINGDIAPI void APIENTRY glColor4ubv (const GLubyte *v);
> > >     * WINGDIAPI void APIENTRY glColor4ui (GLuint red, GLuint green,
> > > GLuint blue, GLuint alpha);
> > >     * WINGDIAPI void APIENTRY glColor4uiv (const GLuint *v);
> > >     * WINGDIAPI void APIENTRY glColor4us (GLushort red, GLushort
> > > green, GLushort blue, GLushort alpha);
> > >     * WINGDIAPI void APIENTRY glColor4usv (const GLushort *v);
>
> > > which was rewritten as:
> > >  -- Color Formats
> > >  Procedure Color    ( red, green, blue : in Byte );
> > >  Procedure Color    ( v : RGB_Byte_Vector );
> > >  Procedure Color    ( red, green, blue : in double );
> > >  Procedure Color    ( v : RGB_Double_Vector );
> > >  Procedure Color    ( red, green, blue : in float );
> > >  Procedure Color    ( V : RGB_Float_Vector );
> > >  Procedure Color    ( red, green, blue : int );
> > >  Procedure Color    ( V : RGB_Integer_Vector );
> > >  Procedure Color    ( red, green, blue : Short );
> > >  Procedure Color    ( V : RGB_Short_Vector );
> > >  Procedure Color    ( red, green, blue : Unsigned_Byte );
> > >  Procedure Color    ( v : RGB_Unsigned_Byte_Vector );
> > >  Procedure Color    ( red, green, blue : in Unsigned_Integer );
> > >  Procedure Color    ( v : RGB_Unsigned_Integer_Vector );
> > >  Procedure Color    ( red, green, blue : in Unsigned_Short );
> > >  Procedure Color    ( v : RGB_Unsigned_Short_Vector );
> > >  Procedure Color    ( red, green, blue, alpha : in byte );
> > >  Procedure Color    ( v: RGBA_Byte_Vector );
> > >  Procedure Color    ( red, green, blue, alpha : in double );
> > >  Procedure Color    ( v : RGBA_Double_Vector );
> > >  Procedure Color    ( red, green, blue, alpha : in float );
> > >  Procedure Color    ( v: RGBA_Float_Vector );
> > >  Procedure Color    ( red, green, blue, alpha : in int );
> > >  Procedure Color    ( v: RGBA_Integer_Vector );
> > >  Procedure Color    ( red, green, blue, alpha : in short );
> > >  Procedure Color    ( v: RGBA_Short_Vector );
> > >  Procedure Color    ( red, green, blue, alpha : in Unsigned_Byte );
> > >  Procedure Color    ( v: RGBA_Unsigned_Byte_Vector );
> > >  Procedure Color    ( red, green, blue, alpha : in Unsigned_Integer );
> > >  Procedure Color    ( v: RGBA_Unsigned_Integer_Vector );
> > >  Procedure Color    ( red, green, blue, alpha : in Unsigned_Short );
> > >  Procedure Color    ( v: RGBA_Unsigned_Short_Vector );
>
> > > where X_Y_Vector is an array of elements of type Y and indexed on type
> > > X.
>
> > > Another thing that I've done is, to the best of my ability, used Ada's
> > > strong typing to make passing invalid parameters less of a problem;
> > > for example:
> > >    Type Begin_Mode_Type is
> > >      (  POINTS, LINES, LINE_LOOP, LINE_STRIP, TRIANGLES,
> > > TRIANGLE_STRIP,
> > >         TRIANGLE_FAN, QUADS, QUAD_STRIP, POLYGON
> > >      );
>
> > >     For Begin_Mode_Type use
> > >      (  POINTS          => GL_POINTS,
> > >         LINES           => GL_LINES,
> > >         LINE_LOOP       => GL_LINE_LOOP,
> > >         LINE_STRIP      => GL_LINE_STRIP,
> > >         TRIANGLES       => GL_TRIANGLES,
> > >         TRIANGLE_STRIP  => GL_TRIANGLE_STRIP,
> > >         TRIANGLE_FAN    => GL_TRIANGLE_FAN,
> > >         QUADS           => GL_QUADS,
> > >         QUAD_STRIP      => GL_QUAD_STRIP,
> > >         POLYGON         => GL_POLYGON
> > >      );
>
> > > is a type for the glBegin-wrapper which only allows the  passing of
> > > valid "mode"-parameters. {That is, range points..polygon.}
>
> > > My questions are these:
> > > Would anyone, other than myself, find such a translation of interest?
> > > and
> > > When I finish, would anyone want to test it out?
>
> > Having done this a couple of times myself, you should consider the
> > approach of writing a specialized program that processes the OpenGL
> > header into a binding.  OpenGL will remain a moving target as graphics
> > hardware continues to evolve.  Compilers will always have their unique
> > quirks.  With all this room for variation, it will probably be easier
> > to maintain a translator than to revise the binding every time the
> > standard changes or grows.
>
> I see what you're saying. The problem is in the specs, the moving
> target you mentioned, for example the glBegin function could be
> extended to take a new enumeration, say, GL_AWESOME! This disrupts the
> allowable inputs for glBegin, now we have a non-contiguous range of
> GL_POINTS..GL_POLYGON & GL_AWESOME..GL_AWESOME since these are
> constants instead of true enumeration-types {thank you c/c++} and the
> glFUNCTIONs take a 32-bit value as the "enumeration."
>
> Basically it's the result of a) lack of foresight, and b) lazy
> programming.

Well, plus the need for backward compatibility.

Nonetheless, if you have isolated the need to identify glBegin args in
a table within a translator, so it can spit out the requisite new
enumeration equivalences, I believe you are ahead of the game.  No one
is saying the translator will keep working with zero modifications.

For (an admittedly contrived) example, if the spec introduces a new
call that accepts anything glBegin will accept plus a few other flags,
the translator can encode this idea in a new addendum table and an
algorithm. This is easier and less error prone going forward than
remembering to update both enumerations in parallel.

Re: OpenGL in Ada

[BrianG]

Shark8 wrote:
> On Jul 9, 9:11 am, Gene <gene.ress...@gmail.com> wrote:
>> On Jul 7, 10:42 pm, Shark8 <onewingedsh...@gmail.com> wrote:
>>> Hello everyone,
>>> I posted about wanting to write an OS in Ada a while ago and, as part
>>> of that effort I've taken to translating the OpenGL API. No, I don't
>>> mean JUST running the headers through ato-Ada converter but actually
>>> translating the API into a more Ada-natural form.
>>> As an example, here is the glColor-'family' of functions:
...
>>> which was rewritten as:
>>>  -- Color Formats
>>>  Procedure Color    ( red, green, blue : in Byte );
>>>  Procedure Color    ( v : RGB_Byte_Vector );
>>>  Procedure Color    ( red, green, blue : in double );
>>>  Procedure Color    ( v : RGB_Double_Vector );
>>>  Procedure Color    ( red, green, blue : in float );
>>>  Procedure Color    ( V : RGB_Float_Vector );
>>>  Procedure Color    ( red, green, blue : int );

One problem you'll have is if a user wants to make a call with all 
literals, i.e. Color(1, 2, 3) or Color(1.0, 2.0, 3.0), the compiler 
won't know which version to use.  The best solution I've found (besides 
making users specify a type) is to have a second name which is defined 
for int and float only (or whatever the default is), but I've come up 
with no good format for the second name:  Color_Literal, Color_L, 
Color1, ...?

(I've tried starting a similar effort, but never got very far.  I was 
using the OpenGL "red book" as a basis; I find it interesting that the 
OpenGL definition recognizes that "some languages like Ada and C++" 
could implement names this way, but every Ada library I've seen follows 
the C naming scheme.)

Re: OpenGL in Ada

[Gautier write-only]

On 10 juil, 06:00, BrianG wrote:

> One problem you'll have is if a user wants to make a call with all
> literals, i.e. Color(1, 2, 3) or Color(1.0, 2.0, 3.0), the
> compiler won't know which version to use.

Sure it will know!
The confusion is rather when the GL.Float and the GL.Double versions
are named Color. One solution is to choose one type as "most common"
per category (floating-point, integer), and for instance name "Color"
for GL.Double and Color_f for GL.Float:

http://globe3d.sourceforge.net/g3d_html/gl__ads.htm#3437_13

There is also an automatic tool to generate these parts of bindings in
a consistent manner, with Import pragmata etc. - just use it (or the
binding itself...).

G.

Re: OpenGL in Ada

[BrianG]

Gautier write-only wrote:
> On 10 juil, 06:00, BrianG wrote:
> 
>> One problem you'll have is if a user wants to make a call with all
>> literals, i.e. Color(1, 2, 3) or Color(1.0, 2.0, 3.0), the
>> compiler won't know which version to use.
> 
> Sure it will know!
> The confusion is rather when the GL.Float and the GL.Double versions
> are named Color. One solution is to choose one type as "most common"
> per category (floating-point, integer), and for instance name "Color"
> for GL.Double and Color_f for GL.Float:
> 
> http://globe3d.sourceforge.net/g3d_html/gl__ads.htm#3437_13
> 
> There is also an automatic tool to generate these parts of bindings in
> a consistent manner, with Import pragmata etc. - just use it (or the
> binding itself...).
> 
> G.

I don't understand your "rather"; that's exactly my point.  See the 
start of my post.

This doesn't just apply to Float/Double, it also applies to 
Byte/Short/Int/Long (etc.).  That's why I specifically included those 
versions of the calls in my post.

What you have is a way to do it, but that's not what the OP posted.  He 
had all procedures named Color, so the user doesn't need to worry about 
implementation.  (If I use Color for Double and want to change my 
program to use Float, I have to change the names of all calls, even if I 
use calls where the compiler could determine what I want - and not just 
calls to Color, many routines would have the same issue.)  This is also 
what the OpenGL documentation implies should be done in a language like Ada.

You could have both Color and Color_F for Float (which is part of what 
my point was).  Then you could also have Color and Color_I for Int, 
which was the other part of my point:  Color_F and Color_I don't have to 
have different names.  If there's only one version for each category, 
they could be overloaded.  My problem is I can't come up with an obvious 
  second name.  Color_F and Color_I (etc) are obvious and simple, so 
maybe that's the best option.

(My defintion of "obvious and simple" is:  I write a program without 
worrying about (or thinking of) this issue, the compile complains where 
I use only literals, and I change the needed names.  I'd like the name 
change to be as easy and obvious as possible.  That's why I thought 
having only two names would be ideal - the 'normal' name and the 'oops' 
name.  Possibly using multiple second names is the only practical 
option.  I'd still like to keep all versions of the 'normal' name, since 
I don't always need to specify the type - otherwise, you might as well 
keep all of the suffixes used by C - especially if the 'default' is the 
one used most often.)

Re: OpenGL in Ada

[Gautier write-only]

On Jul 11, 4:45 am, BrianG <briang...@gmail.com> wrote:

> I don't understand your "rather"; that's exactly my point.  See the
> start of my post.

Sorry, I misunderstood you.

...
> My problem is I can't come up with an obvious
> second name.  Color_F and Color_I (etc) are obvious and simple, so
> maybe that's the best option.

In my opinion it is. It is the closest to the full overloading to
"Color", but avoiding the problem with litterals. Then you can have
also have also "Color" for one of the fp types, same for one of the
integer types.

G.

Re: OpenGL in Ada

[tmoran]

> >>>  Procedure Color    ( red, green, blue : in double );
> >>>  Procedure Color    ( red, green, blue : in float );
>
> One problem you'll have is if a user wants to make a call with all
> literals, i.e. Color(1, 2, 3) or Color(1.0, 2.0, 3.0), the compiler
> won't know which version to use.  The best solution I've found (besides
> making users specify a type)

And what's wrong with requiring the user to be unambiguous by specifying
a type?  It's unlikely there will be a lot of calls with all literals
(unless generated by some program) so it shouldn't be onerous.  And
"Float'(1.0)" is clearer to the person reading the code five years
from now than "Color_F".

Re: OpenGL in Ada

[anon]

In <i1bktn$ucj$1@speranza.aioe.org>, tmoran@acm.org writes:
>> >>>  Procedure Color    ( red, green, blue : in double );
>> >>>  Procedure Color    ( red, green, blue : in float );
>>
>> One problem you'll have is if a user wants to make a call with all
>> literals, i.e. Color(1, 2, 3) or Color(1.0, 2.0, 3.0), the compiler
>> won't know which version to use.  The best solution I've found (besides
>> making users specify a type)
>
>And what's wrong with requiring the user to be unambiguous by specifying
>a type?  It's unlikely there will be a lot of calls with all literals
>(unless generated by some program) so it shouldn't be onerous.  And
>"Float'(1.0)" is clearer to the person reading the code five years
>from now than "Color_F".


What your are forgetting is the openGL is a specification from the openGL 
group ( opengl.org ), it is just like the Ada RM in that respect.  For a 
program or package, to be classified as openGL it must comply with "openGL 
group" openGL specification.  Changing any API part nullify the use of 
openGL in any part of your system.

So, adding or altering any definitions about the given API must comply with 
the openGL specification. Names of the API functions and procedures with 
the API defined types are set by this openGL group.

visit 
www.opengl.org
for more information on openGL and the "openGL group"

Also, you may find the API specifications predefined with examples in C that 
you can alter to Ada there as well.

Re: OpenGL in Ada

[Shark8]

On Jul 11, 2:46 pm, a...@att.net wrote:
> In <i1bktn$uc...@speranza.aioe.org>, tmo...@acm.org writes:
> >> >>>  Procedure Color    ( red, green, blue : in double );
> >> >>>  Procedure Color    ( red, green, blue : in float );
>
> >> One problem you'll have is if a user wants to make a call with all
> >> literals, i.e. Color(1, 2, 3) or Color(1.0, 2.0, 3.0), the compiler
> >> won't know which version to use.  The best solution I've found (besides
> >> making users specify a type)
>
> >And what's wrong with requiring the user to be unambiguous by specifying
> >a type?  It's unlikely there will be a lot of calls with all literals
> >(unless generated by some program) so it shouldn't be onerous.  And
> >"Float'(1.0)" is clearer to the person reading the code five years
> >from now than "Color_F".
>
> What your are forgetting is the openGL is a specification from the openGL
> group ( opengl.org ), it is just like the Ada RM in that respect.  For a
> program or package, to be classified as openGL it must comply with "openGL
> group" openGL specification.  Changing any API part nullify the use of
> openGL in any part of your system.
>
> So, adding or altering any definitions about the given API must comply with
> the openGL specification. Names of the API functions and procedures with
> the API defined types are set by this openGL group.

That seems, on its face, to contradict BrianG's claim:

> What you have is a way to do it, but that's not what the OP posted.  He had
> all procedures named Color, so the user doesn't need to worry about
> implementation.  (If I use Color for Double and want to change my program to
> use Float, I have to change the names of all calls, even if I use calls where
> the compiler could determine what I want - and not just calls to Color, many
> routines would have the same issue.)  This is also what the OpenGL
> documentation implies should be done in a language like Ada.

But, if he's correct in this earlier post:
> (I've tried starting a similar effort, but never got very far.  I was using
> the OpenGL "red book" as a basis; I find it interesting that the OpenGL
> definition recognizes that "some languages like Ada and C++" could implement
> names this way, but every Ada library I've seen follows the C naming scheme.)

Then my renaming (to get rid of the gl- prefix and parameter-type-
postfix) and
overloading them all is a valid OpenGL API.

>
> visitwww.opengl.org
> for more information on openGL and the "openGL group"
>
> Also, you may find the API specifications predefined with examples in C that
> you can alter to Ada there as well.

Re: OpenGL in Ada

[Warren]

John B. Matthews expounded in news:nospam-8BBB96.10151708072010
@news.aioe.org:

> In article 
> <68dd0333-f502-4351-9e50-4ec83bddc44e@k39g2000yqd.googlegroups.com>,
>  Shark8 <onewingedshark@gmail.com> wrote:
> 
>> Would anyone, other than myself, find such a translation of interest?
> 
> I have used AdaOpenGL in the past. Is your project related in any way?
> 
> <http://adaopengl.sourceforge.net/>

There is the SDL project: http://www.libsdl.org/libraries.php
available for portable game writing.  Something like that in
Ada form would be very useful. This is a big project, to be
sure, but Ada tasking and games seem like a natural fit
to me. I'd be interested in developing some games with this
kind of framework.

Warren

Re: OpenGL in Ada

[Warren]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2926 bytes --]

Gene expounded in
news:2074b3a5-12f3-4260-a2ad-f15ed251e378@d16g2000yqb.googlegroups.com: 

> On Jul 9, 1:38�pm, Shark8 <onewingedsh...@gmail.com> wrote:
>> On Jul 9, 9:11�am, Gene <gene.ress...@gmail.com> wrote:
>> > On Jul 7, 10:42�pm, Shark8 <onewingedsh...@gmail.com> wrote:
>>
>> > > Hello everyone,
>> > > I posted about wanting to write an OS in Ada a while ago and, as
>> > > part of that effort I've taken to translating the OpenGL API. No,
>> > > I don't mean JUST running the headers through ato-Ada converter
>> > > but actually translating the API into a more Ada-natural form.
...
>> > Having done this a couple of times myself, you should consider the
>> > approach of writing a specialized program that processes the OpenGL
>> > header into a binding. �OpenGL will remain a moving target as
>> > graphic 
> s
>> > hardware continues to evolve. �Compilers will always have their
>> > uniqu 
> e
>> > quirks. �With all this room for variation, it will probably be
>> > easier to maintain a translator than to revise the binding every
>> > time the standard changes or grows.
>>
>> I see what you're saying. The problem is in the specs, the moving
>> target you mentioned, for example the glBegin function ...
> 
> Well, plus the need for backward compatibility.
> 
> Nonetheless, if you have isolated the need to identify glBegin args in
> a table within a translator, so it can spit out the requisite new
> enumeration equivalences, I believe you are ahead of the game.  No one
> is saying the translator will keep working with zero modifications.
> 
> For (an admittedly contrived) example, if the spec introduces a new
> call that accepts anything glBegin will accept plus a few other flags,
> the translator can encode this idea in a new addendum table and an
> algorithm. This is easier and less error prone going forward than
> remembering to update both enumerations in parallel.

I've not tried to use OpenGL myself, but my two cents worth-

I'd prefer the binding not to be as much of a moving target. One
thing you can use is procedure/function overloading as well as 
differently named procedures/functions.  The Ada binding should
have some of the benefit of hindsight, since it is developed
after. So take that advantage and design an API that is "proper".
In other words, make it less of a binding, than a proper Ada
library layer to the OpenGL behind the scenes.

If you extend something, then I think this can be normally done 
without breaking existing APIs. I know there will be exceptions, 
but I'd be real annoyed if I had to re-work my app every time a 
new version of the binding came out.  

This is one of the reasons that my own open sourced projects 
depend upon as few external projects as possible.  I don't like 
having to re-work and debug other user's problems in my software 
by email, inflicted by other dependency projects' [sometimes] 
whimsical changes.

Warren

Re: OpenGL in Ada

[BrianG]

Shark8 wrote:
> On Jul 11, 2:46 pm, a...@att.net wrote:
>> In <i1bktn$uc...@speranza.aioe.org>, tmo...@acm.org writes:
>>>>>>>  Procedure Color    ( red, green, blue : in double );
>>>>>>>  Procedure Color    ( red, green, blue : in float );
>>>> One problem you'll have is if a user wants to make a call with all
>>>> literals, i.e. Color(1, 2, 3) or Color(1.0, 2.0, 3.0), the compiler
>>>> won't know which version to use.  The best solution I've found (besides
>>>> making users specify a type)
>>> And what's wrong with requiring the user to be unambiguous by specifying
>>> a type?  It's unlikely there will be a lot of calls with all literals
>>> (unless generated by some program) so it shouldn't be onerous.  And
>>> "Float'(1.0)" is clearer to the person reading the code five years
>> >from now than "Color_F".
>>
>> What your are forgetting is the openGL is a specification from the openGL
>> group ( opengl.org ), it is just like the Ada RM in that respect.  For a
>> program or package, to be classified as openGL it must comply with "openGL
>> group" openGL specification.  Changing any API part nullify the use of
>> openGL in any part of your system.

I'm sorry, I wasn't aware we had a member of the OpenGL police present. 
  Where do I go to pay my fine?  BTW, it appears the proper name is 
OpenGL, not openGL :-).  Not that I'm picky.

Maybe you ('Anon') ought to actually read the spec you mentioned.  The 
following is a direct quote from that document:
"The declarations shown in this document apply to ANSI C. Languages such 
as C++ and Ada that allow passing of argument type information admit 
simpler declarations and fewer entry points."
(with reference to the GLxxxTypeInterface naming convention.)
[http://www.opengl.org/registry/doc/glspec40.core.20100311.pdf]

>>
>> So, adding or altering any definitions about the given API must comply with
>> the openGL specification. Names of the API functions and procedures with
>> the API defined types are set by this openGL group.
> 
> That seems, on its face, to contradict BrianG's claim:
> 
>> What you have is a way to do it, but that's not what the OP posted.  He had
>> all procedures named Color, so the user doesn't need to worry about
>> implementation.  (If I use Color for Double and want to change my program to
>> use Float, I have to change the names of all calls, even if I use calls where
>> the compiler could determine what I want - and not just calls to Color, many
>> routines would have the same issue.)  This is also what the OpenGL
>> documentation implies should be done in a language like Ada.
> 
> But, if he's correct in this earlier post:
>> (I've tried starting a similar effort, but never got very far.  I was using
>> the OpenGL "red book" as a basis; I find it interesting that the OpenGL
>> definition recognizes that "some languages like Ada and C++" could implement
>> names this way, but every Ada library I've seen follows the C naming scheme.)
> 
> Then my renaming (to get rid of the gl- prefix and parameter-type-
> postfix) and
> overloading them all is a valid OpenGL API.
> 
Not only is it valid, it looks like it's what was expected.  I've never 
seen an implementation that does that.

>> visitwww.opengl.org
>> for more information on openGL and the "openGL group"
>>
>> Also, you may find the API specifications predefined with examples in C that
>> you can alter to Ada there as well.
> 
What I've been using is the online v1.1 "Redbook" 
[http://www.glprogramming.com/red/] - since ObjectAda (from Barnes' 
book) uses that version (last I looked, GNAT/GTKAda didn't provide 
OpenGL on windows).

I've never tried figuring out OpenGL versions - right now the "current 
edition of the Redbook" is version 2.1, but the same page points to 
          a "Specification Version 4.0".  Whatever.

Re: OpenGL in Ada

[Ludovic Brenta]

Warren wrote on comp.lang.ada:
> There is the SDL project:http://www.libsdl.org/libraries.php
> available for portable game writing.  Something like that in
> Ada form would be very useful. This is a big project, to be
> sure, but Ada tasking and games seem like a natural fit
> to me. I'd be interested in developing some games with this
> kind of framework.

There exists an Ada binding: http://sourceforge.net/projects/adasdl/

Several years ago I started rewroting Defendguin in Ada with this
binding, see

http://green.ada-france.org:8081/branch/changes/org.ludovic-brenta.defendguin

IIUC, it is possible to do OpenGL from within, or in conjunction with,
SDL, as most OpenGL games I know of also use SDL. I never tried.

--
Ludovic Brenta.

Re: OpenGL in Ada

[Warren]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1025 bytes --]

Ludovic Brenta expounded in
news:b3788036-725e-4462-8389-e7a9ca52b6a7@g19g2000yqc.googlegroups.com: 

> Warren wrote on comp.lang.ada:
>> There is the SDL project:http://www.libsdl.org/libraries.php
>> available for portable game writing. �Something like that in
>> Ada form would be very useful. This is a big project, to be
>> sure, but Ada tasking and games seem like a natural fit
>> to me. I'd be interested in developing some games with this
>> kind of framework.
> 
> There exists an Ada binding: http://sourceforge.net/projects/adasdl/

Well that is cool. Thanks for the pointer.

> Several years ago I started rewroting Defendguin in Ada with this
> binding, see
> 
> http://green.ada-france.org:8081/branch/changes/org.ludovic-brenta.defe
> ndguin 
> 
> IIUC, it is possible to do OpenGL from within, or in conjunction with,
> SDL, as most OpenGL games I know of also use SDL. I never tried.

I'll definitely have to check that out. Now if I can only
get my current project workload out of the way. ;-)

Warren

Re: OpenGL in Ada

[anon]

>
>I'm sorry, I wasn't aware we had a member of the OpenGL police present. 
>  Where do I go to pay my fine?  BTW, it appears the proper name is 
>OpenGL, not openGL :-).  Not that I'm picky.
>
>Maybe you ('Anon') ought to actually read the spec you mentioned.  The 
>following is a direct quote from that document:
>"The declarations shown in this document apply to ANSI C. Languages such 
>as C++ and Ada that allow passing of argument type information admit 
>simpler declarations and fewer entry points."
>(with reference to the GLxxxTypeInterface naming convention.)
>[http://www.opengl.org/registry/doc/glspec40.core.20100311.pdf]
>
>


May you should understand that people who use Ada know that the we do not 
want others try to destroy Ada by adding or modifying Ada without the RM 
direct allowance.  So, we as a group should be consider that other may 
feel the same way about openGL's RM or specifications.

And just like Ada uses prefer "Ada' the GL group prefer "openGL".


>What I've been using is the online v1.1 "Redbook" 
>[http://www.glprogramming.com/red/] - since ObjectAda (from Barnes' 
>book) uses that version (last I looked, GNAT/GTKAda didn't provide 
>OpenGL on windows).
>
>I've never tried figuring out OpenGL versions - right now the "current 
>edition of the Redbook" is version 2.1, but the same page points to 
>          a "Specification Version 4.0".  Whatever.

Re: OpenGL in Ada

[Shark8]

According to OpenGL's specification (page 14):
These examples show the ANSI C declarations for these commands. In
general,
a command declaration has the form1
rtype Namef\x0f1234gf\x0f b s i i64 f d ub us ui ui64gf\x0fvg ( [args ,] T
arg1 , : : : , T argN [, args] );
rtype is the return type of the function. The braces (fg) enclose a
series of type
descriptors (see table 2.1), of which one is selected. \x0f indicates no
type descriptor.
The arguments enclosed in brackets ([args ,] and [, args]) may or may
not be
present. The N arguments arg1 through argN have type T, which
corresponds to
one of the type descriptors indicated in table 2.1 (if there are no
letters, then the
arguments’ type is given explicitly). If the final character is not v,
then N is given
by the digit 1, 2, 3, or 4 (if there is no digit, then the number of
arguments is fixed).
If the final character is v, then only arg1 is present and it is an
array of N values of
the indicated type.
For example,
void Uniformf1234gfifg( int location, T value );
indicates the eight declarations

The footnote reads:
"1The declarations shown in this document apply to ANSI C. Languages
such as C++ and Ada
that allow passing of argument type information admit simpler
declarations and fewer entry points."

Therefore, the very spec that you are claiming to advocate says that I
*CAN* use Ada and "simpler declarations and fewer entry points."
If you're going to "language-lawyer" at least read the rules/specs
that your opponent is citing, otherwise you come off as a jerk who is
too [intellectually] lazy to actually consider the problems/statements
at hand.

OpenGL in Ada

[Yves Bailly]

Greetings to everyone in this group,

This is my very first posting, so please apologize if I do something
really wrong (as well as for my english, it's not my native language).

I have created a small program which generates a pair of files, namely
"gl.ads" and "gl.adb", to use OpenGL from Ada. The files are generated
by reading the official OpenGL specifications files (namely
"enum.spec", "gl.spec" and "gl.tm") which can be found from the
official OpenGL page http://www.opengl.org/registry/ (no GLU nor GLUT
though).

The OpenGL subprograms are named according to the usual C naming
scheme ("glBegin", "glVertex3d" and so on), so the result looks more
like C than like Ada, but at least it allows to read tutorials more
easily (as most of them are based on C). So the generated binding is
rather low-level (I think "thin binding" is the appropriate wording).

The subprograms are not imported using "pragma Import", but rather
declared as access to subprograms (procedures or functions). The
access are then resolved in a lenghty "Init_GL" procedure, which
relies on the "glGetProcAddress" function imported from SDL. So the
generated binding requires SDL to work.

I'm far from being an Ada expert. I would really appreciate if someone
interested in using OpenGL with Ada would accept to spend some time:
- to point me to the horrible things I probably wrote in this program;
- to tell if the generated binding is of good or bad quality.

Thanks for your time and best regards,

-- Yves Bailly
yves.bailly@gmail.com

Re: OpenGL in Ada

[anon]

In <d6318f95-59cd-4f12-8aaa-2746c14dbd18@a15g2000yqm.googlegroups.com>, Yves Bailly <yves.bailly@gmail.com> writes:
>Greetings to everyone in this group,
>
>This is my very first posting, so please apologize if I do something
>really wrong (as well as for my english, it's not my native language).
>
>I have created a small program which generates a pair of files, namely
>"gl.ads" and "gl.adb", to use OpenGL from Ada. The files are generated
>by reading the official OpenGL specifications files (namely
>"enum.spec", "gl.spec" and "gl.tm") which can be found from the
>official OpenGL page http://www.opengl.org/registry/ (no GLU nor GLUT
>though).
>
>The OpenGL subprograms are named according to the usual C naming
>scheme ("glBegin", "glVertex3d" and so on), so the result looks more
>like C than like Ada, but at least it allows to read tutorials more
>easily (as most of them are based on C). So the generated binding is
>rather low-level (I think "thin binding" is the appropriate wording).
>
>The subprograms are not imported using "pragma Import", but rather
>declared as access to subprograms (procedures or functions). The
>access are then resolved in a lenghty "Init_GL" procedure, which
>relies on the "glGetProcAddress" function imported from SDL. So the
>generated binding requires SDL to work.
>
>I'm far from being an Ada expert. I would really appreciate if someone
>interested in using OpenGL with Ada would accept to spend some time:
>- to point me to the horrible things I probably wrote in this program;
>- to tell if the generated binding is of good or bad quality.
>
>Thanks for your time and best regards,
>
>-- Yves Bailly
>yves.bailly@gmail.com


The complete Ada openGL source bindings can be found at:

    adaopengl.sourceforge.net

All you needs is to download and install openGL engine set up for your OS.

I do have a few samples that work with Linux\Windows.

Re: OpenGL in Ada

[Yves Bailly]

On Oct 6, 5:45 am, a...@anon.org wrote:
>
> The complete Ada openGL source bindings can be found at:
>     adaopengl.sourceforge.net
> All you needs is to download and install openGL engine set up for your OS.

I've used this binding, unfortunately it's now quite outdated. For
what I can see, it only provides support for OpenGL up to 1.3, however
we're now at 4.1, with shaders and many other shiny things. That's why
I created this program. Subprograms are resolved dynamically at
runtime, if the underlying OpenGL engine doesn't provide a function
(because it's not up-to-date or the hardware itself doesn't provide
it), then the function pointer is simply set to "null".

OpenGL is a moving thing. Since a few years we can see a new
specification every 6 months or so, a hand-made only binding seems too
much work, at least for me.

Re: OpenGL in Ada

[Gautier write-only]

Yves Bailly:

> The OpenGL subprograms are named according to the usual C naming
> scheme ("glBegin", "glVertex3d" and so on), so the result looks more
> like C than like Ada, but at least it allows to read tutorials more
> easily (as most of them are based on C). So the generated binding is
> rather low-level (I think "thin binding" is the appropriate wording).

If you want to see a GL binding with Ada names, visit this
  http://globe3d.sf.net/
There is somewhere among the tools a gl_overloader that produces
different "Vertex" instead of C's "glVertex3d", "glVertex3f", etc.
like here:
  http://globe3d.sf.net/g3d_html/gl__ads.htm#3346_13
You can perhaps combine it with your binding generator.

______________________________________________________________________________
Gautier's Ada programming -- http://gautiersblog.blogspot.com/search/label/Ada
NB: For a direct answer, e-mail address on the following web site:
http://lang-index.sf.net/#contact

Re: OpenGL in Ada

[Alex R. Mosteo]

Yves Bailly wrote:

> On Oct 6, 5:45 am, a...@anon.org wrote:
>>
>> The complete Ada openGL source bindings can be found at:
>> adaopengl.sourceforge.net
>> All you needs is to download and install openGL engine set up for your
>> OS.
> 
> I've used this binding, unfortunately it's now quite outdated. For
> what I can see, it only provides support for OpenGL up to 1.3, however
> we're now at 4.1, with shaders and many other shiny things. That's why
> I created this program. Subprograms are resolved dynamically at
> runtime, if the underlying OpenGL engine doesn't provide a function
> (because it's not up-to-date or the hardware itself doesn't provide
> it), then the function pointer is simply set to "null".
> 
> OpenGL is a moving thing. Since a few years we can see a new
> specification every 6 months or so, a hand-made only binding seems too
> much work, at least for me.

There is this struggle between automatic complete bindings and manual, thick 
good-looking bindings... I'm a fan of completeness and automation, but it's 
difficult to get bearable results (case in point: SWIG). I'm curious about 
the binding you get with your translator. Is your binding available 
somewhere?

Re: OpenGL in Ada

[Yves Bailly]

On Oct 6, 11:51 am, "Alex R. Mosteo" <alejan...@mosteo.invalid> wrote:
> There is this struggle between automatic complete bindings and manual, thick
> good-looking bindings... I'm a fan of completeness and automation, but it's
> difficult to get bearable results (case in point: SWIG). I'm curious about
> the binding you get with your translator. Is your binding available
> somewhere?

Not yes, and I wasn't sure I should post it here (assuming it's
possible). The
resulting gl.ads and gl.adb are both more than 640K (though much less
compressed of course). Actually I was thinking about sending it
directly by
email to anyone asking for it.

Now maybe I can setup some http access to it somewhere.

Thanks for your interest!

Re: OpenGL in Ada

[Ludovic Brenta]

Yves Bailly wrote on comp.lang.ada:
> Alex R. Mosteo wrote:
>> Is your binding available somewhere?
>
> Not yes, and I wasn't sure I should post it here (assuming it's
> possible). The resulting gl.ads and gl.adb are both more than
> 640K (though much less compressed of course). Actually I was
> thinking about sending it directly by email to anyone asking
> for it.
>
> Now maybe I can setup some http access to it somewhere.

Outside of the usual suspects (SourceForge, Berlios, Tigris,
Savannah, GNA! and possibly others), there are Ada-specific
hosting services for git[1] and monotone[2].

[1] http://ada.cx
[2] http://www.ada-france.org/article131.html, hosting is not
    limited to Debian packaging.

--
Ludovic Brenta.

Re: OpenGL in Ada

[Pascal Obry]

Le 06/10/2010 12:59, Ludovic Brenta a �crit :
> Outside of the usual suspects (SourceForge, Berlios, Tigris,
> Savannah, GNA! and possibly others), there are Ada-specific
> hosting services for git[1] and monotone[2].

I'll add github (free for open source projects) and http://repo.or.cz/
free too.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|    http://www.obry.net  -  http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: OpenGL in Ada

[Yves Bailly]

On Oct 6, 6:07 pm, Pascal Obry <pas...@obry.net> wrote:
> Le 06/10/2010 12:59, Ludovic Brenta a écrit :
>
> > Outside of the usual suspects (SourceForge, Berlios, Tigris,
> > Savannah, GNA! and possibly others), there are Ada-specific
> > hosting services for git[1] and monotone[2].
>
> I'll add github (free for open source projects) andhttp://repo.or.cz/
> free too.

Well, let's keep things simple... here's an archive containing my
"generator" (which
requires the OpenGL spec files "gl.spec", "gl.tm" and "enum.spec" in
the exec
directory, as well as the generated "gl.ads" and "gl.adb" files:
http://kafka.fr.free.fr/ada/build_gl.tar.bz2

Please be gentle with me, again I'm far from an Ada expert :-)

Regards,

Re: OpenGL in Ada

[BrianG]

Gautier write-only wrote:
> Yves Bailly:
> 
>> The OpenGL subprograms are named according to the usual C naming
>> scheme ("glBegin", "glVertex3d" and so on), so the result looks more
>> like C than like Ada, but at least it allows to read tutorials more
>> easily (as most of them are based on C). So the generated binding is
>> rather low-level (I think "thin binding" is the appropriate wording).
> 
> If you want to see a GL binding with Ada names, visit this
>   http://globe3d.sf.net/
> There is somewhere among the tools a gl_overloader that produces
> different "Vertex" instead of C's "glVertex3d", "glVertex3f", etc.
> like here:
>   http://globe3d.sf.net/g3d_html/gl__ads.htm#3346_13
> You can perhaps combine it with your binding generator.
> 

I would strongly recommend using an Ada-type naming convention.  Even 
the  OpenGL definition recognizes that the "C naming convention" is only 
due to C's limitations and recommends using a "real" naming with real 
languages (see the Red Book - ok, the "real languages" part is my wording).

Someone trying to use a tutorial ought to be able to understand the 
change from "glVertex3i(x,y,z)" to "GL.Vertex(x, y, z : Int)".

(Of course there is a problem with overloading multiple integral and 
real versions - calls with only literal arguments need some kind of 
kludge.  I've never found a good solution.)

--BrianG

Re: OpenGL in Ada

[Yves Bailly]

On Oct 7, 3:52 am, BrianG <briang...@gmail.com> wrote:
> Gautier write-only wrote:
> > Yves Bailly:
>
> >> The OpenGL subprograms are named according to the usual C naming
> >> scheme ("glBegin", "glVertex3d" and so on), so the result looks more
> >> like C than like Ada, but at least it allows to read tutorials more
> >> easily (as most of them are based on C). So the generated binding is
> >> rather low-level (I think "thin binding" is the appropriate wording).
>
> > If you want to see a GL binding with Ada names, visit this
> >  http://globe3d.sf.net/
> > There is somewhere among the tools a gl_overloader that produces
> > different "Vertex" instead of C's "glVertex3d", "glVertex3f", etc.
> > like here:
> >  http://globe3d.sf.net/g3d_html/gl__ads.htm#3346_13
> > You can perhaps combine it with your binding generator.
>
> I would strongly recommend using an Ada-type naming convention.  Even
> the  OpenGL definition recognizes that the "C naming convention" is only
> due to C's limitations and recommends using a "real" naming with real
> languages (see the Red Book - ok, the "real languages" part is my wording).
>
> Someone trying to use a tutorial ought to be able to understand the
> change from "glVertex3i(x,y,z)" to "GL.Vertex(x, y, z : Int)".
>
> (Of course there is a problem with overloading multiple integral and
> real versions - calls with only literal arguments need some kind of
> kludge.  I've never found a good solution.)

Well, I guess tastes vary on this subject... at least the "gl" prefix
could be removed (or not, according to a command-line option).

About the overloading, maybe things like "GL.Vertexi(x, y: Int)" and
"GL.Vertexf(x, y: Float)", i.e. with a suffix, would be acceptable?

That said, "glVertex*()" is deprecated in recent OpenGL versions ;-)

Re: OpenGL in Ada

[Lucretia]

On Oct 5, 10:23 pm, Yves Bailly <yves.bai...@gmail.com> wrote:

> The subprograms are not imported using "pragma Import", but rather
> declared as access to subprograms (procedures or functions). The
> access are then resolved in a lenghty "Init_GL" procedure, which
> relies on the "glGetProcAddress" function imported from SDL. So the
> generated binding requires SDL to work.

That is something that shouldn't be done here. Most of the API can be
linked to directly with pragma import, the Win32 version needs to use
a different type of import, stdcall, I think; see the GNAT manuals.

glGetProcAddress is for getting the address of subprograms from a DLL,
i.e. the GL extensions.

It would be nice to have just 1 combined effort for GL under a BSD
licence so we can get rid of the x amount of already existing
versions, I think I know of about 4-5 at the moment.

Luke.

Luke.

Re: OpenGL in Ada

[Shark8]

> Someone trying to use a tutorial ought to be able to understand the
> change from "glVertex3i(x,y,z)" to "GL.Vertex(x, y, z : Int)".
>
> (Of course there is a problem with overloading multiple integral and
> real versions - calls with only literal arguments need some kind of
> kludge.  I've never found a good solution.)
>
> --BrianG

Well, there's qualification:
Vertex( Z => Integer'(1), X => Integer'(1), Y => Integer'(1) );

and
There's using typed-constants:
Declare
 One : Constant Integer:= 1;
Begin
 Vertex( X => One, Y => One, Z => One );
End;

Is the case of using only literals the most common case? If not, how
common is it?

Re: OpenGL in Ada

[Yves Bailly]

Lucretia wrote:
> On Oct 5, 10:23 pm, Yves Bailly <yves.bai...@gmail.com> wrote:
>
> > The subprograms are not imported using "pragma Import", but rather
> > declared as access to subprograms (procedures or functions). The
> > access are then resolved in a lenghty "Init_GL" procedure, which
> > relies on the "glGetProcAddress" function imported from SDL. So the
> > generated binding requires SDL to work.
>
> That is something that shouldn't be done here. Most of the API can be
> linked to directly with pragma import, the Win32 version needs to use
> a different type of import, stdcall, I think; see the GNAT manuals.
>
> glGetProcAddress is for getting the address of subprograms from a DLL,
> i.e. the GL extensions.

Actually, I don't think it's enough, because different drivers and
hardwares
provide different OpenGL coverage. For example, maybe you can use
pragma import(C, "glGenFramebuffers") with an OpenGL lib providing
at least OpenGL 3, but it will fail if the lib provides only an older
version.
What is an extension in a given GL version may not be in another.

The use of  a GetProcAddress function allows to work in any case,
just some subprogram pointers stay null. Note that it's the only
dependency imported from SDL, it could be replaced by a hand-
written equivalent, therefore removing the dependency (I'm just too
lazy for this). To be able to use "pragma import" in any case would
require to link with something like Glew.

That said, remains the question of the creation of the GL context,
the handling of events and so on, much things very system-dependent.
As far as I know, GLUT is just too old for this, e.g. it doesn't
handle
Unicode at all. But I guess that's another story.

> It would be nice to have just 1 combined effort for GL under a BSD
> licence so we can get rid of the x amount of already existing
> versions, I think I know of about 4-5 at the moment.

I agree with that, however I personaly don't think I would be able to
organise nor manage such a "combined effort". But I would be glad
to help in such an effort, assuming I could be of any help of course.

Regards,

Re: OpenGL in Ada

[Vadim Godunko]

On Oct 9, 12:42 am, Yves Bailly <yves.bai...@gmail.com> wrote:
>
> Actually, I don't think it's enough, because different drivers and
> hardwares
> provide different OpenGL coverage. For example, maybe you can use
> pragma import(C, "glGenFramebuffers") with an OpenGL lib providing
> at least OpenGL 3, but it will fail if the lib provides only an older
> version.
> What is an extension in a given GL version may not be in another.
>
> The use of  a GetProcAddress function allows to work in any case,
> just some subprogram pointers stay null. Note that it's the only
> dependency imported from SDL, it could be replaced by a hand-
> written equivalent, therefore removing the dependency (I'm just too
> lazy for this). To be able to use "pragma import" in any case would
> require to link with something like Glew.
>
Another option can be generation of set of checks to detect
availability of features/extensions at configuration time and
generation of supported subset only (or preprocessing of generated
code).

> That said, remains the question of the creation of the GL context,
> the handling of events and so on, much things very system-dependent.
> As far as I know, GLUT is just too old for this, e.g. it doesn't
> handle
> Unicode at all. But I guess that's another story.
>
It is another story definitely. GtkAda and QtAda both provide all
needed functionality in cross-platform way.

Re: OpenGL in Ada #2

[JillRivas]

Great article. Thanks for the info, you made it easy to understand. BTW, if anyone needs to fill out a <a href="http://www.pdffiller.com/6954886-f940--2013pdf-2013-Form-940-User-Forms?utm_source=compgroups.net&utm_medium=newblogsystem&utm_campaign= \"ADA form\" journal" target="_blank" >Ada Form</a>, I found a blank form here.

Re: OpenGL in Ada

[Lucretia]

I already have the majority of SDL 2.0.3 bound and I already have parsing for the GL XML spec files. I really must get back to them :D

Luke.

Re: OpenGL in Ada

[David Botton]

On Friday, January 30, 2015 at 9:45:53 AM UTC-5, Lucretia wrote:
> I already have the majority of SDL 2.0.3 bound and I already have parsing for the GL XML spec files. I really must get back to them :D
> 
> Luke.

Please do :) Gnoga is waiting to use it for WebGL :)