OpenGL in Ada
in [ADA]
|
From: Shark8 on 9 Jul 2010 13:38 On Jul 9, 9:11 am, Gene <gene.ress...(a)gmail.com> wrote: > On Jul 7, 10:42 pm, Shark8 <onewingedsh...(a)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.
From: Gene on 9 Jul 2010 16:54 On Jul 9, 1:38 pm, Shark8 <onewingedsh...(a)gmail.com> wrote: > On Jul 9, 9:11 am, Gene <gene.ress...(a)gmail.com> wrote: > > > > > > > On Jul 7, 10:42 pm, Shark8 <onewingedsh...(a)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.
From: BrianG on 10 Jul 2010 00:00 Shark8 wrote: > On Jul 9, 9:11 am, Gene <gene.ress...(a)gmail.com> wrote: >> On Jul 7, 10:42 pm, Shark8 <onewingedsh...(a)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.)
From: Gautier write-only on 10 Jul 2010 07:47 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.
From: BrianG on 10 Jul 2010 22:45 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.)
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 5 Prev: Color Ada Keywords Next: Wikibook on Ada Programming - Object Orientation |