Open GL Bindings (was Re: GPGPU Arrays)

[Pragma]

Mikola Lysenko wrote:
> Personally, I think that it would be a bad idea to jump in and add language-level support for GPU specific functions.  The technology is just changing so fast right now that any effort would probably be hopelessly obsolete within a few months.
> 
> That said, I think it would be good to get OpenGL / GLSL bindings into the standard library.  When it comes to graphics, these are basically standard interfaces, and official library support would be huge.  They provide all the basic facilities for handling GPGPU, without the built in expiration date.  Besides, we could leverage the excellent work that has already been done by Aldacron et.al.  Off the top of my head, I can think of a several benefits of this approach:
> 
> 1. Reduced set up hassle
> 
> Right now building derelict is a huge PITA.  I know that Derek Parnell and Aldacron have worked an incredible amount on simplifying this process, but it is hardly automatic.  On Linux, I need to check out the latest version of derelict, download build, compile some set up scripts, add paths to my project, link in libraries, try compiling, then go back and add that -op switch I forgot, etc. etc.
> 
> Making OpenGL work out of the box saves a huge amount of time and agony.  Imagine how wonderful life could be if all one had to do to was add:
> 
> import opengl.gl;
> 
> Which leads into my next point:
> 
> 2.  Built in OpenGL is more newbie friendly
> 
> When it comes to attracting novice programmers, graphics are extremely important.  Most neophyte coders are interested in making games and getting things running around on the screen.  From personal experience, I can say that this is how I learned how to program, and also how many of my friends picked up the skill.  The importance of graphics in attracting and educating new users can not be overstated.
> 
> One of the reasons Python has been so effective in hooking programmers is that they have a robust set of graphics bindings which are easily available.  C# is likewise popular because of its XNA game development framework.  Java has been used in web games since the 1990s, with decent success.   Even C compilers come with OpenGL bindings installed by default.  For newbies, graphics are much more compelling then a terminal.
> 
> Which brings me to my final point;
> 
> 3. OpenGL is standard
> 
> And it has been the standard for graphics since the early 90s.  It works on Mac OS, Linux and even Windows.  Solaris has OpenGL support.  Even video game consoles have OpenGL bindings these days.  In fact, if you include the last category, there are probably more hardware units out there that have OpenGL support than there are systems that support ANSI C-style FILE stream IO.
> 
> Due to its popularity, this interface is probably not going to change much in the coming years.  Granted Khronos group and company are revamping the specification, but it is doubtful that this will happen at the expense of backwards compatibility.
> 
> Besides, Aldacron has basically worked out most of the details involved in getting future-proofed OpenGL bindings up and running.  I'm sure it shouldn't be too hard to work out some scheme for incorporating a stable version of derelict into the main trunk of either Phobos and/or Tango.  The added development overhead would be so low in comparison to the huge benefit for the community.
> 
> Of course not every little feature should get library level support, but it just seems bizarre that something so essential is only available via a third party add on.  Granted, we also need GUI utilities and template containers, but I suspect that both of these will come in time.
> 
> -Mik

This is a very wise recommendation for D.  Building a platform library with everything, including kitchen sink, can be a 
nightmare to maintain - adding something as rudimentary as GL is nowhere close to that scenario, yet gives developers a 
much broader base to build upon.

If I may ask: what is your take on how GL should be provided as a D library?  There are any number of ways to go, 
ranging from a full-fledged OO wrapper to a faithful port of the C headers and interfaces and everything in between 
(assuming you're not proposing that we just fold Derelict in with Phobos or Tango).

-- 
- EricAnderton at yahoo