- HOpenGL - Haskell.org

Re: [Haskell-cafe] Fw: patch applied (ghc): Remove the OpenGL family of libraries fromextralibs
by Jefferson Heard 25 Jul '08

25 Jul '08

Well, since HOpenGL seems to support practically all of OpenGL 2.1, I don't see that there's much to maintain, except compatibility with upcoming releases of GHC and possibly some optimization. Maybe I'm missing something, though. Is there a list of outstanding bugs somewhere? I personally know of one bug that I found some time ago, which I simply worked around, but a comprehensive list, I'm not aware of. -- Jeff On Fri, Jul 25, 2008 at 1:27 PM, Don Stewart <dons(a)galois.com> wrote: > claus.reinke: >> FYI: Haskell's OpenGL binding has just been dropped from GHC's >> extralibs, which means that it will no longer be kept in sync with GHC >> development, at least not by GHC HQ. >> >> GHC HQ has its hands full and -generally speaking - extralibs are to >> be replaced by H(L)P, the Haskell (Library) Platform: >> >> http://haskell.org/haskellwiki/Haskell_Platform >> >> so this part is understandable. But OpenGL has been dropped before >> H(L)P is ready to take over from extralibs, and at the recent GHC Irc >> meeting on the topic >> >> http://hackage.haskell.org/trac/ghc/attachment/wiki/IRC_Meetings/ghc-2008-0… >> >> the mood seemed to favour not including OpenGL&co in the initial >> versions of H(L)P. Sven put a lot of good work into these libraries, >> but he is often not around for a long time, and it would be a shame >> if these gems were orphaned and went out of sync in the meantime. >> >> While I haven't used OpenGL in a while, I've always hoped to come >> back to that, not to mention Sven's spatial audio binding additions. >> And if I'm not mistaken, there are other community members who >> are using these libs right now for research, possibly even prototyping >> in connection with a startup? >> >> So, if one of you wanted to step forward and offer to keep these >> Haskell bindings for OpenGL&co maintained, perhaps steward them >> into the H(L)P, now would probably be a good time. >> >> Just thought I'd forward this, for those not following cvs-ghc, >> Claus > > Note the OpenGL are still just as maintained as they used to be -- that > is, it hasn't had a maintainer for several years. > > The only change is that the GHC developers don't put them in a tarball > on haskell.org/ghc prior to releasing GHC itself. > > -- Don > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- I try to take things like a crow; war and chaos don't always ruin a picnic, they just mean you have to be careful what you swallow. -- Jessica Edwards

1 0

Re: [Haskell-cafe] Rendering TTF fonts in Haskell and OpenGL
by Claus Reinke 22 Feb '08

22 Feb '08

[cc-ed to hopengl list; are there many haskell opengl users not on that list, btw?] a standard package for easy-to-use, high-quality, portable font support would make a great addition to haskell's otherwise nice opengl bindings! is there a reason for going directly to freetype? from the old opengl font survey at http://www.opengl.org/resources/features/fontsurvey/ i got the impression that accessing freetype2 via ftgl might make things slightly easier, while also offering more options (geometry instead of texture fonts), or did I misread? http://ftgl.wiki.sourceforge.net/ the source doesn't seem to have changed since the end of 2004, which might imply some issues with newer compilers, etc? has anyone tried to bind to ftgl? any comments on that route? and to what extent to the haskell gui libs with opengl support allow their fonts to be used for text geometry or textures in opengl? claus ----- Original Message ----- From: "Bit Connor" <bit(a)mutantlemon.com> To: "Jeremy Shaw" <jeremy(a)n-heptane.com> Cc: "Haskell-cafe Cafe" <haskell-cafe(a)haskell.org> Sent: Friday, February 22, 2008 2:42 PM Subject: Re: [Haskell-cafe] Rendering TTF fonts in Haskell and OpenGL >I also have made haskell bindings to FreeType, including support for > extracting glyph outlines. > > I haven't had time to publish it yet. Hopefully I'll get around to it soon. > > On Mon, Feb 18, 2008 at 5:07 AM, Jeremy Shaw <jeremy(a)n-heptane.com> wrote: >> At Mon, 18 Feb 2008 01:26:17 +0000, >> >> Luke Palmer wrote: >> >> > I have an immature, but precise and picky implementation that renders text in >> > a ttf font to an OpenGL texture (using SDL-ttf) here: >> > http://svn.luqui.org/svn/misc/luke/work/code/haskell/frp/Fregl/Draw.hs >> > (It may have some dependencies in the same directory). Text support is >> > way at the bottom. >> >> Along the same lines, I have an imcomplete, but direct binding to >> freetype and an incomplete binding to GLX which can be used to draw >> text to opengl textures: >> >> http://n-heptane.com/nhlab/repos/haskell-freetype/ >> http://n-heptane.com/nhlab/repos/haskell-glx/ >> >> This file contains an example of drawing text using GLX+FreeType: >> >> http://n-heptane.com/nhlab/repos/haskell-freetype/FreeTypeTest.hs >> >> This code has not been touched in a few years, so it probably needs >> some updates to work with ghc 6.8. Also, I believe the X11 package now >> has builtin support for ClientMessage, so that module can go away. >> >> j. >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe(a)haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe

1 0

threading and OpenGL - some answers
by Jules Bean 07 Oct '07

07 Oct '07

Hi, I managed to get my openGL threading working and I thought I'd post the results here for the mailing list archives if nothing else. I was already aware that it wouldn't be possible to make openGL calls from another thread unless I took care with forkOS and bound threads. That's ok, because I was planning to do only do openGL in the main thread and just do 'work' in other threads. Just using forkIO naively works, but with some caveats: your worker threads only get processing time as often as your 'idle' callback kicks in, and if they work the CPU hard, the UI becomes unresponsive. The solution to this is (a) compile with ghc -threaded, to use the properly threaded RTS. This makes things quite a bit more responsive (and worker threads run quite happily without needing idle callbacks) but the UI still feels a little sticky. (b) run with +RTS -C0 -RTS to make thread switching more aggressive, or -N2 if you have more than one CPU/core. Then everything works nicely. Jules

1 0

Installing GLUT package on Win32
by Ronald Guida 10 Sep '07

10 Sep '07

I am trying to install freeglut and the Haskell GLUT package on my Windows XP machine, and I just can't get it to work. I am wondering if anyone else has tried to install freeglut and the Haskell GLUT package on a Windows XP machine. Here's a summary of what I tried so far: I downloaded freeglut and successfully compiled it with Visual Studio 2003. I found out that in order to compile the GLUT package, I need a unix shell, so I installed MinGW, MSYS, and MSYS-DTK. Naturally, I am from the world of Windows, so the unix shell is a whole new foreign world for me. I downloaded the GLUT package from [1] and tried to compile it. The compile succeeded, but the package would not work. [1] http://hackage.haskell.org/packages/archive/GLUT/2.0/GLUT-2.0.tar.gz Eventually, I found out that the latest version of GLUT is GLUT-2.1.1, and in order to get it, I need to use darcs. Bear in mind, I started learning Haskell a few months ago, and up to this point I simply had not yet heard of darcs. Darcs is available in pre-compiled form for several systems, including Win32/cygwin, but not Win32/MinGW. I downloaded the sources for darcs, zlib, and curl, and eventually get darcs to compile. Finally, I downloaded GLUT-2.1.1 with the command: $ darcs get http://darcs.haskell.org/libraries/GLUT/ When I tried to compile this, I was told that I have two missing dependencies: "array" and "containers". So I performed a "darcs get" on the array library and tried to compile it. It failed to compile. Eventually, I edited the GLUT.cabal file to remove the "array" and "containers" dependencies, and got GLUT to compile, but the library still doesn't work. When I attempt to compile a program that uses glut, and link with "freeglut.dll", as produced by VS-2003, I get linker errors. In addition, I tried to compile freeglut under MinGW, but it failed to compile as well. Again, the unix world, including the shell, the conventions, and the toolchains, are all foreign to me, so for all I know, I could be completely missing something that's both obvious and fundamental. Thank you for any help anyone can provide. -- Ron P.S. Are there any alternatives to GLUT/freeglut, that work with Haskell, and that are /easy/ to install on a Windows box?

1 1

renderString problems
by Dave Tapley 26 Aug '07

26 Aug '07

Hi all, I'm having a lot of trouble using renderString from Graphics.UI.GLUT.Fonts. All my attempts to render a StrokeFont have so far failed. Using a BitmapFont I can get strings to appear but they demonstrate the odd behaviour of translating themselves a distance equal to their length every time my displayCallback function is evaluated. My requests are: * Does anyone know how to keep the position fixed? * Are there any good examples of (working) GLUT code available on the web, I'm finding it very hard to make any progress at the moment. Certainly not at Haskell speed :( I am using the following code: > import Graphics.UI.GLUT > main = do > getArgsAndInitialize > createWindow "" > displayCallback $= update > actionOnWindowClose $= ContinueExectuion > mainLoop > > update = do > clear [ColorBuffer] > renderString Fixed8By13 $ "Test string" > flush Cheers, Dave

3 2

Bug (typo) in Graphics.UI.GLUT.Begin
by Dave Tapley 31 Jul '07

31 Jul '07

Hi all, Sorry if this is known; I searched the achieves but nothing came up. I just noticed that one of the constructors for the data type ActionOnWindowClose, namely ContinueExectuion contains an incorrect spelling of execution as 'exectuion'. As shown here: http://haskell.org/ghc/docs/latest/html/libraries/GLUT/Graphics-UI-GLUT-Beg… My ghc-pkg reports version: GLUT-2.0 Dave,

1 0

"can't load .so/.dll for: glut32 (addDll: unknown error)"
by Hugh Perkins 23 Jul '07

23 Jul '07

Hi, Kindof a dumb question I know, what do I need to do to avoid getting the following message when I try loading GLUT? J:\dev\haskell>ghci -fglasgow-exts Teapots.hs ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.6.1, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \____/\/ /_/\____/|_| Type :? for help. Loading package base ... linking ... done. Ok, modules loaded: Main. Prelude Main> main Loading package OpenGL-2.2.1 ... linking ... done. Loading package GLUT-2.1.1 ... can't load .so/.DLL for: glut32 (addDLL: unknown error) As you can see, running ghc 6.6.1, on Windows.

2 1

Set polygon mode?
by Hugh Perkins 23 Jul '07

23 Jul '07

Hi, question, how do I do "Gl.glPolygonMode(Gl.GL_BACK, Gl.GL_LINE);" in HOpenGl? Maybe something like "polygonMode $= (Line,Line)" ? (By the way, what does "$=" do?)

3 2

Compiling hopengl apps?
by Hugh Perkins 21 Jul '07

21 Jul '07

Started to play with hopengl. It's pretty cool :-) Very easy to use, quite cool :-) Started to look at perf. What interests me most is to see how fast we can make vertex3f calls. Basically, we're testing the speed of the haskell/c boundary, where security(?) and marshalling are going to occur. Yes, we can send the vertices to a vertexarray and not have to handle vertex3f calls, but that's not what I want to measure ;-) So, have a really rough and ready application that draws 45000 triangles a frame, then measures the framerate. Thats about 150,000 calls to vertex3f per frame. The application runs in Java, C#, and now Haskell. Running in ghci, this runs at about 1.5 fps, really ballpark, havent checked I'm really drawing the number of triangles I think I'm drawing, or settings such as backface-culling or shademodel. That's not too bad. I'd like to compile to an executable to increase the framerate, but it's giving me the following output: J:\dev\haskell>ghc -fglasgow-exts -O2 -o OglPerf.exe OglPerf.hs OglPerf.o(.text+0x1f4):ghc3668_0.hc: undefined reference to `glutPostRedisplay@0 ' OglPerf.o(.text+0x255):ghc3668_0.hc: undefined reference to `glVertex3f@12' OglPerf.o(.text+0x1148):ghc3668_0.hc: undefined reference to `glViewport@16' OglPerf.o(.text+0x1157):ghc3668_0.hc: undefined reference to `glMatrixMode@4' OglPerf.o(.text+0x115f):ghc3668_0.hc: undefined reference to `glLoadIdentity@0' OglPerf.o(.text+0x11cc):ghc3668_0.hc: undefined reference to `glFrustum@48' OglPerf.o(.text+0x11db):ghc3668_0.hc: undefined reference to `glMatrixMode@4' OglPerf.o(.text+0x11e3):ghc3668_0.hc: undefined reference to `glLoadIdentity@0' OglPerf.o(.text+0x11fd):ghc3668_0.hc: undefined reference to `glTranslatef@12' OglPerf.o(.text+0x1672):ghc3668_0.hc: undefined reference to `OpenGLzm2zi2zi1_Gr aphicsziRenderingziOpenGLziGLziVertexSpec_Vertex3_con_info' OglPerf.o(.text+0x1764):ghc3668_0.hc: undefined reference to `OpenGLzm2zi2zi1_Gr aphicsziRenderingziOpenGLziGLziVertexSpec_Vertex3_con_info' OglPerf.o(.text+0x1856):ghc3668_0.hc: undefined reference to `OpenGLzm2zi2zi1_Gr aphicsziRenderingziOpenGLziGLziVertexSpec_Vertex3_con_info' OglPerf.o(.text+0x1948):ghc3668_0.hc: undefined reference to `OpenGLzm2zi2zi1_Gr aphicsziRenderingziOpenGLziGLziVertexSpec_Vertex3_con_info' OglPerf.o(.text+0x1b56):ghc3668_0.hc: undefined reference to `OpenGLzm2zi2zi1_Gr aphicsziRenderingziOpenGLziGLziPrimitiveMode_Quads_closure' OglPerf.o(.text+0x1de9):ghc3668_0.hc: undefined reference to `OpenGLzm2zi2zi1_Gr aphicsziRenderingziOpenGLziGLziFramebuffer_marshalClearBuffer_closure' OglPerf.o(.text+0x1e00):ghc3668_0.hc: undefined reference to `OpenGLzm2zi2zi1_Gr aphicsziRenderingziOpenGLziGLziFramebuffer_sum_closure' OglPerf.o(.text+0x1e42):ghc3668_0.hc: undefined reference to `OpenGLzm2zi2zi1_Gr aphicsziRenderingziOpenGLziGLziFramebuffer_sum_closure' [...] aphicsziRenderingziOpenGLziGLziStringQueries_Vendor_closure' OglPerf.o(.text+0x340f):ghc3668_0.hc: undefined reference to `OpenGLzm2zi2zi1_Gr aphicsziRenderingziOpenGLziGLziStringQueries_Renderer_closure' OglPerf.o(.text+0x3634):ghc3668_0.hc: undefined reference to `OpenGLzm2zi2zi1_Gr aphicsziRenderingziOpenGLziGLziBasicTypes_Enabled_closure' OglPerf.o(.text+0x3668):ghc3668_0.hc: undefined reference to `OpenGLzm2zi2zi1_Gr aphicsziRenderingziOpenGLziGLziCoordTrans_normalizze_closure' OglPerf.o(.text+0x36c1):ghc3668_0.hc: undefined reference to `OpenGLzm2zi2zi1_Gr aphicsziRenderingziOpenGLziGLziBasicTypes_Enabled_closure' OglPerf.o(.text+0x3716):ghc3668_0.hc: undefined reference to `OpenGLzm2zi2zi1_Gr aphicsziRenderingziOpenGLziGLziBasicTypes_Enabled_closure' OglPerf.o(.text+0x374a):ghc3668_0.hc: undefined reference to `OpenGLzm2zi2zi1_Gr aphicsziRenderingziOpenGLziGLziColors_lighting_closure' [...] collect2: ld returned 1 exit status What am I missing?

2 2

Segfaults on MouseWheel
by Hendrik Iben 21 Jul '07

21 Jul '07

Hi, I've been experimenting some time with the OpenGL and GLUT bindings and there is one thing I do not understand. While I've read trough the archive and understand that the GLUT binding cannot handle more than the standard Mouse-buttons I thought handling the MouseWheel-buttons should work. However, regardless of whether I actually want to know about Mouse-Buttons my applications segfault when I trigger the WheelUp-Button. WheelDown works as expected (They are reported as button 4 and 5 in X). I don't know where that behaviour comes from - other buttons at least give an error message about the missing marshalling. I guess something is wrong with my setup as I could not find any similar error report (AMD64, linux kernel 2.6.19 (64bit), X.org 7.2, GHC 6.6.1, GLUT 2.1.1, OpenGL-2.2.1). Any suggestions how to further investigate this ? I'm willing to add hooks to the GLUT (?) package if someone can point me to the right direction... This is the output from doing a backtrace on the dumped core - not very informative... : #0 0x0000000000000000 in ?? () #1 0x00002b6f40ccd172 in __glutRegisterEventParser () from /usr/lib/libglut.so.3 #2 0x00002b6f40ccdeb2 in glutMainLoop () from /usr/lib/libglut.so.3 #3 0x0000000000411c08 in GLUTzm2zi1zi1_GraphicsziUIziGLUTziBegin_mainLoop_info () #4 0x000000000057b498 in stg_ap_0_fast () #5 0x0000000000529b98 in s5YF_info () #6 0x00002aaaaac8eaf8 in ?? () #7 0x00000000007c89d0 in ?? () #8 0x0000000000000000 in ?? () Best regards, Hendrik

1 2