[HOpenGL] Shader API changes

[Balazs Komuves]

> - 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 <aspergesoepje at gmail.com> wrote:

> On Sun, Aug 4, 2013 at 4:47 PM, Sven Panne <svenpanne at gmail.com> 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/html/Graphics-Rendering-OpenGL-GL-Shaders.html
> )
> > 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 at 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 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/20130813/fa9da448/attachment.htm>