Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
what is current status of OpenGL and Ada?
411 views
Skip to first unread message
Nasser M. Abbasi
Feb 5, 2012, 1:52:25 AM2/5/12
to
current OpenGL is 4.2, released 8,2012.
http://en.wikipedia.org/wiki/OpenGL
previous version was 3.3.
The Ada openGL binding I could find is
http://adaopengl.sourceforge.net/
and was last updated on 2003 ! This is like 100 years ago
in computer years.
Is there a more recent openGL binding for Ada?
thanks,
--Nasser
http://en.wikipedia.org/wiki/OpenGL
previous version was 3.3.
The Ada openGL binding I could find is
http://adaopengl.sourceforge.net/
and was last updated on 2003 ! This is like 100 years ago
in computer years.
Is there a more recent openGL binding for Ada?
thanks,
--Nasser
Nasser M. Abbasi
Feb 5, 2012, 2:03:54 AM2/5/12
to
On 2/5/2012 12:52 AM, Nasser M. Abbasi wrote:
> current OpenGL is 4.2, released 8,2012.
opps,
> current OpenGL is 4.2, released 8,2012.
s/2012/2011/
Yannick Duchêne (Hibou57)
Feb 5, 2012, 7:00:29 AM2/5/12
to
Le Sun, 05 Feb 2012 07:52:25 +0100, Nasser M. Abbasi <n...@12000.org> a
écrit:
> current OpenGL is 4.2, released 8,2012.
>
> http://en.wikipedia.org/wiki/OpenGL
>
> previous version was 3.3.
>
> The Ada openGL binding I could find is
>
> http://adaopengl.sourceforge.net/
>
> 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
écrit:
> current OpenGL is 4.2, released 8,2012.
>
> http://en.wikipedia.org/wiki/OpenGL
>
> previous version was 3.3.
>
> The Ada openGL binding I could find is
>
> http://adaopengl.sourceforge.net/
>
> and was last updated on 2003 ! This is like 100 years ago
> in computer years.
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
Nasser M. Abbasi
Feb 5, 2012, 7:34:44 AM2/5/12
to
On 2/5/2012 6:00 AM, Yannick Duchêne (Hibou57) wrote:
> Le Sun, 05 Feb 2012 07:52:25 +0100, Nasser M. Abbasi<n...@12000.org> a
> écrit:
>
>> current OpenGL is 4.2, released 8,2012.
>>
>> http://en.wikipedia.org/wiki/OpenGL
>>
>> previous version was 3.3.
>>
>> The Ada openGL binding I could find is
>>
>> http://adaopengl.sourceforge.net/
>>
>> 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
> Le Sun, 05 Feb 2012 07:52:25 +0100, Nasser M. Abbasi<n...@12000.org> a
> écrit:
>
>> current OpenGL is 4.2, released 8,2012.
>>
>> http://en.wikipedia.org/wiki/OpenGL
>>
>> previous version was 3.3.
>>
>> The Ada openGL binding I could find is
>>
>> http://adaopengl.sourceforge.net/
>>
>> 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).
>
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
http://home.arcor.de/hfvogt/programming.html
and it was also last updated in 2002.
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
Erich
Feb 5, 2012, 11:21:47 AM2/5/12
to
> It seems all the Ada pages related to this are old. Here is
> another related page referenced in the readme for Ada openGL
>
> http://home.arcor.de/hfvogt/programming.html
>
http://globe3d.sourceforge.net/
I don't know how recent it is but analyzing the source might be a good
way to learn OpenGL, too.
Yannick Duchêne (Hibou57)
Feb 5, 2012, 9:24:54 PM2/5/12
to
> current OpenGL is 4.2, released 8,2012.
>
> http://en.wikipedia.org/wiki/OpenGL
>
> previous version was 3.3.
>
> The Ada openGL binding I could find is
>
> http://adaopengl.sourceforge.net/
>
> 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:
>
> http://en.wikipedia.org/wiki/OpenGL
>
> previous version was 3.3.
>
> The Ada openGL binding I could find is
>
> http://adaopengl.sourceforge.net/
>
> and was last updated on 2003 ! This is like 100 years ago
> in computer years.
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.
Gautier write-only
Feb 6, 2012, 2:48:28 AM2/6/12
to
On 5 fév, 17:21, Erich <j...@peppermind.com> wrote:
> Have you checked out this?
>
> http://globe3d.sourceforge.net/
>
> 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
> Have you checked out this?
>
> http://globe3d.sourceforge.net/
>
> I don't know how recent it is but analyzing the source might be a good
> way to learn OpenGL, too.
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
BrianG
Feb 6, 2012, 8:33:49 PM2/6/12
to
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.)
--
---
BrianG
000
@[Google's email domain]
.com
Nasser M. Abbasi
Feb 6, 2012, 11:14:55 PM2/6/12
to
On 2/6/2012 7:33 PM, BrianG wrote:
> You could also try GLOBE; it's not OpenGL, but a higher-level library.
> However, it contains an OpenGL binding.
A link?
> You could also try GLOBE; it's not OpenGL, but a higher-level library.
> However, it contains an OpenGL binding.
thanks,
--Nasser
Niklas Holsti
Feb 6, 2012, 11:18:30 PM2/6/12
to
On 12-02-07 03:33 , BrianG wrote:
> 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
> 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}.
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.)
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?
--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
Yannick Duchêne (Hibou57)
Feb 6, 2012, 11:23:45 PM2/6/12
to
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.
> (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.)
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.
Gautier write-only
Feb 7, 2012, 6:44:57 AM2/7/12
to
On 7 fév, 05:14, "Nasser M. Abbasi" <n...@12000.org> wrote:
> On 2/6/2012 7:33 PM, BrianG wrote:
>
> > You could also try GLOBE; it's not OpenGL, but a higher-level library.
> > However, it contains an OpenGL binding.
>
> A link?
http://globe3d.sf.net/
> On 2/6/2012 7:33 PM, BrianG wrote:
>
> > You could also try GLOBE; it's not OpenGL, but a higher-level library.
> > However, it contains an OpenGL binding.
>
> A link?
Enjoy!
BrianG
Feb 7, 2012, 6:00:50 PM2/7/12
to
On 02/06/2012 11:23 PM, Yannick Duchêne (Hibou57) wrote:
> 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
> 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.
>
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).
fas...@gmail.com
Sep 12, 2014, 7:34:31 PM9/12/14
to
Simon Wright
Sep 13, 2014, 3:49:51 AM9/13/14
to
How do you get the "As of 2014-08-31, this project is no longer under
active development." message at the top of the project page?
active development." message at the top of the project page?
darkestkhan
Sep 14, 2014, 8:12:50 AM9/14/14
to
lumen ( https://github.com/karakalo/lumen or its "fork" https://github.com/darkestkhan/lumen ) and
http://flyx.github.io/OpenGLAda/
Not sure about the one from flyx, but I do know that lumen supports at least up to 3.3 (some of that 3.3 stuff I added myself). As for >3.3 I simply wasn't interested in adding it as my hardware has no support for it (if you need I can add). Also lumen provides glut-like functionality. (but the one from me has no support for Windows, due to my cleanup of code under non-ISC license)
0 new messages