- HOpenGL - Haskell.org

How to send matrices to GLSL uniform variables
by 梶本裕介 12 Sep '12

12 Sep '12

Hi everyone, In OpenGL 3.2, there is no fixed pipeline functionalities. So I would like to send my model-view-projection matrix to GLSL through an uniform variable. But I seem that there is no glUniformMatrix* family in HOpenGL. (http://hackage.haskell.org/packages/archive/OpenGL/2.5.0.0/doc/html/Graphic…) How can I achieve this?

5 5

Raw generator and performance
by Fabian Binz 24 Aug '12

24 Aug '12

Hi list, I have two questions: 1. What is holding the release of OpenGLRawGen (see [1]) back? I tried it and it works quite well, although there seems to be a problem with at least some functions: glGenVertexArrays and the related functions are not exported by any core module, although it's part of the core since OpenGL 3.0. I tried to find the source of this error in the code, but the codebase is quite big and I still don't know where things go wrong. 2. Looking at the source of HSOpenGLRaw.c it seems to be quite costly to call OpenGL functions, because every time the function pointer has to be retrieved. Or does GetProcAdress (or the equivalent on Mac and Linux) cache previous results? Other librarys (like GLEW or gl3w for C) load the functions pointers once at initialization (which has of course to be done explicitly unlike in HOpenGL), which I guess is for efficiency reasons. [1] http://www.haskell.org/pipermail/hopengl/2012-January/001073.html

2 1

Problem with Glut
by ai00rea 20 May '12

20 May '12

I have to make a project for university. I want to make a little game like Pong. For this I decided to use Glut. I followed this tutorial but I didn't succeed: http://netsuperbrain.com/blog/posts/freeglut-windows-hopengl-hglut/ I am using Windows 7. Now I removed all things I installed from my computer about haskell & openGL & GLUT. And I installed Haskell Platform. I found out that openGL and GLUT are included in this platform. OK but there is one problem: GHCi, version 7.0.4: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package ffi-1.0 ... linking ... done. [1 of 1] Compiling Main ( C:\Users\fuRy\Desktop\openGL\teapots.hs, i nterpreted ) Ok, modules loaded: Main. *Main> main Loading package OpenGL-2.2.3.0 ... linking ... done. Loading package array-0.3.0.2 ... linking ... done. Loading package containers-0.4.0.0 ... linking ... done. Loading package GLUT-2.1.2.1 ... <interactive>: glut32: The specified module cou ld not be found. can't load .so/.DLL for: glut32 (addDLL: could not load DLL) Please help me. I tried 2 days to install this. Before that I tried to instal WXHaskell too, and i failed. Or recomand me an library that you use and there are some examples of code to figure out how to use it and is good for my purpose: Pong. -- View this message in context: http://haskell.1045720.n5.nabble.com/Problem-with-Glut-tp5689667.html Sent from the Haskell - HOpenGL mailing list archive at Nabble.com.

4 7

Getting into the Haskell Platform
by Jason Dagit 13 Feb '12

13 Feb '12

I wrote the following email to the Haskell Platform list asking for guidance getting the latest versions of OpenGL back into the platform (they currently only have an old version): http://projects.haskell.org/pipermail/haskell-platform/2012-January/001738.… It's unfortunate that no one has responded there. It's something I'd like to move forward on. Do people here have opinions about the suggestions I made in that email? Thanks, Jason

2 1

Raw generator
by L Corbijn 24 Jan '12

24 Jan '12

Hi, The raw generator is quite complete. As far as I can see it does work, and has the option for a compatibility layer for the old core and produces the correct code (although that's hard to verify with 300+ modules ;) ). In addition I don't see many points of improvement to the output nor the internal structure. Therefore I would like to know if the generated code and program is correct/good/according to specification i.e. should it be changed? Because (as said) as far as I can see it is all working. For those of you who like to build it, the instructions are at the end. If people would prefer an archive above the hassle of generating it themselves please let me know. Lars * Build instructions * The non hackage dependencies are: opengl-api [1] includes some modifications on noteeds (thank you) package for parsing the spec files. CodeGenerating [2] a package with utility functions on top of haskell-src-exts The generator can be found at [3] when compiled run it from the directory with the source files (build root). When running the generator the following options are probably useful: --no-vendorf=novendor (removes the extensions from vendors listed in the novendor file, to reduce the output a bit) -o output (output to the `output` subdirectory) -c (generate compatibility with the current OpenGLRaw) [1] https://github.com/Laar/opengl-api [2] https://github.com/Laar/CodeGenerating [3] https://github.com/Laar/OpenGLRawgen

2 1

Conversion of GLsizei to GLfloat
by Achim Krause 20 Jan '12

20 Jan '12

Hello everyone, I'm making my first experiences with OpenGL at the moment. It's really nice to use, but I got one issue which really freaks me out: Let's say I want to create a square-grid across the whole screen as background of a very basic 2D game. The application is meant to run in full screen mode. Since I want it to work on different resolutions and screen formats I introduced an IORef relSize (of type (GLfloat,GLfloat)) which is meant to store the size of the squares relative to the current window size, and tried to set a reshape callback in the form of reshape relS s@(Size w h) = do viewport $= (Position 0 0, s) relS $= (size / w, size / h) where size is just a name for the (at another place) defined absolute size for the squares. The Problem is that i see absolutely no way to convert w and h (which are of type GLsizei) in order to yield a value of type GLfloat. Is there any way to extract a Haskell Integer value from values of type GLsizei and convert a Haskell Float value to a GLfloat? Or is there a more direct way to do what I'm trying to achieve? The only solution i've come up with so far is using read.show as converter, which cannot really be the intended way of doing this. Thank you very much! Sincerely, Achim Krause

2 1

OpenGLRaw naming convention
by L Corbijn 16 Jan '12

16 Jan '12

Hello HOpenGL, While working on my OpenGLRaw-generator which is getting quite good (current OpenGL compiles with minor changes) I've come to wonder/worry about the current naming convention of Raw. The current naming scheme of OpenGLRaw can best be described as, try to remove the vendor names (NV, ARB, etc. suffixes) unless it will result in a conflict. To give two examples, MultiTexCoord2dARB -> MultiTexCoord2d, as there is none defined otherwise, while glPrimitiveRestartIndexNV keeps it's name as glPrimitiveRestartIndex is a different function. When generating code I've come across a few nasty disadvantages with no obvious solution in this scheme. 1. What to do when two or more vendors have the same enum/function which should be promoted to the one without vendor name. 2. The mixing of functions with and without vendor name, e.g. glPrimitiveRestart, glPrimitiveRestartIndexNV from NVidia's PrimitiveRestart extension. 3. Breaking changes, what if a new extension or even a new OpenGL version adds a different enum/function with the same name (without vender part), as the striped name collides the extension must be re-added leading to some code breaking (maybe even silently!). The only advantage I see is that two enums/functions who differ in name also differ in value/implementation. Therefore I would like to know what people think about the current naming convention, and whether it would be a major issue to change it (probably to keeping the vendor names everywhere). Greetings, Lars

2 3

Invitation to connect on LinkedIn
by Stan Serebryakov via LinkedIn 16 Jan '12

16 Jan '12

LinkedIn ------------ Stan Serebryakov requested to add you as a connection on LinkedIn: ------------------------------------------ Christopher, I'd like to add you to my professional network on LinkedIn. - Stan Accept invitation from Stan Serebryakov http://www.linkedin.com/e/-f6fe7z-gxhwfedx-6r/77PN7KA73EVxsEv0693Na8O7A7iYG… View invitation from Stan Serebryakov http://www.linkedin.com/e/-f6fe7z-gxhwfedx-6r/77PN7KA73EVxsEv0693Na8O7A7iYG… ------------------------------------------ Why might connecting with Stan Serebryakov be a good idea? Stan Serebryakov's connections could be useful to you: After accepting Stan Serebryakov's invitation, check Stan Serebryakov's connections to see who else you may know and who you might want an introduction to. Building these connections can create opportunities in the future. -- (c) 2011, LinkedIn Corporation

1 0

OpenGL-Raw generator
by L Corbijn 11 Dec '11

11 Dec '11

Hello, 0123456789012345678901234567890123456789012345678901234567890123456789012 OpenGL Raw is still 'stuck' at version 3.2 of the OpenGL Specification. Updating it to a more recent version (including adding more extensions) is quite a task, and quite boring one too. Fortunately there are specifications [1] which specifies all the functions and enumeration values. As a possible solution I've created a generator to generate the most of the OpenGLRaw, including the most boring parts. The code has (finally) been uploaded to Github and can be found at [2]. The current situation is that it's almost undocumented and there are no options yet (every path, etc. is hard-coded). The current implementation (the develop branch) generates the following, * Enum values and functions in line with the Spec files of OpenGL, where for each category in the spec there is a corresponding module. * Several grouping modules which group the previously modules in to logical groups. The current implementation groups it into vendor modules (with all extension from that vendor), and ones for the core profiles. * A list of all the modules generated, in a format that can be used to make the cabal file. Most of the base things (loading proc addresses, the bare cabal file, the types) are reused for building the generated files. The biggest change from OpenGLRaw is the layout of modules which define the core of OpenGL. Raw has two modules (which get bundled) for defining all enums and functions up to GL3.1. While the generator groups them into modules by the spec version they were introduced, and makes an export for each module. Furthermore, the use of the CPP to make the foreign imports has abandoned as this wasn't really practical with haskell-src-exts. For those who are interested in building it, the major non-hackage dependencies are: * opengl-api, [3], A package by Vo Minh Thu to parse the OpenGL spec files, you need the head of develop to parse the current specs. * CodeGenerating, A package I made with all sorts of more generic functions used to generate haskell code, based on haskell-src-exts. Again take the head of develop for all the functions needed. If you would just like the output of it all without the hassle of building it, send email me for an archive. I hope this tool could be made of use in updating the OpenGLRaw package, as I currently see nobody doing it by hand. So if you have any question or comment about the tool please email me. Greetings, Lars [1] http://www.opengl.org/registry/#specfiles [2] https://github.com/Laar/OpenGLRawgen [3] https://github.com/Laar/opengl-api/tree/develop [4] https://github.com/Laar/CodeGenerating/tree/develop

2 3

Re: [HOpenGL] [Haskell-cafe] ANN: Haskell OpenGL package updates
by Jason Dagit 30 Oct '11

30 Oct '11

On Fri, Oct 28, 2011 at 2:07 PM, Edward Kmett <ekmett(a)gmail.com> wrote: > Jason, > Thank you for taking ownership of HOpenGL! Thanks! > I would like to make a formal request for there to be some way to get access > to either > Graphics.Rendering.OpenGL.Raw.Core31.TypesInternal > or that > Graphics.Rendering.OpenGL.Raw.Core31.Types > re-export the newtype wrappers it places around CDouble and CFloat. > As things stand the only way to work with them is to pointlessly round-trip > through rational or pray that GHC is smart enough to automatically convert > once it sees through the newtype, which it isn't, potentially costing me > orders of magnitude of performance in tight loops in exchange for > implementation freedom the current OpenGL bindings do not use on any > platform. Yes, it's a real problem. I think there are a couple directions we could move in (and some may not even be mutually exclusive). Andy Gill created this workaround: {-# RULES "realToFrac/a->GLfloat" realToFrac = \x -> GLfloat (realToFrac x) #-} {-# RULES "realToFrac/GLfloat->a" realToFrac = \(GLfloat x) -> realToFrac x #-} That one helps a lot for most people. Someone made a libraries proposal that also helps the conversion situation but I don't have the details handy at the moment. If you read here, I'd like to get some MArray support in and I think it's possible, although I haven't the idea I proposed yet: http://www.haskell.org/pipermail/haskell-cafe/2011-March/090511.html Another thing we could do is find a different balance between newtypes and the C types. I'm totally onboard with exposing all of OpenGLRaw. I think we just need to sufficiently document the "internal" bits so that only people who absolutely need them will use them. That's how I see ByteString and it seems to be working there. Thanks for your suggestion (and your pull request on github, yay for collaborative tools!). Jason

2 1