> and was last updated on 2003 ! This is like 100 years ago
> in computer years.
Not necessarily. The 2003's API may match your needs. Check it before,
only then you will know (newer ≠ better).
-- “Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University
>> and was last updated on 2003 ! This is like 100 years ago
>> in computer years.
> Not necessarily. The 2003's API may match your needs. Check it before,
> only then you will know (newer ≠ better).
I do not have specific needs, just wanted to learn basic openGL
a little, and thought why not use Ada. But this binding is
very old, and many releases behind current openGL version.
I can use c++ and use the current openGL, or use Ada and
use much older API version to learn from.
It seems all the Ada pages related to this are old. Here is
another related page referenced in the readme for Ada openGL
> and was last updated on 2003 ! This is like 100 years ago
> in computer years.
I've just checked the version I used in some experiments a few months ago:
was OpenGL 2.1.
Believe me, that was fine. I just get into troubles with text display,
which is not Unicode aware (still fine for english only text).
Pretty sure you can go with the Ada binding you found. Or else, you can
create your own if you wish.
-- “Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University
> I don't know how recent it is but analyzing the source might be a good
> way to learn OpenGL, too.
Note that you are not obliged to use the GLOBE_3D[.*] packages, you
can use the GL binding alone which has following advantages:
- it uses Ada-like notations (GL.Color instead of, say, glColor3d)
- it is maintained
_________________________
Gautier's Ada programming
http://gautiersblog.blogspot.com/search/label/Ada NB: follow the above link for a valid e-mail address
>>> and was last updated on 2003 ! This is like 100 years ago
>>> in computer years.
>> Not necessarily. The 2003's API may match your needs. Check it before,
>> only then you will know (newer ≠ better).
> I do not have specific needs, just wanted to learn basic openGL
> a little, and thought why not use Ada. But this binding is
> very old, and many releases behind current openGL version.
> I can use c++ and use the current openGL, or use Ada and
> use much older API version to learn from.
> It seems all the Ada pages related to this are old. Here is
> another related page referenced in the readme for Ada openGL
> It looks like the people who did this initially are all gone
> to do other things.
> I like Ada more than C/C++, but it seems to me, it is easier
> and more useful to just use C++ for this sort of thing.
> Thanks,
> --Nasser
You could also try GLOBE; it's not OpenGL, but a higher-level library. However, it contains an OpenGL binding. I haven't looked at it recently, except to see that it gets updates, but it should be more recent than 2003. It's also the only Ada binding I've seen that doesn't blindly follow the C nature of the typical OpenGL function set (every function has different named versions for the different parameter sets - which even the OpenGL spec 'Red Book' recognizes as not needed for languages that allow overloading "like C++ and Ada").
(I occasionally return to my attempt to build a binding, based on the 'Red Book', but it doesn't hold enough interest for me to keep at it very long. I did learn that you can't use a single name for all versions of a function - because then you can't call it with all literal parameters {there's no way to resolve the short/long or float/double versions}. At a minimum, you need 2 names; I prefer to use the 2nd for the literal case, but never came up with a reasonable naming convention.)
> You could also try GLOBE; it's not OpenGL, but a higher-level library.
> However, it contains an OpenGL binding. I haven't looked at it recently,
> except to see that it gets updates, but it should be more recent than
> 2003. It's also the only Ada binding I've seen that doesn't blindly
> follow the C nature of the typical OpenGL function set (every function
> has different named versions for the different parameter sets - which
> even the OpenGL spec 'Red Book' recognizes as not needed for languages
> that allow overloading "like C++ and Ada").
> (I occasionally return to my attempt to build a binding, based on the
> 'Red Book', but it doesn't hold enough interest for me to keep at it
> very long. I did learn that you can't use a single name for all versions
> of a function - because then you can't call it with all literal
> parameters {there's no way to resolve the short/long or float/double
> versions}.
"No way"? Is there some reason why you cannot qualify the literals, as in Float'(3.14) versus Long_Float'(3.14)?
> At a minimum, you need 2 names; I prefer to use the 2nd for
> the literal case, but never came up with a reasonable naming convention.)
If there are many parameters that can (all together) be either Float or Long_Float, and many calls with all-literal parameters, it is of course briefer to write a few extra letters in the function name, than to write all the type qualifiers around the literals. (In principle it is not necessary to qualify all the literal parameters; it is enough to qualify only as many as are needed to resolve the overloading, but that looks unsymmetric and unsystematic.)
I know next to nothing about OpenGL or GLOBE. Are all-literal calls so sommon that writing them in a qualified form is very bad?
Le Tue, 07 Feb 2012 02:33:49 +0100, BrianG <m...@null.email> a écrit:
> (I occasionally return to my attempt to build a binding, based on the
> 'Red Book', but it doesn't hold enough interest for me to keep at it
> very long. I did learn that you can't use a single name for all
> versions of a function - because then you can't call it with all literal
> parameters {there's no way to resolve the short/long or float/double
> versions}. At a minimum, you need 2 names; I prefer to use the 2nd for
> the literal case, but never came up with a reasonable naming convention.)
Or else four packages with static genericity.
package OpenGL.With_Shorts is
function F1 (Param1 : Short, ...);
function F2 (Param1 : Short)
function F2 return Short;
...
end ...;
package OpenGL.With_Longs is
function F1 (Param1 : Long, ...);
function F2 (Param1 : Long)
function F2 return Long;
...
end ...;
And so on.
-- “Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University
> Le Tue, 07 Feb 2012 02:33:49 +0100, BrianG <m...@null.email> a écrit:
>> (I occasionally return to my attempt to build a binding, based on the
>> 'Red Book', but it doesn't hold enough interest for me to keep at it
>> very long. I did learn that you can't use a single name for all
>> versions of a function - because then you can't call it with all
>> literal parameters {there's no way to resolve the short/long or
>> float/double versions}. At a minimum, you need 2 names; I prefer to
>> use the 2nd for the literal case, but never came up with a reasonable
>> naming convention.)
> Or else four packages with static genericity.
> package OpenGL.With_Shorts is
> function F1 (Param1 : Short, ...);
> function F2 (Param1 : Short)
> function F2 return Short;
> ...
> end ...;
> package OpenGL.With_Longs is
> function F1 (Param1 : Long, ...);
> function F2 (Param1 : Long)
> function F2 return Long;
> ...
> end ...;
> And so on.
Yes, and that might be one good way to organize the bindings. I presume that a typical program would tend to use one 'flavor' of number more-or-less consistently.
One thing I would like is to a way to organize the package structure in a way that makes _using_ it easier. Most OpenGL programs I've looked at, which isn't many, with (or #include) all/most parts of the library structure, because it was organized for the library _writer's_ benefit. (This probably applies to most large, structured libraries).
