- HOpenGL - Haskell.org

Re: [HOpenGL] [Haskell-cafe] Merging the OpenGLRaw and gl packages
by Sven Panne 11 Jan '16

11 Jan '16

2016-01-10 21:56 GMT+01:00 Oliver Charles <ollie(a)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.

1 0

Re: [HOpenGL] [Haskell-cafe] Merging the OpenGLRaw and gl packages
by Sven Panne 11 Jan '16

11 Jan '16

2015-10-01 11:01 GMT+02:00 Oliver Charles <ollie(a)ocharles.org.uk>: > [...] However, it's a lot more significant if you want to do something > like: > > foo x = doSomething (case x of ...) > > Without pattern synonyms, you either have > > foo x = doSomething x' > where x' | x == ... = ... > > or > > {-# LANGUAGE MultiWayIf #-} > > foo x = doSomething (if | x == ... -> ...) > Or simply in plain old Haskell (basically the desugaring of the multi-way-if): foo x = doSomething (case () of _ | x == gl_BAR -> expr1 | x == gl_BAZ -> expr2 | otherwise -> expr3) Compared to: foo x = doSomething (case x of GL_BAR -> expr1 GL_BAZ -> expr2 _ .> expr3) it doesn't really look *that* much different IMHO, given the high price one has to pay for a tiny improvement in readability. But that's my personal, more conservative view of things, and I'm here to see what other people prefer.Alas, up to now, this is not very conclusive... :-/

1 2

Regal and cross platform 3D
by Jelle Hermsen 10 Jan '16

10 Jan '16

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

2 1

Re: [HOpenGL] [Haskell-cafe] Merging the OpenGLRaw and gl packages
by Sven Panne 01 Oct '15

01 Oct '15

2015-09-30 17:02 GMT+02:00 Casey McCann <cam(a)uptoisomorphism.net>: > On Wed, Sep 30, 2015 at 10:29 AM, Sven Panne <svenpanne(a)gmail.com> wrote: > > * Should OpenGLRaw use pattern synonyms? (Probably yes, but note that > this > > implies GHC >= 7.8.1) > > > > * Should OpenGLRaw use the 'Half' type from the 'half' package? > (Probably > > yes, but again this implies GHC 7.8.1) > > 7.8.1 is, what, a year and a half old? > > I'm all for bleeding edge personally but not everyone feels that way, > and that seems pretty severe relative to the benefits. > That's my biggest concern, too, and that's why I wanted to hear other people's opinions: IMHO using pattern synonyms vs. plain old Haskell values is to a large part just bikeshedding, at least in the trivial case at hand where we talk about simple integral values. It basically boils down to the question: Is foo x = case x of GL_BAR -> expr1 GL_BAZ -> expr2 _ -> expr3 really so much better than foo x | x == GL_BAR = expr1 | x == GL_BAZ = expr2 | otherwise = expr3 that we want to drop support for GHC < 7.8.1? Personally, I'm not convinced, but if most other people think that it's OK, I'm willing to pay the price for the sake of merging the packages. Edward claims that using pattern synonyms will result in more efficient code, too, but I haven't checked that. And even if it was: Perhaps GHC can be tweaked to treat both versions above in the same way (I can see no reason why this shouldn't be possible, but perhaps I'm wrong). Regarding readability: The version with pattern synonyms *is* slightly more readable, but not so much that it would warrant dropping slightly outdated GHCs. Regarding the 'half' package: I've just seen that it should work with any GHC 7.x now, so this decision can be decoupled from the pattern synonym issue. Perhaps I should release a new, only slightly incompatible OpenGLRaw version using 'half'? Although GLhalf is part of OpenGL core since 3.0, it is only used in very few non-central places (GL_ARB_half_float_pixel, GL_ARB_half_float_vertex, and GL_NV_half_float). So the resulting breakage will probably be very low. Regarding the module prefix: I'm not sure if it's worth making this breaking change alone, probably this should only be done in conjunction with the introduction of pattern synonyms. But other opinions would be valuable here, too. [...] As an aside regarding the wiki discussion, I don't really see how > there's a sane way to have a combined low-level API for WebGL and full > OpenGL. [...] As already mentioned in more detail on the Wiki, the plan to combine OpenGL and WebGL in a single package is doomed: Different values for the same token, different contents of the extensions, different ways to retrieve the entry points. It's a pity, but that's how it is...

1 0

Re: [HOpenGL] Merging the OpenGLRaw and gl packages
by Sven Panne 30 Sep '15

30 Sep '15

After some discussions via email and via the Wiki ( https://github.com/haskell-opengl/OpenGLRaw/wiki/Merging-OpenGLRaw-and-gl) I've already made a few changes to OpenGLRaw, bringing it closer to 'gl'. These are fully backwards compatible, because they mainly consist of improvements in the generated documentation and the addition of various extension-related retrieval functions. Before I move on and introduce breaking changes, I'd like to hear some opinions about a few items which might need some more discussion: * Should OpenGLRaw use pattern synonyms? (Probably yes, but note that this implies GHC >= 7.8.1) * Should OpenGLRaw use the 'Half' type from the 'half' package? (Probably yes, but again this implies GHC 7.8.1) * Should the incredibly long 'Graphics.Rendering.OpenGL.Raw' module prefix be replaced by the more palatable 'Graphics.GL.Raw'? (Probably yes) More details and other already resolved and/or less controversial items can be found on the Wiki. The plan is to release a new OpenGLRaw version soon (3.0), after which Edward and Gabríel Arthúr can deprecate the 'gl' package (if they like).

1 0

Fwd: Merging the OpenGLRaw and gl packages
by Sven Panne 18 Sep '15

18 Sep '15

[ I forgot to add this mailing list in the initial mail... ] Edward and I already commented a bit on the Wiki, but I would really like to have some more input from users. Breaking an API shouldn't be done in a hurry and without feedback, so raise your voice! :-) ---------- Forwarded message ---------- From: Sven Panne <svenpanne(a)gmail.com> Date: 2015-09-13 22:13 GMT+02:00 Subject: Merging the OpenGLRaw and gl packages To: Haskell Cafe <haskell-cafe(a)haskell.org> Currently there are 2 similar packages on Hackage to access raw OpenGL functionality: OpenGLRaw and gl. Taking a closer look at them, it turns out that they are only superficially different and have a lot of things in common. This is a bit confusing for users, so it might make sense to merge those packages. Therefore I'd like to start a discussion how to do this in detail, collecting user feedback and opinions. I think that haskell-cafe is the right place for this discussion, while an accompanying wiki page is more suitable to collect the results. As a basis I started a page at https://github.com/haskell-opengl/OpenGLRaw/wiki/Merging-OpenGLRaw-and-gl, which is necessarily biased at the moment. ;-) It would be nice to hear your opinions about how the package should look like, what might be missing, what could be done better, which differences I forgot, etc. Cheers, S.

2 1

two bugs in ShaderObjects.hs
by Claude Heiland-Allen 20 Jan '15

20 Jan '15

Hi all, I don't have a github.com account, so reporting here. Hope that's ok. I found these bugs after Cale posted a link to some problematic behaviour (which probably failed initially due to lack of an OpenGL context): http://lpaste.net/118704 The first bug is lack of error checking in createShader: ---8<--- createShader :: ShaderType -> IO Shader createShader = fmap Shader . glCreateShader . marshalShaderType ---8<--- http://hackage.haskell.org/package/OpenGL-2.10.0.0/docs/src/Graphics-Render… glCreateShader returns 0 on error, and using that "not a shader" id for other calls is bound to cause chaos. https://www.opengl.org/sdk/docs/man/html/glCreateShader.xhtml The second bug is much more serious, a lack of error checking in shaderVar: ---8<--- shaderVar :: (GLint -> a) -> GetShaderPName -> Shader -> GettableStateVar a shaderVar f p shader = makeGettableStateVar $ alloca $ \buf -> do glGetShaderiv (shaderID shader) (marshalGetShaderPName p) buf peek1 f buf ---8<--- http://hackage.haskell.org/package/OpenGL-2.10.0.0/docs/src/Graphics-Render… glGetShaderiv doesn't modifiy the contents of buf on error. This means uninitialized memory is read by peek1 and then presumably used by f, which can cause a crash (in the best case) or wrong/undefined behaviour (in the worst case). https://www.opengl.org/sdk/docs/man/html/glGetShader.xhtml Thanks for reading, Claude -- http://mathr.co.uk

2 5

Re: [HOpenGL] 2D textures with OpenGL and GLUT
by Jason Dagit 09 Jul '14

09 Jul '14

On Wed, Jul 2, 2014 at 9:33 AM, Elise Huard <elise(a)jabberwocky.eu> wrote: > Hi Jason, > thanks for taking the time to answer. > So trying to read between the lines: > - do you have any _working_ examples of texture mapping with OpenGLRaw > and low-level Haskell I could have a look at? (anything would help at > this point) > I do. I converted some of the old nehe tutorials: https://github.com/dagit/nehe-tuts If you look through the history you can find examples that use a very very old version of OpenGL (instead of OpenGLRaw). The OpenGL style in those examples is old and no longer the recommended way. The examples use immediate mode which is now deprecated in favor of shaders. I think lesson 6 makes a cube and throws some textures on it. The lesson numbers are meant to match these: * http://nehe.gamedev.net/tutorial/lessons_01__05/22004/ * http://nehe.gamedev.net/tutorial/lessons_06__10/17010/ > - do you think the unsafeCoerce (which I borrowed from examples) that > transform CpFloat to GLdouble might be the issue, or is this just a > general stylistic comment? > Not just stylistic. As for correctness, I think the answer varies by platform. Specifically, I think CFloat is not required to match GLdouble in size (in fact, doubles should be expected to be twice as big). While both types should correspond to IEEE 754 floats the bit width is very likely different and that could easily cause the interpretation of the values to go wonky. Imagine passing 64bits when only the first 32bits correspond to a valid number or truncating a 64bit value to 32bits. Which examples use unsafeCoerce for this? I'm just sort of curious so I can recommend people not to use them :)

2 3

2D textures with OpenGL and GLUT
by Elise Huard 03 Jul '14

03 Jul '14

Hi, I've been trying to get a texture mapped onto a circle. I've pounded my head against this problem for a good while, been reading lots of posts about how to do it in C, reproduced those as much as possible, but the best I get is a fairly distorted texture (I'm working with a basic checkerboard as displayed in the Redbook4 examples of GLUT, just to make sure I've got it right before moving on to actual images). Code here: loading texture https://github.com/elisehuard/game-prototype/blob/master/src/Main.hs#L90 using the texture in a circle (mapping): https://github.com/elisehuard/game-prototype/blob/master/src/Main.hs#L130 the result is here https://github.com/elisehuard/game-prototype/blob/master/images/texture.jpg (as you can see, it is not a checkerboard) My aim is to make a 2D game to start with, so the perspective is orthogonal, I don't know if that helps. This may be due to my being a noob with things OpenGL - I hope anyone can help me solve this, textures are a pretty important part. Thank you,

2 2

NURBS surface with texture
by Rob Agar 26 Jun '14

26 Jun '14

Hi all Does the GLU.NURBS module support texture mapping? I'm playing around with code based on the sample at https://github.com/haskell-opengl/GLUT/blob/master/examples/RedBook4/Surfac… trying to draw a textured surface. As I understand it, I need to call nurbsSurface again to create a texture coordinate surface as well as the vertex one, but I can't see how to tell it which type to make. Or have I misunderstood the way NURBS surfaces are created? The docs at http://www.opengl.org/sdk/docs/man2/xhtml/gluNurbsSurface.xml are fairly sketchy :\ cheers Rob

1 0