Re: Shader API changes

--===============0235475578840518570==
Content-Type: multipart/alternative; boundary=001a1133aa8667f9f704e3d21788

--001a1133aa8667f9f704e3d21788
Content-Type: text/plain; charset=UTF-8

> - 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 <[email protected]> wrote:

> On Sun, Aug 4, 2013 at 4:47 PM, Sven Panne <[email protected]> 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
> > [email protected]
> > 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
> [email protected]
> http://www.haskell.org/mailman/listinfo/hopengl
>

--001a1133aa8667f9f704e3d21788
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><br><blockquote style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left:1px solid rgb(204,204,204);padding-left:1ex" class=3D"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&#39;s worth, I imple=
mented framebuffer / renderbuffer objects back in 2009 (before OpenGLRaw), =
and I&#39;m using that since. I tried to follow the existing conventions of=
 the library. Darcs patches are here: <a href=3D"http://code.haskell.org/~b=
komuves/hopengl_2009-03-13.patch">http://code.haskell.org/~bkomuves/hopengl=
_2009-03-13.patch</a><br>
<br><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb=
(204,204,204);padding-left:1ex" class=3D"gmail_quote">- Part of the sharder=
program API, the matrix uniforms needs urgent fixing.<br></blockquote><br><=
/div>
<div>I also remember having some issues with the uniforms.<br></div><div><b=
r><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(2=
04,204,204);padding-left:1ex" class=3D"gmail_quote">- The texture API, curr=
ently 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=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Sun, Aug 11, 20=
13 at 10:16 PM, L Corbijn <span dir=3D"ltr">&lt;<a href=3D"mailto:aspergeso=
[email protected]" target=3D"_blank">[email protected]</a>&gt;</span> wr=
ote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div class=3D""><div clas=
s=3D"h5">On Sun, Aug 4, 2013 at 4:47 PM, Sven Panne &lt;<a href=3D"mailto:s=
[email protected]">[email protected]</a>&gt; wrote:<br>

&gt; While going through the latest and greatest Red Book (8th ed., for<br>
&gt; OpenGL 4.3), I&#39;ve come to the conclusion that the current shader A=
PI<br>
&gt; (<a href=3D"http://lambda.haskell.org/platform/doc/current/packages/Op=
enGL-2.8.0.0/doc/html/Graphics-Rendering-OpenGL-GL-Shaders.html" target=3D"=
_blank">http://lambda.haskell.org/platform/doc/current/packages/OpenGL-2.8.=
0.0/doc/html/Graphics-Rendering-OpenGL-GL-Shaders.html</a>)<br>

&gt; is fundamentally broken. It was designed at a time when shaders were<b=
r>
&gt; very new, so I had very little experience with them and how to expose<=
br>
&gt; them to Haskell nicely, and the underlying C API has been vastly<br>
&gt; extended over the last few years.<br>
&gt;<br>
&gt; As I see it, there is no good backwards-compatible way of improving<br=
>
&gt; the API, even though I would prefer that: I would really like to<br>
&gt; change Shader from a type class into a normal algebraic data type,<br>
&gt; changing quite a few signatures because of that on the way. This would=
<br>
&gt; make things much easier and straightforward, and it would be much more=
<br>
&gt; in the spirit of the OpenGL C API, where all shader types are treated<=
br>
&gt; more or less the same.<br>
&gt;<br>
&gt; Corollary: <a href=3D"http://www.haskell.org/haskellwiki/Package_versi=
oning_policy" target=3D"_blank">http://www.haskell.org/haskellwiki/Package_=
versioning_policy</a><br>
&gt; implies that the major version of the OpenGL package has to change,<br=
>
&gt; and because re-exports the GLUT package version number has to change,<=
br>
&gt; too, correct?<br>
&gt;<br>
&gt; Any thoughts, opinions and proposals are appreciated.<br>
&gt;<br>
&gt; Cheers,<br>
&gt; =C2=A0 =C2=A0S.<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; HOpenGL mailing list<br>
&gt; <a href=3D"mailto:[email protected]">[email protected]</a><br>
&gt; <a href=3D"http://www.haskell.org/mailman/listinfo/hopengl" target=3D"=
_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] wa=
s 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=3D"https://github.com/haskell-opengl/OpenGL/pull/34" target=3D=
"_blank">https://github.com/haskell-opengl/OpenGL/pull/34</a><br>
<div class=3D""><div class=3D"h5"><br>
_______________________________________________<br>
HOpenGL mailing list<br>
<a href=3D"mailto:[email protected]">[email protected]</a><br>
<a href=3D"http://www.haskell.org/mailman/listinfo/hopengl" target=3D"_blan=
k">http://www.haskell.org/mailman/listinfo/hopengl</a><br>
</div></div></blockquote></div><br></div></div></div>

--001a1133aa8667f9f704e3d21788--


--===============0235475578840518570==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
HOpenGL mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/hopengl

--===============0235475578840518570==--