From svenpanne at gmail.com  Mon Jan  4 16:18:08 2016
From: svenpanne at gmail.com (Sven Panne)
Date: Mon, 4 Jan 2016 17:18:08 +0100
Subject: [HOpenGL] [Haskell-cafe] Merging the OpenGLRaw and gl packages
In-Reply-To: <CANBN=mtnUgU-Kdec54mC02=UBBsgh_si+3mSMUVfZpGhGy70kA@mail.gmail.com>
References: <CANBN=msHkd14O2PAsCGoXE=SAWhe8Zzisho3FeiC1P6Y7OFJ-w@mail.gmail.com>
 <CANBN=msTe-=fB6p89-4+iBQ3vj_8GY-o-j1Ee9iH2-DGTc_itg@mail.gmail.com>
 <CAJ5riwL1xJeTaxueoV6bbH+t6fY04B2kPFyzbUG4c3iLApzrAA@mail.gmail.com>
 <CANBN=mt-tWyE=t1gJ9_G2sZZH9KSJ58hRTeJpgW5knDFMLCsJg@mail.gmail.com>
 <CAGRp5RmoNM7NR8sGoRBtpWJNdb1c8m0TfixkvyVA-sYPo4x8Lw@mail.gmail.com>
 <CANBN=mtnUgU-Kdec54mC02=UBBsgh_si+3mSMUVfZpGhGy70kA@mail.gmail.com>
Message-ID: <CANBN=msyFBRviiLZOqg1ETgwn53G8gWYasSOPKM2Wafup-nQHA@mail.gmail.com>

FYI: I've released a new OpenGLRaw version 3.0.0.0 which is now quite close
to the gl package. The changes:

  * Use pattern synonyms for OpenGL enums.
  * Changed module name prefix from Graphics.Rendering.OpenGL.Raw to
Graphics.GL.
  * Use slightly different type synonyms for GL type (introducing Fixed on
the way):
      * CDouble => Double (for GLclampd, GLdouble)
      * CFloat => Float (for GLclampf, GLfloat)
      * CInt => Fixed (for GLclampx, GLfixed)
      * CInt => Int32 (for GLint, GLsizei)
      * CSChar => Int8 (for GLbyte)
      * CShort => Int16 (for GLshort)
      * CUChar => Word8 (for GLboolean, GLubyte)
      * CUInt => Word32 (for GLbitfield, GLenum, GLhandleARB, GLuint)
      * CUShort => Word16 (for GLushort)

There are still a few minor differences between OpenGLRaw and gl (see
https://github.com/haskell-opengl/OpenGLRaw/wiki/Merging-OpenGLRaw-and-gl),
but nothing serious: As a test, I modified the luminance package to make it
compatible with the new OpenGLRaw, and the diff is really small (see
https://github.com/phaazon/luminance/pull/39). So I think that the gl
package can be retired, but that's of course totally up to Edward and
Gabr?el. A few remarks:

  * Using pattern synonyms means losing support for GHC < 7.8, which I
consider OK now that 8.0 is coming soon. But to be sure, there is a branch
("classic") for the previous OpenGLRaw API if the need for minor
changes/bug fixes arises.

  * To stay consistent, GLURaw has been changed in a similar way.

  * The OpenGL package has been adapted to use the new APIs internally, but
its external API is still the same.

Cheers,
   S.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/hopengl/attachments/20160104/40f0bb5d/attachment.html>

From Tommyschnabel at gmail.com  Sun Jan 10 15:43:56 2016
From: Tommyschnabel at gmail.com (Tommy Schnabel)
Date: Sun, 10 Jan 2016 15:43:56 +0000 (UTC)
Subject: [HOpenGL] Regal and cross platform 3D
References: <C2B3173D-9AE8-4ACA-A9E4-D41BC1041AC1@animalinside.eu>
Message-ID: <loom.20160110T164138-761@post.gmane.org>

Jelle Hermsen <jelle <at> animalinside.eu> 
writes:

> 
> 
> Hiya everybody,
> I?m planning to build a cross platform 
3D application in Haskell and I?m thinking 
about using Regal 
(https://github.com/p3/regal?)?as an 
abstraction layer so I can support OpenGL 
2.x, 3.x, 4.x and ES 2.0 with the same 
code base. Has any of you have tried to 
use it with HopenGL / OpenGLRaw?
> 
> Cheers,
> Jelle
> 
> 
> 
__________________________________________
_____
> HOpenGL mailing list
> HOpenGL <at> haskell.org
> 
http://www.haskell.org/mailman/listinfo/ho
pengl
> 

Did you ever do this, and did you have any 
luck? I'm looking to do something similar.

Thanks,

Tommy

From svenpanne at gmail.com  Sun Jan 10 19:42:56 2016
From: svenpanne at gmail.com (Sven Panne)
Date: Sun, 10 Jan 2016 20:42:56 +0100
Subject: [HOpenGL] [Haskell-cafe] Merging the OpenGLRaw and gl packages
In-Reply-To: <CANBN=msyFBRviiLZOqg1ETgwn53G8gWYasSOPKM2Wafup-nQHA@mail.gmail.com>
References: <CANBN=msHkd14O2PAsCGoXE=SAWhe8Zzisho3FeiC1P6Y7OFJ-w@mail.gmail.com>
 <CANBN=msTe-=fB6p89-4+iBQ3vj_8GY-o-j1Ee9iH2-DGTc_itg@mail.gmail.com>
 <CAJ5riwL1xJeTaxueoV6bbH+t6fY04B2kPFyzbUG4c3iLApzrAA@mail.gmail.com>
 <CANBN=mt-tWyE=t1gJ9_G2sZZH9KSJ58hRTeJpgW5knDFMLCsJg@mail.gmail.com>
 <CAGRp5RmoNM7NR8sGoRBtpWJNdb1c8m0TfixkvyVA-sYPo4x8Lw@mail.gmail.com>
 <CANBN=mtnUgU-Kdec54mC02=UBBsgh_si+3mSMUVfZpGhGy70kA@mail.gmail.com>
 <CANBN=msyFBRviiLZOqg1ETgwn53G8gWYasSOPKM2Wafup-nQHA@mail.gmail.com>
Message-ID: <CANBN=mukYRbog07VR3Tt56rg5kdfw3HK5uQVEDXfPDYZc9=5KQ@mail.gmail.com>

After some discussions and looking at the diffs needed to make the
`luminance` package and Oliver Charles' SSAO-example use OpenGLRaw instead
of gl, I decided to change the types of GL_TRUE and GL_FALSE from GLenum to
GLboolean. When these enums are used as parameters, their type is almost
always GLboolean, with glClampColor being the only exception. Some general
retrieval functions like glProgramiv return boolean values as GLint, but
that seems to be the rarer use case. OpenGL is very loosely typed, so you
will have to use some fromIntegral calls, even if the enum patterns were
more polymorphic. After several decades of computer science and having seen
tons of bugs caused by them, I have a strong aversion to implicit
conversions, so I'm still convinced that the monomorphic enums are the
right thing. :-)

I made a new release of OpenGLRaw (
https://github.com/haskell-opengl/OpenGLRaw/releases/tag/v3.1.0.0), which
in addition to this typing change contains some "mkFoo" synonyms for the
"makeFoo" functions, too, a difference between OpenGLRaw and gl I didn't
notice earlier.

Cheers,
   S.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/hopengl/attachments/20160110/9dd49831/attachment.html>

From svenpanne at gmail.com  Mon Jan 11 09:42:40 2016
From: svenpanne at gmail.com (Sven Panne)
Date: Mon, 11 Jan 2016 10:42:40 +0100
Subject: [HOpenGL] [Haskell-cafe] Merging the OpenGLRaw and gl packages
In-Reply-To: <CAGRp5Rm003Qxqgdnm=_HZf_eM2j=8ZVNHqT=DL3JQhHeqF1vHw@mail.gmail.com>
References: <CANBN=msHkd14O2PAsCGoXE=SAWhe8Zzisho3FeiC1P6Y7OFJ-w@mail.gmail.com>
 <CANBN=msTe-=fB6p89-4+iBQ3vj_8GY-o-j1Ee9iH2-DGTc_itg@mail.gmail.com>
 <CAJ5riwL1xJeTaxueoV6bbH+t6fY04B2kPFyzbUG4c3iLApzrAA@mail.gmail.com>
 <CANBN=mt-tWyE=t1gJ9_G2sZZH9KSJ58hRTeJpgW5knDFMLCsJg@mail.gmail.com>
 <CAGRp5RmoNM7NR8sGoRBtpWJNdb1c8m0TfixkvyVA-sYPo4x8Lw@mail.gmail.com>
 <CANBN=mtnUgU-Kdec54mC02=UBBsgh_si+3mSMUVfZpGhGy70kA@mail.gmail.com>
 <CANBN=msyFBRviiLZOqg1ETgwn53G8gWYasSOPKM2Wafup-nQHA@mail.gmail.com>
 <CANBN=mukYRbog07VR3Tt56rg5kdfw3HK5uQVEDXfPDYZc9=5KQ@mail.gmail.com>
 <CAGRp5Rm003Qxqgdnm=_HZf_eM2j=8ZVNHqT=DL3JQhHeqF1vHw@mail.gmail.com>
Message-ID: <CANBN=mschZ5UAxpX7YK9VDrKswwU68rMJqrWj2rC+PP=Z02eHw@mail.gmail.com>

2016-01-10 21:56 GMT+01:00 Oliver Charles <ollie at ocharles.org.uk>:

> I'm not really convinced by this. This change introduced an inconsistency
> and duplication, but doesn't really solve the problem. I already found
> another enum that has this problem (GL_LINEAR), and I hardly suggest
> introducing GL_LINEAR to work around that.
>
GL_LINEAR as a parameter is sometimes used as a GLenum (see e.g.
glBlitFramebuffer) and sometimes as a GLint (see
e.g. glGetTextureParameteriv), and there is no clear winner.


> While I agree that OpenGL is barely typed *statically*, there is a lot of
> runtime type checking. In practice o always develop with KHR debug as an
> extension or replay via apitrace, and this always checks ebum values for
> validity.
>
Yes, using a debug context + glEnable(GL_DEBUG_OUTPUT_SYNCHRONOUS)
+ glDebugMessageCallback during development is always a good idea. Apart
from the stateful nature of the API ("this and that is only allowed when we
are in state foobar etc."), the whole notion of profiles and extensions
makes it fundamentally impossible to have a 100% type-safe API. You can't
even e.g. statically tell which set of enums is allowed as a parameter for
a given function.

> I think OpenGLRaw would be more practical with gl-style polymorphic
> patterns
>
As I said in my previous email: Whenever you use the OpenGL API directly
(be it via OpenGLRaw or gl), you *will* have lots of 'fromIntegral's, and
the patterns don't make much of a difference. A quick grep showed that your
SSAO-example project has 33 fromIntegral calls, and only 2 are caused by
the patterns being monomorphic. The luminance package is even more extreme
in this respect: It contains 188 fromIntegral calls, and only 2 are caused
by the monomorphic patterns. (I may be off by small amount, but that
doesn't really change the fact.) So in a nutshell: This is a non-issue in
practice and mostly a bikeshedding discussion, and I won't change that
aspect of the binding.

Cheers,
   S.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/hopengl/attachments/20160111/04b0f0f2/attachment.html>