www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - OpenGL support.... is it possible and if so...

reply Jacob Santos <Jacob_member pathlink.com> writes:
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.
Jun 10 2004
next sibling parent reply Daniel Horn <hellcatv hotmail.com> writes:
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.
Jun 10 2004
parent reply Jacob Santos <Jacob_member pathlink.com> writes:
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
Jun 10 2004
parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
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/
Jun 10 2004
parent reply J Santos <J_member pathlink.com> writes:
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/
Jun 10 2004
parent J Anderson <REMOVEanderson badmama.com.au> writes:
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/
Jun 10 2004
prev sibling next sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
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/
Jun 10 2004
parent reply J Santos <J_member pathlink.com> writes:
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/
Jun 10 2004
parent J Anderson <REMOVEanderson badmama.com.au> writes:
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/
Jun 10 2004
prev sibling parent "Glenn M. Lewis" <noSpam noSpam.com> writes:
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.
Jun 16 2004