Hello Café, Where do you people stand on using OpenGLRaw instead of the higher-level layer? I saw that the ports of the nehe tutorial use directly OpenGLRaw, and I wondered why that choice had been made.
Translation from c is much more straightforward with openglraw compared with OpenGL. Also, many of the design decisions behind OpenGL are arbitrary or limiting, and some features aren't even exposed in its interface.
I'm a bit curious about who might be using GPipe.
I've been trying to find a good variation on OpenGL that integrates nicely
with reactive programming. Issues such as texture management seem to be
rather difficult targets.
On Sat, Jul 23, 2011 at 12:06 PM, Jake McArthur
Translation from c is much more straightforward with openglraw compared with OpenGL. Also, many of the design decisions behind OpenGL are arbitrary or limiting, and some features aren't even exposed in its interface.
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
On Sat, Jul 23, 2011 at 8:51 PM, Yves Parès
Hello Café,
Where do you people stand on using OpenGLRaw instead of the higher-level layer? I saw that the ports of the nehe tutorial use directly OpenGLRaw, and I wondered why that choice had been made.
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Hi, I was/am working on improving the OpenGL package. My view on things is that the Raw package is a pure ffi package that imports the C functions for use in haskell. The OpenGL package tries to make a more type safe interface on top of the Raw package. I think that the nehe tutorials are more easily and readable ported to the raw package (as it's using the raw C). The following is my viewpoint on the current packages, Some reasons for using the Raw package might be - more constant API, it's the raw C api, while the OpenGL package sometimes changes due to adding functionality. - functionality is supported earlier in the Raw package. Some reasons for using the OpenGL package - Better type safety (can't mismatch a Shader and program identifier) - Utility and typeclass (overloaded) functions The biggest disadvantage of the OpenGL package is that it is a bit outdated from the viewpoint of OpenGL functions, I was/am trying to add support for 3.0 and later. Hopefully the package OpenGL will improve over time to include functions for the newer OpenGL API versions. One other option, though not the nicest from somepoints, is using both. The idea is to use where ever possible the functions of the OpenGL package, and where necessary unsafeCoerce the object to the Identifier used by OpenGL and use that for the Raw function. This works because all (as far as I know) the OpenGL objects are represented by newtypes. Hopefully the number of functions where this is needed will be reduced in the near future, as there are quite some points where they are needed (Mostly for OpenGL >= 3.0). Lars Corbijn
participants (4)
-
David Barbour -
Jake McArthur -
L Corbijn -
Yves Parès