<div dir="ltr"><div><br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">- Framebuffers and renderbuffers in combination with the default<br>
framebuffer probably should be looked at. This is one of the more<br>
complex parts and I am not sure about what I wrote (I had less<br>
experience back then).<br></blockquote><br>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: <a href="http://code.haskell.org/~bkomuves/hopengl_2009-03-13.patch">http://code.haskell.org/~bkomuves/hopengl_2009-03-13.patch</a><br>
<br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">- Part of the sharderprogram API, the matrix uniforms needs urgent fixing.<br></blockquote><br></div>
<div>I also remember having some issues with the uniforms.<br></div><div><br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">- The texture API, currently it is very old and can IIRC only be used<br>
for 1,2,3D textures and maybe cubemaps. Furthermore without changing<br>
the API this is probably not resolvable and otherwise not future<br>
proof.<br></blockquote><br></div><div>Cubemaps worked with the old API (or at least I think I used them).<br></div><div><br></div>Balazs<br><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Aug 11, 2013 at 10:16 PM, L Corbijn <span dir="ltr"><<a href="mailto:aspergesoepje@gmail.com" target="_blank">aspergesoepje@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class="h5">On Sun, Aug 4, 2013 at 4:47 PM, Sven Panne <<a href="mailto:svenpanne@gmail.com">svenpanne@gmail.com</a>> wrote:<br>
> While going through the latest and greatest Red Book (8th ed., for<br>
> OpenGL 4.3), I've come to the conclusion that the current shader API<br>
> (<a href="http://lambda.haskell.org/platform/doc/current/packages/OpenGL-2.8.0.0/doc/html/Graphics-Rendering-OpenGL-GL-Shaders.html" target="_blank">http://lambda.haskell.org/platform/doc/current/packages/OpenGL-2.8.0.0/doc/html/Graphics-Rendering-OpenGL-GL-Shaders.html</a>)<br>
> is fundamentally broken. It was designed at a time when shaders were<br>
> very new, so I had very little experience with them and how to expose<br>
> them to Haskell nicely, and the underlying C API has been vastly<br>
> extended over the last few years.<br>
><br>
> As I see it, there is no good backwards-compatible way of improving<br>
> the API, even though I would prefer that: I would really like to<br>
> change Shader from a type class into a normal algebraic data type,<br>
> changing quite a few signatures because of that on the way. This would<br>
> make things much easier and straightforward, and it would be much more<br>
> in the spirit of the OpenGL C API, where all shader types are treated<br>
> more or less the same.<br>
><br>
> Corollary: <a href="http://www.haskell.org/haskellwiki/Package_versioning_policy" target="_blank">http://www.haskell.org/haskellwiki/Package_versioning_policy</a><br>
> implies that the major version of the OpenGL package has to change,<br>
> and because re-exports the GLUT package version number has to change,<br>
> too, correct?<br>
><br>
> Any thoughts, opinions and proposals are appreciated.<br>
><br>
> Cheers,<br>
> S.<br>
><br>
> _______________________________________________<br>
> HOpenGL mailing list<br>
> <a href="mailto:HOpenGL@haskell.org">HOpenGL@haskell.org</a><br>
> <a href="http://www.haskell.org/mailman/listinfo/hopengl" target="_blank">http://www.haskell.org/mailman/listinfo/hopengl</a><br>
<br>
</div></div>It sounds like a good idea to change the API. An attempt [1] was made<br>
at extending it to include geometry shaders, but the result was in my<br>
opinion not satisfactory.<br>
<br>
As there is no function that depends on the shadertype that I could<br>
find on the reference card for OpenGL 4.3 (though I could have missed<br>
it). So switching to an algebraic data type seems to me as a good<br>
idea. The only disadvantage is that it can no longer be a ObjectName,<br>
as the shader needs a type to create.<br>
<br>
When doing so we indeed need to bump the major version. But as we are<br>
revamping part of the API it might be worth wile to also redesign and<br>
fix other parts as well. The following parts come to mind:<br>
- The texture API, currently it is very old and can IIRC only be used<br>
for 1,2,3D textures and maybe cubemaps. Furthermore without changing<br>
the API this is probably not resolvable and otherwise not future<br>
proof.<br>
- Framebuffers and renderbuffers in combination with the default<br>
framebuffer probably should be looked at. This is one of the more<br>
complex parts and I am not sure about what I wrote (I had less<br>
experience back then).<br>
- Part of the sharderprogram API, the matrix uniforms needs urgent fixing.<br>
<br>
Lars<br>
<br>
<br>
[1]: <a href="https://github.com/haskell-opengl/OpenGL/pull/34" target="_blank">https://github.com/haskell-opengl/OpenGL/pull/34</a><br>
<div class=""><div class="h5"><br>
_______________________________________________<br>
HOpenGL mailing list<br>
<a href="mailto:HOpenGL@haskell.org">HOpenGL@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/hopengl" target="_blank">http://www.haskell.org/mailman/listinfo/hopengl</a><br>
</div></div></blockquote></div><br></div></div></div>