On Tue, Apr 16, 2013 at 11:20 PM, Peter Jones
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@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