[HOpenGL] Back again

[Mike Ledger]

I made very little contribution to the decision (just submitting an issue
on github a while ago), but I'm very positive about the decision to switch
to type synonyms instead of newtypes.

In my experience, the newtypes added an inconvenience that seemed to imply
that the only safe way to convert between GL* types and their corresponding
C* types is to use fromIntegral/realToFrac, which can be *very*
inconvenient, especially if your data is in a Ptr (as OpenGL often expects
for anything but the fixed-function pipeline). When binding to C libraries,
you have to create wrappers around your functions to convert between GL
types and C types (provided they use C types and their GL typedefs), if you
buy into GL types truly being different.

A specific problem I ran into was (see ) that GLchar being a newtype meant
that I had to use castPtr to convert to and from CString or Ptr CString to
Ptr (Ptr GLchar).

On https://github.com/haskell-opengl/OpenGLRaw/pull/11 is my issue. Jason
Dagit's response is probably of interest to you as well.

As for more modern OpenGL things, for my recent game (that excusively used
"modern" OpenGL, aside from glRaster* to draw text with ftgl), I made some
nice wrappers around OpenGL things, that had no overhead while still being
more than just convenience wrappers (something that can't be said about
OpenGL, the package, today), and I'd like to get them into a package
sometime, when I have more time.

Mike

On Mon, Jul 22, 2013 at 7:23 PM, 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/414e9673/attachment.htm>