[HOpenGL] Back again

[Balazs Komuves]

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 <svenpanne at gmail.com> wrote:

> 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-API-Registry-released?p=1251759
> ),
> 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/hopengl
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/hopengl/attachments/20130722/596262bd/attachment.htm>