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