Open GL Bindings (was Re: GPGPU Arrays)

[Tristam MacDonald]

Mikola Lysenko Wrote:

> 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;

So don't use derelict - I don't since I didn't want to port it to Mac. Honestly, all you need is a GL header file (run h2d on gl.h and do 5 minutes search & replace - or automate it in perl, whatever), and a platform context toolkit, such as GLFW or SDL, of which several are already around. 

Even better, grab the XML definition files from GLee (www.elf-stone.com), and build a generator script for D (I will do at some point, but haven't needed it yet as I am on Mac, and we have GL 2 in core).

> 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.

Tried setting up PyGame on a Mac recently? Or any system for that matter? Newbie friendly I would not call it. I consider my 'installer foo' to be stronger than most and it took several hours to get the pre-built binaries working. I didn't even go near a source install.

> 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.

Hang on, hang on! D isn't only a PC language is it? Don't forget all that embedded hardware that will never see an OpenGL implementation. Direct frame-buffer access would make more sense, but there are plenty of devices without that as well.

And even if we only deal with PCs, OpenGL is not the only game in town (think Direct3D), and OpenGL is not really that standard... each console manufacturer rolls their own, with little regard for the core standard. Plus lets not forget OpenGL ES, for all those mobile phones, etc.

And then of course there is the upcoming Khronos release, where OpenGL gets split into 'classic' and 'modern', with the fixed function pipeline going the way of the dinosaurs very quickly.

And as far as future proofing, a lot can be done, but how do you deal with an API that has at times added extensions on a monthly basis?

> 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

I would say templated-containers are desperately needed, before everyone rolls their own non-compatible versions. But GUI stuff (and I include OpenGL) in the core library? That requires unified cross-platform GUI toolkits, and I don't really think you will find anyone willing to invest a few million man-hours in that can of worms. What is wrong with just using wxD or similar, rather than polluting the standard lib?