<div dir="ltr"><div><div><div><div><br>Sven, first of all it's very nice to see you back again! HOpenGL was one of my early, and influential Haskell experiences.<br><br></div><div>I prefer one big package opposed to separate StateVar etc, but that's just a subjective opinion.<br>
</div><div><br></div>The newtypes (GLDouble etc) are both inconvenient and very slow because GHC sees fromRational/toRational which it cannot optimize away. In my personal projects I actually used unsafeCoerce, which kind of illustrates the seriousness of this issue... <br>
<br></div><div>I fully agree with supporting old-school OpenGL, it's much much easier to start with than modern OpenGL.<br><br></div>I'm not up to date with the latest versions, both because I don't really have modern hardware, and because I use what is basically a fork of the old version (with render-to-texture and other stuff added). It's probably horribly outdated, but in any case, I think the patches are here: <a href="http://code.haskell.org/~bkomuves/hopengl_2009-03-13.patch">http://code.haskell.org/~bkomuves/hopengl_2009-03-13.patch</a><br>
<br></div>Offtopic, but examples of "real-world" Haskell OpenGL stuff can be seen here: <a href="http://moire.be/misszio/">http://moire.be/misszio/</a> (almost all of that is Haskell, sometimes with minor C code)<br>
<br></div>Balazs<br><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jul 22, 2013 at 11:23 AM, Sven Panne <span dir="ltr"><<a href="mailto:svenpanne@gmail.com" target="_blank">svenpanne@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">After a few HOpenGL-free years caused by personal and job-related<br>
circumstances, I'd like to work on this again. First of thanks to all<br>
the people involved in keeping the binding alive, especially Jason!<br>
Having the packages in the Haskell platform is simply great, because<br>
it improves the visibility of the binding a lot and will keep new<br>
users (and new bug reports ;-) coming.<br>
<br>
I've browsed through the mailing list archives, so here are a few<br>
miscellaneous remarks:<br>
<br>
* The StateVar/Tensor/ObjectName packages are now in the OpenGL<br>
package itself (in a different namespace), and the previous standalone<br>
packages are still available, too. Although I don't think it is a<br>
perfect solution, it was probably done to get the OpenGL packages into<br>
the Haskell platform, right? If this was the motivation, I think the<br>
price to pay was well worth it. The OpenAL/ALUT packages use the<br>
assimilated packages, too, so I should probably update the former ones<br>
to use the latter ones. This will introduce a dependency of<br>
OpenAL/ALUT on OpenGL, something I wanted to avoid. But I think there<br>
are very few programs using OpenAL without OpenGL, and the latter is<br>
now universally available via the Haskell platformm, so this should be<br>
the right way to proceed.<br>
<br>
* What was the exact motivation for using type synonyms instead of<br>
the former renamings (newtypes) for the OpenGL types? Were there any<br>
*real* problems or only potential/hypothetical ones? I am a bit torn<br>
between those alternatives, so I'd like to learn the experience of<br>
other people, including their opinions.<br>
<br>
* The examples have bit-rotted, e.g. SmoothOpenGL3.hs yields an<br>
InvalidOperation in triangle's vertexAttribPointer calls, 'catch'<br>
should probably be replaced by Control.Exception.{catch,IOException},<br>
etc. Apart from fixing them, having GLUT versions of nehe-tuts in the<br>
GLUT package would be great. I really like the idea of GLUT being a<br>
one-stop-shop for tons of examples regarding the usage of the<br>
OpenGL/OpenGLRaw packages.<br>
<br>
* Currently the binding doesn't work out-of-the box with ghci on<br>
Ubuntu 12.04 if you have NVIDIA drivers installed in addition to the<br>
Mesa ones. I have an ugly fix (adding /usr/lib/nvidia/current to<br>
OpenGLRaw's library-dirs), but I'd like to solve this more cleanly.<br>
More about this in a separate mail.<br>
<br>
* Finally Khronos has released the OpenGL registry in a less<br>
braindead format<br>
(<a href="http://www.opengl.org/discussion_boards/showthread.php/181927-New-XML-based-API-Registry-released?p=1251759" target="_blank">http://www.opengl.org/discussion_boards/showthread.php/181927-New-XML-based-API-Registry-released?p=1251759</a>),<br>
so there is a good chance now that the OpenGLRaw package can be<br>
completely autogenerated, something I wanted to do for ages. Judging<br>
from the HOpenGL mailing list, Lars is already looking into it, so<br>
let's coordinate our efforts here, preferably in a separate mail<br>
thread. My main concerns here are: Include the generator (plus<br>
pre-generated bindings) in the OpenGLRaw package, it really belongs<br>
there. Don't put anything clever into OpenGLRaw, it should really,<br>
really be a plain, straightforward 1:1 mapping of the registry. No<br>
name mangling, structural modifications etc. apart from things<br>
automatically derivable from the XML registry. A big question remains:<br>
Can we generate the (un-)marshaling functions already in OpenGLRaw?<br>
The XML registry has <groups>/<group> tags, but I fear that they are<br>
still too incomplete/incorrect to be of any use for the Haskell<br>
binding. On the positive side, I think that it should be possible to<br>
upstream changes to the registry to make it more useful in general. I<br>
had contact with Jon Leech in the past, and he has always been very<br>
open and helpful.<br>
<br>
* Given the fact that OpenGL 4.3 is quite different from OpenGL in<br>
the "old days", there are quite a few design decisions in the OpenGL<br>
(convenience) package that I would do differently nowadays. But I<br>
think with the feedback from the community we can gradually tweak this<br>
layer to something more useful and up-to-date. Perhaps we can somehow<br>
re-arrange things to be more in line with OpenGL versions/profiles,<br>
but whatever we do, we should not drop support for "old skool" OpenGL,<br>
there are *tons* of tutorials, books and courses relying on it, and<br>
even NVIDIA has effectively promised to support this forever.<br>
<br>
Cheers,<br>
S.<br>
<br>
_______________________________________________<br>
HOpenGL mailing list<br>
<a href="mailto:HOpenGL@haskell.org">HOpenGL@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/hopengl" target="_blank">http://www.haskell.org/mailman/listinfo/hopengl</a><br>
</blockquote></div><br></div>