[HOpenGL] OpenGL ES 2.0

[L Corbijn]

On Tue, Apr 16, 2013 at 11:20 PM, Peter Jones <mlists at pmade.com> wrote:

> I'm new to both Haskell and OpenGL so please forgive my ignorance and
> feel free to correct any mistakes.
>
> GHC cross-compiling to ARM (at least for iOS and maybe Android) is
> currently being merged into mainline, making Haskell an attractive
> language for desktop *and* mobile development.  This is still pretty
> bleeding edge but, at least to me, very exciting.
>
> I'm in the planning stages for a couple of applications that will have a
> graphical game-like component to them.  I'd like to use Haskell and I've
> also decided that since I need to support mobile devices the most
> platform agnostic graphics library I can probably get away with is
> OpenGL ES 2.0.
>
> Since OpenGL ES 2.0 is based on OpenGL 2.0 with some modifications and a
> proper subset of OpenGL 4.1 with the GL_ARB_ES2_compatibility extension,
> I'm wondering if the current OpenGL package will work if I restrict
> myself to the ES defined functions.  My research suggests that it won't
> work because there are subtle differences between some of the function
> names and other small incompatibilities.  One major difference being the
> fact that OpenGL doesn't manage the window where drawing happens in ES.
>

> If the existing packages won't work for this then I suppose I'll need to
> write a new raw package for ES and provide some sort of shim layer to
> OpenGL proper so that desktop applications can use the ES API.  My
> initial thoughts for a raw package involve code generation, so I was
> pretty happy when I stumbled upon the OpenGLRawgen repository.
>
> At this point I'm looking to get some feedback on my approach and see if
> anyone wants to work on this with me.
>
> --
> Peter Jones --- Love to Develop
> Devalot: http://www.devalot.com
>
>
> _______________________________________________
> HOpenGL mailing list
> HOpenGL at haskell.org
> http://www.haskell.org/mailman/listinfo/hopengl
>

tl;dr: I think/hope that if OpenGLRaw works (or can be made to work) on the
target platform there should not be any fundamental problems.

I think it is worth making a difference here between HOpenGL and OpenGLRaw.
OpenGLRaw is effectively a listing of enumeration values and functions from
OpenGL. While HOpenGL is just a wrapper around OpenGLRaw. Both of these
could be 'incompatible' with you use. At the moment I can think of three
points which could cause trouble.

The first problem is that the current interfacing with the lower C
libraries might not be correct on your target platform. To use an OpenGL
function you need to query a function pointer to it. This is handled by
OpenGLRaw (see [1] for the implementation). The possible problem might be
that this low level C-stuff cannot be extended to OpenGL ES. This could be
the most fundamental problem or no problem at all, as I don't know much
about the low level C-stuff, I can not tell. Though I'm hopeful as,
according to wikipedia, OpenGL ES applications should be easily portable to
OpenGL.

The second (non-)problem might be some incompatibilities between OpenGL and
OpenGL ES. As you mentioned OpenGL ES is a subset of OpenGL 4.1
and GL_ARB_ES2_compatibility. The latter looks quite simple, so I think
there are no fundamental differences (like name changes or enumerations
that have different values). So I don't think this will be a problem.

The third problem is that OpenGLRaw and HOpenGLmight not define what you
need. This will probably be the case, and I think it is best to differ here
between the two packages.

OpenGLRaw needs updating as it is stuck somewhere around version 3.2. Doing
this by hand is quite simple but laborious.That's why I first started
writing the generator for it, though this is still not used (there is some
discussion about using it on github [2]). The output would probably be good
enough for you as it defines a module with the GL_ARB_ES2_compatibility
extension.

HOpenGL is quite a different story, it is stuck somewhere around version
3.0 is more complicated to update. It involves writing a lot of marshalling
code and defining wrapper enums and (consuming quite some time) reading the
specification. Furthermore there are some missing things from previous
specification. Therefore quite some people have opted to not use HOpenGL
and instead write their own marshalling code for OpenGLRaw.

The naming problem is, as far as I see, not really troubling. The simple
reason for this view is that HOpenGL only uses OpenGLRaw which uses the
original OpenGL names. On the windowing I'm not sure but I think that both
systems delegate the creation and managing of the window to other libraries.

So I don't think (hope) there are no fundamental issues. Though this is
under the assumption that the binding in OpenGLRaw works (or can be made to
work). Whether or not you want to use/improve HOpenGL or write your own
marshalling code is up to you.

Lars

[1]:
https://github.com/haskell-opengl/OpenGLRaw/blob/master/cbits/HsOpenGLRaw.c
[2]: https://github.com/haskell-opengl/OpenGLRaw/issues/3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/hopengl/attachments/20130417/ee3fb0a1/attachment.htm>