Re: OpenGL in Ada

[Gene <gene.ressler@gmail.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.
>
> > > 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.