- Framebuffers and renderbuffers in combination with the default framebuffer probably should be looked at. This is one of the more complex parts and I am not sure about what I wrote (I had less experience back then).

For what it's worth, I implemented framebuffer / renderbuffer objects back in 2009 (before OpenGLRaw), and I'm using that since. I tried to follow the existing conventions of the library. Darcs patches are here: http://code.haskell.org/~bkomuves/hopengl_2009-03-13.patch - Part of the sharderprogram API, the matrix uniforms needs urgent fixing.

I also remember having some issues with the uniforms. - The texture API, currently it is very old and can IIRC only be used

for 1,2,3D textures and maybe cubemaps. Furthermore without changing the API this is probably not resolvable and otherwise not future proof.

Cubemaps worked with the old API (or at least I think I used them). Balazs On Sun, Aug 11, 2013 at 10:16 PM, L Corbijn wrote:

On Sun, Aug 4, 2013 at 4:47 PM, Sven Panne wrote:

...

While going through the latest and greatest Red Book (8th ed., for OpenGL 4.3), I've come to the conclusion that the current shader API ( http://lambda.haskell.org/platform/doc/current/packages/OpenGL-2.8.0.0/doc/h... ) is fundamentally broken. It was designed at a time when shaders were very new, so I had very little experience with them and how to expose them to Haskell nicely, and the underlying C API has been vastly extended over the last few years.

As I see it, there is no good backwards-compatible way of improving the API, even though I would prefer that: I would really like to change Shader from a type class into a normal algebraic data type, changing quite a few signatures because of that on the way. This would make things much easier and straightforward, and it would be much more in the spirit of the OpenGL C API, where all shader types are treated more or less the same.

Corollary: http://www.haskell.org/haskellwiki/Package_versioning_policy implies that the major version of the OpenGL package has to change, and because re-exports the GLUT package version number has to change, too, correct?

Any thoughts, opinions and proposals are appreciated.

Cheers, S.

_______________________________________________ HOpenGL mailing list HOpenGL@haskell.org http://www.haskell.org/mailman/listinfo/hopengl

It sounds like a good idea to change the API. An attempt [1] was made at extending it to include geometry shaders, but the result was in my opinion not satisfactory.

As there is no function that depends on the shadertype that I could find on the reference card for OpenGL 4.3 (though I could have missed it). So switching to an algebraic data type seems to me as a good idea. The only disadvantage is that it can no longer be a ObjectName, as the shader needs a type to create.

When doing so we indeed need to bump the major version. But as we are revamping part of the API it might be worth wile to also redesign and fix other parts as well. The following parts come to mind: - The texture API, currently it is very old and can IIRC only be used for 1,2,3D textures and maybe cubemaps. Furthermore without changing the API this is probably not resolvable and otherwise not future proof. - Framebuffers and renderbuffers in combination with the default framebuffer probably should be looked at. This is one of the more complex parts and I am not sure about what I wrote (I had less experience back then). - Part of the sharderprogram API, the matrix uniforms needs urgent fixing.

Lars

[1]: https://github.com/haskell-opengl/OpenGL/pull/34

_______________________________________________ HOpenGL mailing list HOpenGL@haskell.org http://www.haskell.org/mailman/listinfo/hopengl