I was wondering if OpenGL API is going to be, is, or will be part of the D Programming Language. If it is, which I think it could very well be given interfacing with C, then some overloading problems could very well be solved. This of course seeing as what I could read, either templating is harder than C++ or easier (which may well be the case), and would allow for the API to omitt the need to have f, i, s, and so on along with 1, 2, 3, and 4 at the end of functions. If given the time the API could be made into classes allowing greater tasks to be performed on objects such as cubes, spheres, and what not.

One may question the reason or possiblity of even trying to create this package as  it could very well be as a big of a waste of time as my writing this. I ask what could be done to the current API to simplify and/or extend the API. Nothing can really be done as the API may always be created in C to allow the greatest portability between platforms. Unless of course D comes to play and the API is ported over to D.

I wrote one already--it loads all the extensions as well
nab it at
http://svn.dsource.org/svn/projects/deliria/
enjoy :-) I put that under the BSD license

Jacob Santos wrote:
> I was wondering if OpenGL API is going to be, is, or will be part of the D
> Programming Language. If it is, which I think it could very well be given
> interfacing with C, then some overloading problems could very well be solved.
> This of course seeing as what I could read, either templating is harder than C++
> or easier (which may well be the case), and would allow for the API to omitt the
> need to have f, i, s, and so on along with 1, 2, 3, and 4 at the end of
> functions. If given the time the API could be made into classes allowing greater
> tasks to be performed on objects such as cubes, spheres, and what not.
> 
> One may question the reason or possiblity of even trying to create this package
> as  it could very well be as a big of a waste of time as my writing this. I ask
> what could be done to the current API to simplify and/or extend the API. Nothing
> can really be done as the API may always be created in C to allow the greatest
> portability between platforms. Unless of course D comes to play and the API is
> ported over to D.
> 
> 

Jacob Santos wrote:

>I was wondering if OpenGL API is going to be, is, or will be part of the D
>Programming Language. If it is, which I think it could very well be given
>interfacing with C, then some overloading problems could very well be solved.
>This of course seeing as what I could read, either templating is harder than C++
>or easier (which may well be the case), and would allow for the API to omitt the
>need to have f, i, s, and so on along with 1, 2, 3, and 4 at the end of
>functions. If given the time the API could be made into classes allowing greater
>tasks to be performed on objects such as cubes, spheres, and what not.
>
>One may question the reason or possiblity of even trying to create this package
>as  it could very well be as a big of a waste of time as my writing this. I ask
>what could be done to the current API to simplify and/or extend the API. Nothing
>can really be done as the API may always be created in C to allow the greatest
>portability between platforms. Unless of course D comes to play and the API is
>ported over to D.
>  
>
Burton's dig (undig) created a class version of openGL, although the C old version is also supported.  For example instead of passing in a colour as 4 params you can pass in a color class.  See my website and www.dsource.org for the latest version. 

The openGL API has been ported about 5 times for D :)

-- 
-Anderson: http://badmama.com.au/~anderson/

What I had in mind was something such as:
import opengl32.gl;
OpenGLOject Triangle;
Triangle.begin(GL_TRIANGLE);
Triangle.color(0.0, 1.0, 1.0, 0.75);
Triangle.vertex(0.9, 0.9, 0.0);
Triangle.vertex(0.3, 0.5, 0.0);
Triangle.vertex(0.0, 0.1, 0.0);

But I believe this wouldn't be possible unless you directly recompile the DLL and even so you would still have to follow C rules so the above is impossible. C++ is awesome but there are somethings you can never do with it. Unless of course I over looked the documention of D creating DLLs. Nevermind that you can't do that to the Windows DLL so there is no point of trying it.

One could, create a set of classes from your module and create a OpenGL framework that works off of it but it would likely produce unwanted overhead in the application and therefore would most likely never be accepted. That and the OpenGL specification would be sent to hell and code would have to be rewritten. I guess it isn't practical in the sense of the rioting and having whoever wrote it head on a pike on some wall somewhere. It would be really cool, I think anyway. One can dream and use it for himself, I think.

I like D better than C already but I still think I shouldn't have to think about what type I'm sending to the screen using printf. I Like cout and cin, along with sstream class better but I guess that may because it is where I started. Never really thought I would have to deal with damnable C code again. Doesn't pay well to be a fool. I like the path D is heading but I doubt anything will change with printf. Wonder if you couldn't just build a class that does the conversions for you and places everything into a string and then places the string into a printf("%s", string); at the very end. I have no idea how the iostream class works so I can't say.

>I wrote one already--it loads all the extensions as well
>nab it at
>http://svn.dsource.org/svn/projects/deliria/
>enjoy :-) I put that under the BSD license

Jacob Santos wrote:

>What I had in mind was something such as:
>import opengl32.gl;
>OpenGLOject Triangle;
>Triangle.begin(GL_TRIANGLE);
>Triangle.color(0.0, 1.0, 1.0, 0.75);
>Triangle.vertex(0.9, 0.9, 0.0);
>Triangle.vertex(0.3, 0.5, 0.0);
>Triangle.vertex(0.0, 0.1, 0.0);
>  
>

Try undig. The documentation is here http://www.opend.org/dig/classGL.html.  But don't use the version from that website as it no longer works.

Rather then start from scratch (Burton put a lot of work into dig), you could contribute to the undig project if you like and make the opengl stuff even better.

-- 
-Anderson: http://badmama.com.au/~anderson/

Wow, a work of art! Well, eventually the weaker implementations will be weeded out or all will form into one. Although, I do like digs classes.

>Burton's dig (undig) created a class version of openGL, although the C old version is also supported.  For example instead of passing in a colour as 4 params you can pass in a color class.  See my website and www.dsource.org for the latest version.
>
>The openGL API has been ported about 5 times for D :)
>
>-- 
>-Anderson: http://badmama.com.au/~anderson/

J Santos wrote:

>Wow, a work of art! Well, eventually the weaker implementations will be weeded
>out or all will form into one. Although, I do like digs classes.
>  
>
The problem with dig is that there a few things missing that you only spot as you need them but then it is still developing at a snails pace.   Note that dig also has matrix classes + vectors and a gui system that all work with openGL.

-- 
-Anderson: http://badmama.com.au/~anderson/

Not a bad idea. I will have to figure out how to compile code with the compiler or use the compiler I mean. Thanks for your help and support. The classes really are better than anything I could dream of doing.

>Try undig. The documentation is here http://www.opend.org/dig/classGL.html.  But don't use the version from that website as it no longer works.
>
>Rather then start from scratch (Burton put a lot of work into dig), you could contribute to the undig project if you like and make the opengl stuff even better.
>
>-- 
>-Anderson: http://badmama.com.au/~anderson/

J Santos wrote:

>Not a bad idea. I will have to figure out how to compile code with the compiler
>or use the compiler I mean. Thanks for your help and support. The classes really
>are better than anything I could dream of doing.
>  
>
If you need any help on undig contact the undig forum at: http://www.dsource.org/forums/

-- 
-Anderson: http://badmama.com.au/~anderson/

Check out http://glfw.sourceforge.net/
It has complete OpenGL bindings for the D language in the current CVS version.
Marcus hasn't got around to releasing version 2.4.2 yet that I know of, but if
you checkout all the source from the repository, all the examples are there for D,
and it works great.
-- Glenn

Jacob Santos wrote:

> I was wondering if OpenGL API is going to be, is, or will be part of the D
> Programming Language. If it is, which I think it could very well be given
> interfacing with C, then some overloading problems could very well be solved.
> This of course seeing as what I could read, either templating is harder than C++
> or easier (which may well be the case), and would allow for the API to omitt the
> need to have f, i, s, and so on along with 1, 2, 3, and 4 at the end of
> functions. If given the time the API could be made into classes allowing greater
> tasks to be performed on objects such as cubes, spheres, and what not.
> 
> One may question the reason or possiblity of even trying to create this package
> as  it could very well be as a big of a waste of time as my writing this. I ask
> what could be done to the current API to simplify and/or extend the API. Nothing
> can really be done as the API may always be created in C to allow the greatest
> portability between platforms. Unless of course D comes to play and the API is
> ported over to D.
> 
>