http://permalink.gmane.org/gmane.comp.lang.haskell.hopengl hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.lang.haskell.hopengl/917 <pre>Aprovados relação publicada Anadia: Pontal do Araguaia: ALESSANDRA DE SIQUEIRA ALVES, KELVIA MAYARA CISNE DOS SANTOS, FELIPE CUNHA FALCAO, NAJELA MARIA GOMES DE MATTOS COELHO ALENCAR, JOÃO CARLOS MOREIRA DE CARVALHO, CICERO ROBERT BEZERRA ANASTACIO, MARCOS BARROS REIS, IRENE COSTA OLIVEIRA BEZERRA. ROSIMERI CORDEIRO DOS SANTOS, EDVANIA DE JESUS GOMES, MARTHEUS CARLOS DE FREITAS, JOSE MACIANO ALEXANDRINO SILVA, VANESSA GADELHA DOS SANTOS. Igarapé Grande. Anadia, ANA LÚCIA MENDES DOS SANTOS, LUANA FELIX BIE, FRANCISCO PAULO DE OLIVEIRA MESQUITA, POLLIANA BRASILIANA DE SIQUEIRA, JOÃO CARLOS MOREIRA DE CARVALHO, DANIELE SILVA OLIVEIRA, MARIA JOSÉ BATISTA LEITE, JÉSSICA MAYARA P. PAULINO. SOLANGE FERREIRA ANDRADE, BRENA RODRIGUES MACIEL, LUIS FABRICIO DE FREITAS SOUZA, HÉLIO BARROS FERREIRA, RENATO CEZAR FARIAS TORRES. Buenópolis. Muniz Ferreira e ANAHISA PEDROSA VITALINO, LUCAS BEZERRA DE MESQUITA, GABRIELLE DE MOURA FERREIRA, RACHEL CABRAL MOTA, JOÃO CARLOS MOREIRA DE CARVALHO, DEBORA BEZERRA DE </pre> Edson 2013-05-29T07:03:06 http://permalink.gmane.org/gmane.comp.lang.haskell.hopengl/916 <pre> Thank you for the details. I'm going to give OpenGLRaw and the generator a try and see how far I can get without having to write a new raw library. </pre> Peter Jones 2013-04-23T01:54:59 http://permalink.gmane.org/gmane.comp.lang.haskell.hopengl/915 <pre> tl;dr: I think/hope that if OpenGLRaw works (or can be made to work) on the target platform there should not be any fundamental problems. I think it is worth making a difference here between HOpenGL and OpenGLRaw. OpenGLRaw is effectively a listing of enumeration values and functions from OpenGL. While HOpenGL is just a wrapper around OpenGLRaw. Both of these could be 'incompatible' with you use. At the moment I can think of three points which could cause trouble. The first problem is that the current interfacing with the lower C libraries might not be correct on your target platform. To use an OpenGL function you need to query a function pointer to it. This is handled by OpenGLRaw (see [1] for the implementation). The possible problem might be that this low level C-stuff cannot be extended to OpenGL ES. This could be the most fundamental problem or no problem at all, as I don't know much about the low level C-stuff, I can not tell. Though I'm hopeful as, according to wikipedia, OpenGL ES applications s</pre> L Corbijn 2013-04-17T11:14:21 http://permalink.gmane.org/gmane.comp.lang.haskell.hopengl/914 <pre>I'm new to both Haskell and OpenGL so please forgive my ignorance and feel free to correct any mistakes. GHC cross-compiling to ARM (at least for iOS and maybe Android) is currently being merged into mainline, making Haskell an attractive language for desktop *and* mobile development. This is still pretty bleeding edge but, at least to me, very exciting. I'm in the planning stages for a couple of applications that will have a graphical game-like component to them. I'd like to use Haskell and I've also decided that since I need to support mobile devices the most platform agnostic graphics library I can probably get away with is OpenGL ES 2.0. Since OpenGL ES 2.0 is based on OpenGL 2.0 with some modifications and a proper subset of OpenGL 4.1 with the GL_ARB_ES2_compatibility extension, I'm wondering if the current OpenGL package will work if I restrict myself to the ES defined functions. My research suggests that it won't work because there are subtle differences between some of the function names and o</pre> Peter Jones 2013-04-16T21:20:48 http://permalink.gmane.org/gmane.comp.lang.haskell.hopengl/913 <pre>I realize this change may be frustrating for some users. I'm sorry about the inconveniences that it may cause. The positive side is that the Haskell Platform will be able to upgrade to the latest OpenGL bindings. I think that makes this disruption worth it. Then new versions are not yet on hackage, but I'll probably upload them today. How this will affect you: I moved StateVar, ObjectName, and Tensor back into the OpenGL package (and renamed their modules from Data.* to Graphics.Rendering.OpenGL.GL.*). This also required a change in the GLUT package. I bumped the version number of OpenGL to 2.8.* and GLUT to 2.4.*. The StateVar, Tensor, and ObjectName packages are still on hackage exactly as they were. So if you're using those they will continue to work except that GHC will see them as incompatible with the ones exported from Graphics.Rendering.OpenGL. If this is a problem then I can upload versions of those packages that are re-exports from OpenGL. The reason I haven't don that is because then those pack</pre> Jason Dagit 2013-03-17T23:48:26 http://permalink.gmane.org/gmane.comp.lang.haskell.hopengl/912 <pre>No, there is no such plan to replace the OpenGL types by the vect types. However, with vect, you don't really have to use the OpenGL types at all, at least in normal circumstances. Yes, AC-Vector is similar, but vect is older, more mature, and has *much* more functionality. hmatrix is a very different library: It is intended for large-scale linear algebra (based on the scientific libraries BLAS, LAPACK, GSL). vect (and AC-Vector) is intended specifically for low-dimensional (up to 4 dimensions) linear algebra (and vect is tailored specifically for graphics). vect is also completely standalone (no dependencies), as opposed to hmatrix. Balazs On Sun, Mar 3, 2013 at 6:10 PM, MIMUW &lt;mgajda&lt; at &gt;mimuw.edu.pl&gt; wrote: _______________________________________________ HOpenGL mailing list HOpenGL&lt; at &gt;haskell.org http://www.haskell.org/mailman/listinfo/hopengl </pre> Balazs Komuves 2013-03-03T17:58:42 http://permalink.gmane.org/gmane.comp.lang.haskell.hopengl/911 <pre>Hi Balazs, That sounds nice, but is there any timeline for replacing types used by current version of OpenGL by those in vect? Since as far as I understand, vect-opengl gives just typecasts, and thus doesn't really address a problem of using many different Vector/Vertex types in place of one, and requiring typecasts. Thus we have AC-Vector that serves similar purpose as vect (and probably few more similar packages, like hmatrix.) &gt; the vect library: http://hackage.haskell.org/package/vect &gt; and its OpenGLl companion: http://hackage.haskell.org/package/vect-opengl &gt; &gt; were written specifically for doing computer graphics. It probably contains &gt; all vector/matrix operations you need. If this is not the case, I'm happy &gt; to hear suggestions. &gt; &gt; I don't think there is a better alternative at the moment (definitely &gt; nothing close in coverage of functionality). &gt; (disclaimer: I'm the author of these) &gt; &gt; Historical note: The Tensor package was born because the original author of &gt; the OpenGL </pre> MIMUW 2013-03-03T17:10:22 http://permalink.gmane.org/gmane.comp.lang.haskell.hopengl/910 <pre>Hi, the vect library: http://hackage.haskell.org/package/vect and its OpenGLl companion: http://hackage.haskell.org/package/vect-opengl were written specifically for doing computer graphics. It probably contains all vector/matrix operations you need. If this is not the case, I'm happy to hear suggestions. I don't think there is a better alternative at the moment (definitely nothing close in coverage of functionality). (disclaimer: I'm the author of these) Historical note: The Tensor package was born because the original author of the OpenGL package felt that it makes sense to make it separate from the big OpenGL package. He planned a serious refactoring/rewrite of the OpenGL package. However, he seems to have disappeared since. Balazs On Sun, Mar 3, 2013 at 2:26 PM, Michal J Gajda &lt;mgajda&lt; at &gt;mimuw.edu.pl&gt; wrote: _______________________________________________ HOpenGL mailing list HOpenGL&lt; at &gt;haskell.org http://www.haskell.org/mailman/listinfo/hopengl </pre> Balazs Komuves 2013-03-03T16:13:33 http://permalink.gmane.org/gmane.comp.lang.haskell.hopengl/909 <pre>Dear All, I see that Tensor library is used in OpenGL, OpenVG and few other libraries. Is there any plan to make vector operations available? [E.g. dot and cross product, vector projection and rejection.] Would you accept a patch, or would you recommend making another library? (Say Tensor-Operations:Data.Tensor.Operations.) For now they are included in AC-Vector package that uses a different type, which leads to impedance mismatch and unnecessary copying. I already contacted the maintainer of AC-Vector package, but got no answer to this problem so far. </pre> Michal J Gajda 2013-03-03T13:26:57 http://permalink.gmane.org/gmane.comp.lang.haskell.hopengl/908 <pre>Thank you. The example you gave was very helpful in understanding the use of StateVars. On 2013-02-20 at 12:49, Claude Heiland-Allen &lt;claude&lt; at &gt;mathr.co.uk&gt; wrote: </pre> Daniel Bergey 2013-02-21T04:52:39 http://permalink.gmane.org/gmane.comp.lang.haskell.hopengl/907 <pre> Personally I tend to use OpenGLRaw package or OpenGLRaw21 package, as OpenGL package diverges from all the useful non-Haskell tutorials and documentation by a wide margin, and OpenGL package doesn't yet support such useful things as geometry shaders. Anyway, usage is mostly via the ObjectName/StateVar interface: </pre> Claude Heiland-Allen 2013-02-20T17:49:43 http://permalink.gmane.org/gmane.comp.lang.haskell.hopengl/906 <pre>What is the recommended way to create and use a Shader object? Graphics.Rendering.OpenGL.GL.Shaders.Shaders has a function createShader which looks good, but is not exported. Similar not-exported functions seem to exist for the Program type. If there's still work do be done on this part of the library, I can to test out some code and submit a pull request. Thanks, bergey </pre> Daniel Bergey 2013-02-20T17:26:31 http://permalink.gmane.org/gmane.comp.lang.haskell.hopengl/905 <pre>(sorry for the dupplicate, but I forgot to cc the list) The reason for still being at version 3.2 is the work needed to go further. Updating OpenGLRaw is a very tedious and error prone task as you have to lookup all the functions and enumeration values for each and every new extension. Updating OpenGL (which is somewhere around OpenGL 3.1) is also not the most interesting work (I've got experience in doing so), though still better work than updating OpenGLRaw. It mainly boils down to adding enumeration datatypes and functions that are already present in OpenGLRaw but now in the correct context, therefore it also includes digging through the OpenGL specification. As a possible solution to the first problem (updating OpenGLRaw) I've been developing a generator to do it for us. Though functioning it hasn't been put to use yet. I have thought about solving the second problem (updating OpenGL) by also generating it, yet this is far more difficult. Lars </pre> L Corbijn 2013-01-16T16:51:12 http://permalink.gmane.org/gmane.comp.lang.haskell.hopengl/904 <pre>I thought that newer versions were already spread out. Thanks for your answer, greatly appreciated. 2013/1/15 Myles C. Maxfield &lt;myles.maxfield&lt; at &gt;gmail.com&gt; _______________________________________________ HOpenGL mailing list HOpenGL&lt; at &gt;haskell.org http://www.haskell.org/mailman/listinfo/hopengl </pre> Thiago Negri 2013-01-16T10:16:30 http://permalink.gmane.org/gmane.comp.lang.haskell.hopengl/903 <pre>I'd say that OpenGL 3.2 is still the norm nowadays. Many graphics cards out there don't support OpenGL 4.x (meaning: no hardware support for tessellation). Mac OSX and Mesa both only support OpenGL 3.2. You can read the OpenGL 4.3 specifications "with changes marked" to see what's different between the various releases. If you just want a synopsis, check out Wikipedia at http://en.wikipedia.org/wiki/OpenGL#OpenGL_4.0 . --Myles On Tue, Jan 15, 2013 at 6:58 AM, Thiago Negri &lt;evohunz&lt; at &gt;gmail.com&gt; wrote: _______________________________________________ HOpenGL mailing list HOpenGL&lt; at &gt;haskell.org http://www.haskell.org/mailman/listinfo/hopengl </pre> Myles C. Maxfield 2013-01-15T18:36:27 http://permalink.gmane.org/gmane.comp.lang.haskell.hopengl/902 <pre>Hello. I'm quite new to OpenGL, so I don't know all features available. The description of the OpenGLRaw package says it's a binding for OpenGL 3.2. On the official site, the 3.2 specification version is from 2009. [1] Why the Haskell binding uses version 3.2? What OpenGL features I'm missing by using Haskell instead of C? Thanks. [1] http://www.opengl.org/registry/ _______________________________________________ HOpenGL mailing list HOpenGL&lt; at &gt;haskell.org http://www.haskell.org/mailman/listinfo/hopengl </pre> Thiago Negri 2013-01-15T14:58:28 http://permalink.gmane.org/gmane.comp.lang.haskell.hopengl/901 <pre>The updates include: * All of the newtypes in OpenGLRaw have been changed to type aliases (credit to Trevor Elliott and Mike Ledger) * OpenGLRaw's TypesInternal module has gone away * NVidia path rendering extensions have been added by "ozelis" on github This release changes OpenGLRaw to use type aliases instead of newtype wrappers for the GLfoo types, such as GLenum/GLfloat/GLdouble. Using newtypes had the following downsides: * The CPP macros to make these definitions are borrowed verbatim from GHC sources and required updates with new GHC releases in order to stay compatible. Although, it hasn't been a problem yet, it's conceivable this will conflict with supporting different versions of GHC at some point. * Optimization rules have to be written against these newtypes and forgetting them can lead to significant performance degradation or extra verbosity for people using the bindings. * You have to reach pretty deep into GHC to make it possible for the newtypes to work in the unboxed vectors </pre> Jason Dagit 2012-11-04T19:28:36 http://permalink.gmane.org/gmane.comp.lang.haskell.hopengl/900 <pre> Great. Good point. The easiest thing is to try removing it and see if anything requires it. We're using travis-ci to build all the OpenGL packages now which helps with this sort of testing. Thanks, Jason _______________________________________________ HOpenGL mailing list HOpenGL&lt; at &gt;haskell.org http://www.haskell.org/mailman/listinfo/hopengl </pre> Jason Dagit 2012-10-26T20:11:52 http://permalink.gmane.org/gmane.comp.lang.haskell.hopengl/899 <pre>I like this change. The issues you brought up have been relevant to me. A long while ago I had a severe performance bug because of coercions between GL float types and C float types that went away when I replaced them with unsafeCoercions. Glancing at the source for Raw, does this mean that include/CTypes.h is no longer required? On Fri, Oct 26, 2012 at 1:25 AM, Jason Dagit &lt;dagitj&lt; at &gt;gmail.com&gt; wrote: _______________________________________________ HOpenGL mailing list HOpenGL&lt; at &gt;haskell.org http://www.haskell.org/mailman/listinfo/hopengl </pre> Dan Haraj 2012-10-26T20:02:55 http://permalink.gmane.org/gmane.comp.lang.haskell.hopengl/898 <pre>Hello, At some point in the past, OpenGLRaw was converted to use newtype wrappers for the GLfoo types, such as GLenum. I think this makes a certain amount of sense. It's certainly makes type safety easier. There have also been significant downsides to this: * The CPP macros to make these definitions are borrowed verbatim from GHC sources and required updates with new GHC releases in order to stay compatible. Although, it hasn't been a problem yet, it's conceivable this will conflict with supporting different versions of GHC at some point. * Optimization rules have to be written against these newtypes and forgetting them can lead to significant performance degradation or extra verbosity for people using the bindings. * You have to reach pretty deep into GHC to make it possible for the newtypes to work in the unboxed vectors provided by the vector package. This is again, another missed opportunity for high performance code. If you look at the current HEAD of the master branch for the OpenGLRaw code o</pre> Jason Dagit 2012-10-26T05:25:07 http://permalink.gmane.org/gmane.comp.lang.haskell.hopengl/897 <pre> I don't see why it shouldn't be ready to release after updating the cabal file. StateVar is almost as small and simple abstraction as is possible (and should be) that it can't be not ready. About the namsepaces, I think the current place is the most sensible option for the moment. Data.IO.StateVar would be nice, but creating Data.IO just for StateVar is not to my liking. Lars </pre> L Corbijn 2012-09-26T15:14:24 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.lang.haskell.hopengl