OpenGL in Ada
in [ADA]
|
From: Warren on 12 Jul 2010 13:04 Gene expounded in news:2074b3a5-12f3-4260-a2ad-f15ed251e378(a)d16g2000yqb.googlegroups.com: > 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. .... >> > 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
From: BrianG on 12 Jul 2010 20:45 Shark8 wrote: > On Jul 11, 2:46 pm, a...(a)att.net wrote: >> In <i1bktn$uc...(a)speranza.aioe.org>, tmo...(a)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.
From: Ludovic Brenta on 13 Jul 2010 08:26 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.
From: Warren on 13 Jul 2010 09:13 Ludovic Brenta expounded in news:b3788036-725e-4462-8389-e7a9ca52b6a7(a)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
From: anon on 13 Jul 2010 13:50 > >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.
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 5 Prev: Color Ada Keywords Next: Wikibook on Ada Programming - Object Orientation |