- HOpenGL - Haskell.org

ANNOUNCE: New OpenGL packages
by Sven Panne 19 May '14

19 May '14

New versions of the OpenGL packages are available on Hackage: * OpenGLRaw 1.5.0.0 * GLURaw 1.4.0.1 * OpenGL 2.9.2.0 * GLUT 2.5.1.1 Cheers, S. ====================================================================== Changes in the OpenGLRaw package ====================================================================== * Don't rely on K&R features in CPP, making things easier for Mac/clang users. * Added support for OpenGL 3.2's glGetInteger64i_v and the following extensions, so now all parts of OpenGL 4.1 are supported (plus a few more): APPLE_flush_buffer_range APPLE_vertex_array_object ARB_blend_func_extended ARB_gpu_shader_fp64 ARB_sampler_objects ARB_shader_subroutine ARB_shading_language_include ARB_texture_compression_bptc ARB_texture_rgb10_a2ui ARB_texture_swizzle ARB_transform_feedback2 ARB_vertex_attrib_64bit ARB_vertex_type_2_10_10_10_rev EXT_draw_buffers2 EXT_framebuffer_blit EXT_framebuffer_multisample EXT_gpu_shader4 EXT_packed_stencil_depth EXT_texture_array EXT_texture_compression_rgtc EXT_texture_shared_exponent EXT_transform_feedback * Made naming more consistent: Abgr => ABGR Bgra => BGRA Cmyka => CMYKA Dxt1 => DXT1 Fp => FP Gpu => GPU Latc => LATC Lod => LOD S3tc => S3TC Vtc => VTC ====================================================================== Changes in the GLURaw package ====================================================================== * Don't rely on K&R features in CPP, making things easier for Mac/clang users. ====================================================================== OpenGL 2.9.2.0 ====================================================================== * Added generateMipmap’, a modern version of the deprecated generateMipmap. * Added a few missing IndexedBufferTargets. * indexedBufferSize and indexedBufferStart correctly use 64bit queries now. * Setting bindBufferRange handles Nothing correctly now. * Added missing Eq/Ord/Show instances for a few data types. ====================================================================== Changes in the GLUT package ====================================================================== * Don't rely on K&R features in CPP, making things easier for Mac/clang users. * Added ColorTriange example.

1 0

ANNOUNCE: GLUT 2.5.1.0
by Sven Panne 29 Jan '14

29 Jan '14

A new version of the GLUT package is available on Hackage, with the following new features: * Added support for left/right SHIFT/CTRL/ALT special keys. * Added skipStaleMotionEvents state flag, making it possible to skip all but the last motion event. * Added leaveFullScreen call. * Added support for position, application life cycle and multi-touch window callbacks. * Various object drawing improvements: * Added teacup and teaspoon objects, so we support the full Newell tea set now. * Added geometryVisualizeNormals state flag. * Added support for drawing objects via VBOs: vertexAttribCoord3, vertexAttribNormal, and vertexAttribTexCoord2. * Added support for menu fonts via new constructor MenuWithFont. Apart from glutInitErrorFunc and glutInitWarningFunc, which are not extremely useful IMHO, all freeglut features are now exposed on the Haskell side. Cheers, S.

1 0

Lista de emails list mail listas de emails gratis
by Ed Soares 23 Nov '13

23 Nov '13

Lista de emails list mail listas de emails gratis listas email também contendo lista de emails, mala direta em casa lista de emails: http://www.maladiretaemails.com normalmente é email lista gratis, pode ser bastante bom para todos. cadastro email endereco de email que contenham lista de emails, lista de email servidor de email, é realmente a função do nosso website. Se você gostaria de enderecos de email, mala direta em casa bem como servidor de email: http://www.maladiretaemails.com pode ser ótimo listagem de empresas também lista com emails, cadastro email lista de empresas. é excelente email mailing juntamente com o que é e-mail marketing. emails empresas trabalho com mala direta, listas de email. nos dias de hoje lista de mail tais como Enviar email, lista email é benéfico. a intenção de nosso website: mala direta em casa, Enviar email, assim como listagem de empresas. Temos agora lista de mail listagem de empresas, emails empresas.

1 0

Fwd: ANNOUNCE: New OpenGL packages
by Sven Panne 16 Sep '13

16 Sep '13

[Forgot to cross-post...] ---------- Forwarded message ---------- From: Sven Panne <svenpanne(a)gmail.com> Date: 2013/9/15 Subject: ANNOUNCE: New OpenGL packages To: haskell-cafe(a)haskell.org New versions of the OpenGL packages are available on Hackage: * OpenGLRaw 1.4.0.0 * GLURaw 1.4.0.0 * OpenGL 2.9.0.0 * GLUT 2.5.0.0 The mid-term goal is to make all these packages conform to the latest OpenGL 4.4 specification, and while we're not yet there, this release is nevertheless an important stepping stone towards that goal. The packages contain a few non-backwards compatible changes, something which is never nice for a public API, but it has been necessary: OpenGL has come a long way from its initial fixed function pipeline to its current form flexible form centered around shaders and buffers. Because of this, a few design decisions on the Haskell side were not a good fit anymore and simply had to change. Nevertheless, almost all changes needed in the applications and libraries using the OpenGL packages should be mechanical and straightforward. If not: hopengl(a)haskell.org is the place to get help if needed. Hopefully the new packages will make it into the next Haskell Platform release (2013.4.0.0), at least if I find out how to make it through the proposal process... ;-) Cheers, S. P.S.: Here a list of the changes for each package: ====================================================================== Changes in the OpenGLRaw package ====================================================================== * Added support for the following extensions: GL_ARB_occlusion_query2 GL_ARB_timer_query GL_ARB_draw_indirect GL_ARB_gpu_shader5 GL_ARB_tesselllation_shader GL_ARB_transform_feedback3 GL_ARB_ES2_compatibility GL_ARB_get_program_binary GL_ARB_separate_shader_objects GL_ARB_shader_atomic_counters GL_ARB_compute_shader GL_ARB_ES3_compatibility GL_ARB_framebuffer_no_attachments GL_ARB_shader_storage_buffer_object GL_ARB_query_buffer_object * Added GLfixed type from OpenGL 4.1. * Moved GLhandle type to Graphics.Rendering.OpenGL.Raw.ARB.ShaderObjects where it belongs and fixed its representation on Mac OS X. * Added new Graphics.Rendering.OpenGL.Raw.Type module which exports all GL types. Core31 and Core32 export only their respective subset now. * Correctly typed bitfield tokens as, well, GLbitfield instead of GLenum. * Consistently use ‘Ptr a’ for ‘void*’ which are not opaque. * Use ccall instead of stdcall on x86_64-windows. * Use the OpenGLES framework on iOS. ====================================================================== Changes in the GLURaw package ====================================================================== * Use ccall instead of stdcall on x86_64-windows. * Use the OpenGLES framework on iOS. ====================================================================== Changes in the OpenGL package ====================================================================== * Added sync object support. * Added full support for OpenGL 4.4 query objects, extending and changing the previous query object API a bit. * Split ObjectName class into ObjectName + GeneratableObjectName classes. Added single-name variants deleteObjectName and genObjectName, they are a very common use case. * Made BufferObject and TextureObject abstract. Now all GL objects names are abstract and have to be explicitly generated. The only exception is DisplayList, which is required to be non-abstract by the spec. * Shader is not a class anymore, but a data type with an ObjectName instance and a creation action. Added ShaderType and shaderType. * Added partial support for tessellation/geometry/compute shaders. * Program is not a GeneratableObjectName, but has a createProgram action now. Added attachShader and detachShader for incremental changes. * Deprecated shaderSource and added shaderSourceBS instead. Using ByteString is more efficient and forces the caller to think about encodings, e.g. via Data.Text.Encoding. * Added support for shader/program binaries and shader precision queries. * Revamped texture targets, adding partial support for texture buffer objects and texture arrays. * OpenGL 3.1 deprecated separate polygon draw modes, so use GL_FRONT_AND_BACK internally in polygonMode whenever possible. * Added missing Eq/Ord/Show instances for lots of data types. * Simplified TransformFeedbackVaryings API, making it a bit more similar to the one for activeAttribs and activeUniforms. * Exported ContextProfile’. * Renamed BlitFramebufferMask (to BlitBuffer) and its constructors. * Renamed BufferRangeAccessBit (to MapBufferUsage) and its constructors * Removed currentMatrix, genLists, deleteLists and isList, they have been deprecated for ages. * Full internal support for UTF-8. * Do not expose internal #hidden modules. * Lots of Haddock fixes and improvements. * Renamed IndexedTransformFeedbackBuffer to IndexedTransformFeedbackBuffer. * Fixed clip plane query. ====================================================================== Changes in the GLUT package ====================================================================== * Deprecated the misspelled ContinueExectuion constructor and added a new one correctly called ContinueExecution instead. * Use ccall instead of stdcall on x86_64-windows. * Do not expose internal #hidden modules.

1 0

Upcoming releases
by Sven Panne 13 Sep '13

13 Sep '13

I've just tagged new releases for the OpenGLRaw/GLURaw/OpenGL/GLUT packages on GitHub. It would be nice if people on this list give them a try to iron out small bugs before I "officially" announce them on haskell-cafe. The goal is to have these package versions in the upcoming Haskell Platform release, and the package proposal deadline for this is not that far away. I know we are still quite a bit away from full OpenGL 4.4 support, but there are already enough changes that makes it worthwhile to push out the new stuff. ChangeLog: https://docs.google.com/document/d/1GVxpMyfbFwmi37dGgwMlXk5H1GVxhEwuQoXA9ZT… Cheers, S.

1 0

Haddock documentation on Travis CI
by Sven Panne 25 Aug '13

25 Aug '13

I'd like to build/test the Haddock documentation for the OpenGL packages on Travis CI a bit more, so I've tweaked the configuration a bit by building the Haddock documentation for the dependencies first. One problem remains: There seems to be no installed Haddock documentation for the Haskell platform itself on Travis CI, so we get tons of warnings, e.g. here: https://travis-ci.org/haskell-opengl/GLUT Does anybody have a clue how to fix this (probably via some apt-get magic in the before-install section)? Cheers, S.

2 2

Shader API changes
by Sven Panne 16 Aug '13

16 Aug '13

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/…) 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.

3 3

Fwd: Shader API changes
by Sven Panne 12 Aug '13

12 Aug '13

[ Wrong kind of reply... :-P ] ---------- Forwarded message ---------- From: Sven Panne <svenpanne(a)gmail.com> Date: 2013/8/12 Subject: Re: [HOpenGL] Shader API changes To: L Corbijn <aspergesoepje(a)gmail.com> 2013/8/11 L Corbijn <aspergesoepje(a)gmail.com>: > 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. [...] All shaders share the same name space, so there is no problem regarding OpenGL semantics. The last point regarding ObjectName is the real problem, and it needs some thought to resolve it nicely. As a first brainstorming step let's look at all OpenGL objects and their related lifetime API (see section 2.5, "Objects and the Object Model"): ---------------------------------------------------------------------- * Buffer Objects void GenBuffers( sizei n, uint *buffers ); void DeleteBuffers( sizei n, const uint *buffers ); boolean IsBuffer( uint buffer ); * Shader Objects uint CreateShader( enum type ); void DeleteShader( uint shader ); boolean IsShader( uint shader ); * Program Objects uint CreateProgram( void ); void DeleteProgram( uint program ); boolean IsProgram( uint program ); * Program Pipeline Objects void GenProgramPipelines( sizei n, uint *pipelines ); void DeleteProgramPipelines( sizei n, const uint *pipelines ); boolean IsProgramPipeline( uint pipeline ); * Texture Objects void GenTextures( sizei n, uint *textures ); void DeleteTextures( sizei n, const uint *textures ); boolean IsTexture( uint texture ); * Sampler Objects void GenSamplers( sizei count, uint *samplers ); void DeleteSamplers( sizei count, const uint *samplers ); boolean IsSampler( uint sampler ); * Renderbuffer Objects void GenRenderbuffers( sizei n, uint *renderbuffers ); void DeleteRenderbuffers( sizei n, const uint *renderbuffers ); boolean IsRenderbuffer( uint renderbuffer ); * Framebuffer Objects void GenFramebuffers( sizei n, uint *framebuffers ); void DeleteFramebuffers( sizei n, const uint *framebuffers ); boolean IsFramebuffer( uint framebuffer ); * Vertex Array Objects void GenVertexArrays( sizei n, uint *arrays ); void DeleteVertexArrays( sizei n, const uint *arrays ); boolean IsVertexArray( uint array ); * Transform Feedback Objects void GenTransformFeedbacks( sizei n, uint *ids ); void DeleteTransformFeedbacks( sizei n, const uint *ids ); boolean IsTransformFeedback( uint id ); * Query Objects void GenQueries( sizei n, uint *ids ); void DeleteQueries( sizei n, const uint *ids ); boolean IsQuery( uint id ); * Sync Objects sync FenceSync( enum condition, bitfield flags ); void DeleteSync( sync sync ); boolean IsSync( sync sync ); * Display Lists uint GenLists( sizei s ); void DeleteLists( uint list, sizei range ); boolean IsList( uint list ); ---------------------------------------------------------------------- Looking at this, the following kind of objects are a perfect fit for the current ObjectName class: * Buffer Objects * Program Pipeline Objects * Texture Objects * Sampler Objects * Renderbuffer Objects * Framebuffer Objects * Vertex Array Objects * Transform Feedback Objects * Query Objects The following two object kinds fit, although not 100% perfectly, but this can easily be handled e.g. via comments and exporting a constructor: * Program Objects: CreateProgram directly creates a name *and* the object. * Display Lists: List names don't have to be generated via GenLists, and GenLists itself is guaranteed to return a consecutive range of names. The following two object kinds are the tricky ones: * Shader Objects: Just like program objects, their name and the associated object are created simultaneously. Furthermore, creation needs a parameter (the shader type). * Sync Objects: The same problems as for shader objects (direct creation + arguments for creation), in addition the object identifier is an opaque pointer (GLsync) instead of a GLuint, but the latter fact can be hidden. Any suggestions regarding how to reflect this on the Haskell side? It would be nice to keep ObjectName, perhaps with some modifications and/or additions like e.g. another type class. There are probably several ways of doing this, I would really like to get some ideas and feedback before I rush into changing things.

1 1

Back again
by Sven Panne 12 Aug '13

12 Aug '13

After a few HOpenGL-free years caused by personal and job-related circumstances, I'd like to work on this again. First of thanks to all the people involved in keeping the binding alive, especially Jason! Having the packages in the Haskell platform is simply great, because it improves the visibility of the binding a lot and will keep new users (and new bug reports ;-) coming. I've browsed through the mailing list archives, so here are a few miscellaneous remarks: * The StateVar/Tensor/ObjectName packages are now in the OpenGL package itself (in a different namespace), and the previous standalone packages are still available, too. Although I don't think it is a perfect solution, it was probably done to get the OpenGL packages into the Haskell platform, right? If this was the motivation, I think the price to pay was well worth it. The OpenAL/ALUT packages use the assimilated packages, too, so I should probably update the former ones to use the latter ones. This will introduce a dependency of OpenAL/ALUT on OpenGL, something I wanted to avoid. But I think there are very few programs using OpenAL without OpenGL, and the latter is now universally available via the Haskell platformm, so this should be the right way to proceed. * What was the exact motivation for using type synonyms instead of the former renamings (newtypes) for the OpenGL types? Were there any *real* problems or only potential/hypothetical ones? I am a bit torn between those alternatives, so I'd like to learn the experience of other people, including their opinions. * The examples have bit-rotted, e.g. SmoothOpenGL3.hs yields an InvalidOperation in triangle's vertexAttribPointer calls, 'catch' should probably be replaced by Control.Exception.{catch,IOException}, etc. Apart from fixing them, having GLUT versions of nehe-tuts in the GLUT package would be great. I really like the idea of GLUT being a one-stop-shop for tons of examples regarding the usage of the OpenGL/OpenGLRaw packages. * Currently the binding doesn't work out-of-the box with ghci on Ubuntu 12.04 if you have NVIDIA drivers installed in addition to the Mesa ones. I have an ugly fix (adding /usr/lib/nvidia/current to OpenGLRaw's library-dirs), but I'd like to solve this more cleanly. More about this in a separate mail. * Finally Khronos has released the OpenGL registry in a less braindead format (http://www.opengl.org/discussion_boards/showthread.php/181927-New-XML-based…) so there is a good chance now that the OpenGLRaw package can be completely autogenerated, something I wanted to do for ages. Judging from the HOpenGL mailing list, Lars is already looking into it, so let's coordinate our efforts here, preferably in a separate mail thread. My main concerns here are: Include the generator (plus pre-generated bindings) in the OpenGLRaw package, it really belongs there. Don't put anything clever into OpenGLRaw, it should really, really be a plain, straightforward 1:1 mapping of the registry. No name mangling, structural modifications etc. apart from things automatically derivable from the XML registry. A big question remains: Can we generate the (un-)marshaling functions already in OpenGLRaw? The XML registry has <groups>/<group> tags, but I fear that they are still too incomplete/incorrect to be of any use for the Haskell binding. On the positive side, I think that it should be possible to upstream changes to the registry to make it more useful in general. I had contact with Jon Leech in the past, and he has always been very open and helpful. * Given the fact that OpenGL 4.3 is quite different from OpenGL in the "old days", there are quite a few design decisions in the OpenGL (convenience) package that I would do differently nowadays. But I think with the feedback from the community we can gradually tweak this layer to something more useful and up-to-date. Perhaps we can somehow re-arrange things to be more in line with OpenGL versions/profiles, but whatever we do, we should not drop support for "old skool" OpenGL, there are *tons* of tutorials, books and courses relying on it, and even NVIDIA has effectively promised to support this forever. Cheers, S.

6 8

Ancient glut32.dll bundled with the Haskell platform
by Sven Panne 26 Jul '13

26 Jul '13

If I see things correctly, https://github.com/23Skidoo/haskell-platform-windows/tree/master/etc contains the glut32.dll which is installed via the Haskell platform installer when no other GLUT DLL can be found. The problem is that this DLL seems to contain an ancient GLUT version from 2001, which misses a lot of new features: glutBitmapHeight glutBitmapString glutCloseFunc glutExit glutFullScreenToggle glutGetMenuData glutGetModeValues glutGetProcAddress glutGetWindowData glutInitContextFlags glutInitContextProfile glutInitContextVersion glutInitErrorFunc glutInitWarningFunc glutLeaveFullScreen glutLeaveMainLoop glutMainLoopEvent glutMenuDestroyFunc glutMouseWheelFunc glutMultiButtonFunc glutMultiEntryFunc glutMultiMotionFunc glutMultiPassiveFunc glutSetMenuData glutSetOption glutSetWindowData glutSolidCylinder glutSolidRhombicDodecahedron glutSolidSierpinskiSponge glutStrokeHeight glutStrokeString glutWMCloseFunc glutWireCylinder glutWireRhombicDodecahedron glutWireSierpinskiSponge As one can see, a few really crucial features are missing, like the ability to cleanly exit the GLUT main loop, and much more importantly: The ability to create specific OpenGL contexts via glutInitContext*. The latter is extensively used in e.g. the current Red Book. A better DLL is e.g. in the MSVC package in http://www.transmissionzero.co.uk/software/freeglut-devel/ (linked from the freeglut SF page). So my question is: How/where should a bug report be submitted? As it is, the bundled glut32.dll is almost useless for modern OpenGL. :-( Cheers, S.

1 0