- HOpenGL - Haskell.org

GLUT_Game
by Andre W B Furtado 26 Mar '02

26 Mar '02

[Trying to make gameMode not so highly untested ... :)] Hello everybody. I'm not sure if I understood how the HOpenGL binding deals with GLUT_Game, so I'd like to exchange some ideas... 1. Ok, there is no ugly strings like "800x600:16@60" anymore. But can I COMPLETELY forget about calling function "createWindow"? If so, what about the configuration list (such as [ Single, GLUT.Rgb ])? I mean, how do I specify that I'd like to use double-buffering, rgb or rgba pallet, etc., in the gamemode? Besides that, is there any real danger if I reshape the window via reshapeWindow and its siblings? 2. In previuos experiences I noticed that I need to call enterGameMode just after gameMode. Is that True? 3. If it is required a GameModeWidth >= 640, for example, is it possible to predict wich of the possible configurations (640, 800, etc.) will be the one chosen? 4. What really happens when there are no possible specified configurations? I always get an illegal operation... 5. Is it possible to know in runtime if no possible configuration was detected? Case yes, what would be a reasonable approach to handle with this (exiting the program, trying another configuration, etc.)? 4. Is the best place to call leaveGameMode just before my general exiting routine (such as exitWith)? Thanks a lot for your time! -- Andre ps: coming soon - the first (AFAIK) Haskell Game Engine

1 0

game mode
by Andre W B Furtado 17 Mar '02

17 Mar '02

It is said in GLUT_Game.hs that: "gameMode is highly untested because it currently only works with WinDoze". Is this true for every (OpenGL + GLUT) API? BTW, I'm having some difficulty in trying to make this stuff work: In OpenGL, we only need to set a string (such as "640x480:8@60") and use it as a parameter to glutGameModeString. In HOpenGL, however, there is a function called "gameMode" but I can't use it, since the type of its parameter is not exported by module GLUT_Game. Am I missing something obvious? Can anyone tell me me how to set my game mode correctly? Thanks a lot, -- Andre

2 1

-O strangeness
by Robert Vollmert 07 Mar '02

07 Mar '02

Hello, I've been experimenting with HOpenGL a little, and have run into strange behaviour when compiling with -O. In particular, while things work as expected when compiling normally, if I compile the following module with -O, drawLine' appears to scale the line by 2, while drawLine works as before. module Lines where import GL drawLine = do pushMatrix beginEnd Lines . sequence_ . map vertex $ [ Vertex2 0 0, Vertex2 0 (1::GLfloat) ] popMatrix drawLine' = do pushMatrix scale 1 1 (1::GLfloat) beginEnd Lines . sequence_ . map vertex $ [ Vertex2 0 0, Vertex2 0 (1::GLfloat) ] popMatrix This was tested using the attached program. I'm using HOpenGL-1.01 with the recent patch, and a ghc from CVS which is about a week old. When compiling Lines.hs with -O, I get /tmp/ghc14725.hc: In function `s8Wy_ret': /tmp/ghc14725.hc:474: warning: implicit declaration of function `glScalef' Also, if I actually compile the test program with -O, it doesn't display anything.

3 3

ANNOUNCE: "VOP" - POV-Ray Previewer using HOpenGL
by Wolfgang Thaller 04 Mar '02

04 Mar '02

VOP is a program that parses POV-Ray (www.povray.org) scene description files and renders them using OpenGL. While the resulting 3D images are not as nice as POV-Ray's, VOP is anywhere from five to two thousand times faster (depending on situation and measurement method). VOP consists of slightly over 10000 lines of Haskell code and a little less than 1000 lines of C++ code. GLUT is used for the front end. I offer a binary version for Windows, but source code is available and should be easy to compile on Linux. I would also appreciate any help that I can get, so if anyone has too much free time... ;-) (Yes, I know that there is no such thing as "too much free time"...) I'm hoping for your feedback. Yours sincerely, Wolfgang Thaller

2 2

Patches for HOpenGL-1.01
by Sven Panne 04 Mar '02

04 Mar '02

Appended are a bunch of patches for HOpenGL-1.01 to catch up with the latest changes in GLU and the CVS HEAD version of GHC. They provide minimal fixes for the ubiquitous GLU versionitis and the current Haskell library reorganization. People which are using only "official" GHCs and don't have any problems with their GLU setup can happily ignore this mail... I don't really want to release Yet Another HOpenGL Version (tm) before a new GHC is out, so this seems to be the easiest way to keep people on the bleeding edge happy. Cheers, S. diff -u -r HOpenGL-1.01-orig/examples/misc/BitSet.hs HOpenGL-1.01/examples/misc/BitSet.hs --- HOpenGL-1.01-orig/examples/misc/BitSet.hs Fri Jan 14 16:06:20 2000 +++ HOpenGL-1.01/examples/misc/BitSet.hs Mon Mar 4 17:32:03 2002 @@ -7,24 +7,24 @@ import Ix(rangeSize) import Monad(liftM) -import IOExts +import Data.Array.IO -newtype BitSet = BitSet (IOArray Int Bool) +newtype BitSet = BitSet (IOUArray Int Bool) emptyBS :: Int -> IO BitSet -emptyBS size = liftM BitSet $ newIOArray (0, size-1) False +emptyBS size = liftM BitSet $ newArray (0, size-1) False clearBS :: BitSet -> Int -> IO () -clearBS (BitSet bs) i = writeIOArray bs i False +clearBS (BitSet bs) i = writeArray bs i False clearAllBS :: BitSet -> IO () clearAllBS bs = mapM_ (clearBS bs) [0 .. sizeBS bs - 1] setBS :: BitSet -> Int -> IO () -setBS (BitSet bs) i = writeIOArray bs i True +setBS (BitSet bs) i = writeArray bs i True isSetBS :: BitSet -> Int -> IO Bool -isSetBS (BitSet bs) i = readIOArray bs i +isSetBS (BitSet bs) i = readArray bs i sizeBS :: BitSet -> Int -sizeBS (BitSet bs) = rangeSize (boundsIOArray bs) +sizeBS (BitSet bs) = rangeSize (bounds bs) diff -u -r HOpenGL-1.01-orig/examples/misc/FPSCounter.hs HOpenGL-1.01/examples/misc/FPSCounter.hs --- HOpenGL-1.01-orig/examples/misc/FPSCounter.hs Tue Mar 14 12:07:47 2000 +++ HOpenGL-1.01/examples/misc/FPSCounter.hs Mon Mar 4 17:33:36 2002 @@ -9,6 +9,7 @@ import IOExts import Time +import Data.Array.IO data FPSCounter = FPSCounter (IORef Int) -- 0-based counter for averaging @@ -20,18 +21,18 @@ -- The initial value is as wrong as any other, but it is -- automatically corrected after a wrap-around. ct <- getClockTime - elapsedTimes <- newIOArray (1, numUpdates) ct + elapsedTimes <- newArray (1, numUpdates) ct return $ FPSCounter counter elapsedTimes getFPS :: FPSCounter -> IO Float getFPS (FPSCounter counter elapsedTimes) = do - let (lo, hi) = boundsIOArray elapsedTimes + let (lo, hi) = bounds elapsedTimes numUpdates = hi - lo + 1 count <- readIORef counter - oldElapsed <- readIOArray elapsedTimes (count + lo) + oldElapsed <- readArray elapsedTimes (count + lo) newElapsed <- getClockTime writeIORef counter ((count + 1) `mod` numUpdates) - writeIOArray elapsedTimes (count + lo) newElapsed + writeArray elapsedTimes (count + lo) newElapsed return $ fromIntegral numUpdates / max (timeDiffInSecs (diffClockTimes newElapsed oldElapsed)) 1.0e-4 -- safety diff -u -r HOpenGL-1.01-orig/examples/misc/PackLib.hs HOpenGL-1.01/examples/misc/PackLib.hs --- HOpenGL-1.01-orig/examples/misc/PackLib.hs Sun Jun 11 16:43:43 2000 +++ HOpenGL-1.01/examples/misc/PackLib.hs Mon Mar 4 17:18:24 2002 @@ -17,7 +17,7 @@ import List(isPrefixOf, nub) import Monad(liftM, when, unless) import Directory(getDirectoryContents) -import IOExts(hSetBinaryMode) -- see comment in front of openBinaryFile +import GHC.Handle(hSetBinaryMode) -- see comment in front of openBinaryFile {- -- DEBUGGING ONLY diff -u -r HOpenGL-1.01-orig/lib/GLUT_CBGlobal.gc.in HOpenGL-1.01/lib/GLUT_CBGlobal.gc.in --- HOpenGL-1.01-orig/lib/GLUT_CBGlobal.gc.in Thu Mar 16 11:56:46 2000 +++ HOpenGL-1.01/lib/GLUT_CBGlobal.gc.in Mon Mar 4 16:29:41 2002 @@ -29,7 +29,7 @@ import Prelude hiding (Either(Left)) -import IOExts(fixIO, freeHaskellFunctionPtr) +import IOExts(fixIO) import GL_DIS import GL_BasicTypes(WindowPosition(..)) import GLUT_CallbackUtils(GlobalCallback(..), gFunc) diff -u -r HOpenGL-1.01-orig/lib/GLUT_CallbackUtils.hs HOpenGL-1.01/lib/GLUT_CallbackUtils.hs --- HOpenGL-1.01-orig/lib/GLUT_CallbackUtils.hs Wed Mar 15 14:05:33 2000 +++ HOpenGL-1.01/lib/GLUT_CallbackUtils.hs Mon Mar 4 16:29:53 2002 @@ -25,7 +25,7 @@ GlobalCallback(..), gFunc ) where -import IOExts(IORef, newIORef, readIORef, writeIORef, freeHaskellFunctionPtr) +import IOExts(IORef, newIORef, readIORef, writeIORef) import Maybe(isJust) import GL_DIS import GLUT_Window(Window, getWindow) diff -u -r HOpenGL-1.01-orig/lib/GLUT_Menu.gc HOpenGL-1.01/lib/GLUT_Menu.gc --- HOpenGL-1.01-orig/lib/GLUT_Menu.gc Sun Oct 28 16:16:30 2001 +++ HOpenGL-1.01/lib/GLUT_Menu.gc Mon Mar 4 16:29:09 2002 @@ -27,7 +27,7 @@ MenuAction, MenuItem(..), attachMenu ) where -import IOExts(IORef, newIORef, readIORef, writeIORef, freeHaskellFunctionPtr) +import IOExts(IORef, newIORef, readIORef, writeIORef) import Monad(unless) import GL_DIS import GLUT_CBWindow(MouseButton, marshall_MouseButton) diff -u -r HOpenGL-1.01-orig/lib/GLU_NURBS.gc.in HOpenGL-1.01/lib/GLU_NURBS.gc.in --- HOpenGL-1.01-orig/lib/GLU_NURBS.gc.in Thu Nov 1 18:06:55 2001 +++ HOpenGL-1.01/lib/GLU_NURBS.gc.in Mon Mar 4 17:00:15 2002 @@ -212,7 +212,7 @@ @GLU_1_3@%enum NurbsMode (Eq,Ord) GLfloat [ @GLU_1_3@% GLU_NURBS_RENDERER, -@GLU_1_3@% GLU_NURBS_TESSELATOR +@GLU_1_3@% GLU_NURBS_TESSELLATOR @GLU_1_3@% ] nurbsProperty :: NurbsObj -> NurbsProperty -> IO () diff -u -r HOpenGL-1.01-orig/lib/GLU_Quadrics.gc HOpenGL-1.01/lib/GLU_Quadrics.gc --- HOpenGL-1.01-orig/lib/GLU_Quadrics.gc Thu Nov 1 18:07:31 2001 +++ HOpenGL-1.01/lib/GLU_Quadrics.gc Mon Mar 4 16:29:16 2002 @@ -30,7 +30,7 @@ sphere, cylinder, disk, partialDisk ) where -import IOExts(fixIO, IORef, newIORef, readIORef, writeIORef, freeHaskellFunctionPtr) +import IOExts(fixIO, IORef, newIORef, readIORef, writeIORef) import Monad(when, unless) import GL_DIS import GL_BasicTypes(GLdouble, GLint, GLenum, GLboolean, marshall_GLboolean) diff -u -r HOpenGL-1.01-orig/lib/GL_Errors.gc HOpenGL-1.01/lib/GL_Errors.gc --- HOpenGL-1.01-orig/lib/GL_Errors.gc Sun Nov 11 18:31:59 2001 +++ HOpenGL-1.01/lib/GL_Errors.gc Mon Mar 4 15:32:14 2002 @@ -53,7 +53,7 @@ % GLU_NURBS_ERROR31, GLU_NURBS_ERROR32, GLU_NURBS_ERROR33, % GLU_NURBS_ERROR34, GLU_NURBS_ERROR35, GLU_NURBS_ERROR36, % GLU_NURBS_ERROR37, GLU_INVALID_ENUM, GLU_INVALID_VALUE, -% GLU_OUT_OF_MEMORY, GLU_INCOMPATIBLE_GL_VERSION +% GLU_OUT_OF_MEMORY % ] -- Silly line, because some Green Card versions stumble over a directive at EOF diff -u -r HOpenGL-1.01-orig/lib/GL_FFI.hs.in HOpenGL-1.01/lib/GL_FFI.hs.in --- HOpenGL-1.01-orig/lib/GL_FFI.hs.in Sat Jul 8 23:27:10 2000 +++ HOpenGL-1.01/lib/GL_FFI.hs.in Mon Mar 4 17:05:45 2002 @@ -18,8 +18,14 @@ Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA -} -@HAS_STORABLE@module GL_FFI ( module Foreign ) where +@HAS_STORABLE@module GL_FFI ( module Foreign, module Addr, module ForeignObj, +@HAS_STORABLE@ freeHaskellFunctionPtr, makeStablePtr ) where @HAS_STORABLE@import Foreign +@HAS_STORABLE@import Addr +@HAS_STORABLE@import ForeignObj +@HAS_STORABLE@foreign import "freeHaskellFunctionPtr" unsafe +@HAS_STORABLE@ freeHaskellFunctionPtr :: Addr -> IO () +@HAS_STORABLE@makeStablePtr = newStablePtr @HAS_STORABLE@ {- module GL_FFI (

1 0

RE: [HOpenGL] HOpenGL and the new library hierarchy
by Simon Marlow 25 Feb '02

25 Feb '02

> Sorry for the long period of silence, but I'm currently > slowly recovering > from a head crash (my hard disk's head, to be exact, not *mine* :-). > > I'm going to re-implement HOpenGL based on the .spec files > and the new FFI, > moving to the new library hierarchy on the way. Great! > So I'm seeking advice where > to put it exactly. My suggestion: > > The GL/GLU modules reside into the subtrees > > Graphics.Drawing.OpenGL.GL > Graphics.Drawing.OpenGL.GLU > > with 2 modules of the same names, re-exporting the modules from the > subtrees. A module Graphics.Drawing.OpenGL re-exports those > two modules > again. This looks fine. > The GLUT modules reside in Graphics.UI.GLUT, with a module of the same > name, re-exporting the modules below it plus Graphics.Drawing.OpenGL > (Graphics.UI.OpenGL.GLUT looks a little bit like overkill, IMHO). > > I'm a little bit unhappy with "Drawing", "Rendering" would be more > appropriate, but I could live with that... I have no objection to a Drawing==>Rendering change; if you suggest this on libraries(a)haskell.org and no-one complains, then go ahead - we don't have any other occupants of the Graphics.Drawing namespace as yet. Cheers, Simon

1 0

HOpenGL and the new library hierarchy
by Sven Panne 24 Feb '02

24 Feb '02

Sorry for the long period of silence, but I'm currently slowly recovering from a head crash (my hard disk's head, to be exact, not *mine* :-). I'm going to re-implement HOpenGL based on the .spec files and the new FFI, moving to the new library hierarchy on the way. So I'm seeking advice where to put it exactly. My suggestion: The GL/GLU modules reside into the subtrees Graphics.Drawing.OpenGL.GL Graphics.Drawing.OpenGL.GLU with 2 modules of the same names, re-exporting the modules from the subtrees. A module Graphics.Drawing.OpenGL re-exports those two modules again. The GLUT modules reside in Graphics.UI.GLUT, with a module of the same name, re-exporting the modules below it plus Graphics.Drawing.OpenGL (Graphics.UI.OpenGL.GLUT looks a little bit like overkill, IMHO). I'm a little bit unhappy with "Drawing", "Rendering" would be more appropriate, but I could live with that... Comments/suggestions? Cheers, S.

2 2

forcing IO operations
by Andre W B Furtado 19 Feb '02

19 Feb '02

Curious problem... Suppose MyMonad is a Monad other than the IO Monad. Consider the following piece of code: > f :: MyMonad () > f = action1 Now suppose also that ioToMyMonad converts an IO Monad to a MyMonad Monad: > ioToMyMonad :: IO a -> MyMonad a > ioToMyMonad = return . unsafePerformIO Suppose also that action1 needs to perform some IO operation (called IO_op), which returns IO (). In other words, action1 would be: > action1 :: MyMonad () > action1 = do > -- MyMonad operations > ioToMyMonad $ IO_op > -- other MyMonad operations When I run f (via runMyMonad or something like that), I noticed that the io operation (IO_op) is not executed. I guess that this happens because of laziness properties, since the value returned by IO_op is useless to MyMonad. I have then two questions: 1. Does this really happen because of laziness properties? 2. Which is the best way to force IO_op to be performed? I tried the following approach: Step1: Change the type of IO_op from "IO ()" to "IO Bool" and make it returns True. Step2: Change action1 to > action1 :: MyMonad Bool > action1 = do > -- MyMonad operations > b <- ioToMyMonad $ IO_op > -- other MyMonad operations > return b Step3: Change the type of f to MyMonad Bool Step4: Finally, use this boolean somewhere after calling "runMyMonad", e. g., printing it on the screen. I'm sure this is not the best approach, so I'd really appreciate any suggestions. [I'm sending this mail to the HOpenGL list also because runMyMonad is being called inside the display callback, so perhaps it may have something to do with the problem] Thanks a lot, -- Andre

1 0

RE: [HOpenGL] news on FFI?
by Simon Marlow 05 Feb '02

05 Feb '02

> > I would like to know if that will help to solve that > "uncaught exception > > problem" when leaving HOpenGL programs. > > A strictly conforming implementation shouldn't have that problem, see: > > http://haskell.org/pipermail/ffi/2002-January/000436.html > > I know that Simon "RTS" Marlow :-) is on this list, what... who.. me? :-} > so perhaps he could answer > the question when GHC is changed this way... Ok, the problem as we all know is that System.exitWith now raises an exception rather than simply terminating the program. This is highly desirable behaviour especially in a concurrent system, and was essential in GHCi so that if the interpreted program calls System.exitWith we don't terminate GHCi itself. The problem is that this exception isn't propagated to the main thread automatically if it is raised in a child thread. Foreign-exported functions are run in child threads. Furthermore, it's not clear exactly how the exception should be propagated, because there isn't always a single main thread to send it to. Two workarounds spring to mind: firstly, you could wrap callbacks in a suitable exception handler. So instead of calling 'mkCallback e' where mkCallback is a foreign export dynamic, you would call 'mkCallback (Exception.catch e handler)' where handler is something like topHandler in fptools/ghc/lib/std/PrelTopHandler.lhs, but you probably want to discard all exceptions except ExitException. Perhaps GHC should do this wrapping automatically, I'm not sure. Alternatively you could call your own version of exitWith which does a real exit. Again, see PrelTopHandler.lhs for the function shutdownHaskellAndExit, which is our equivalent of hs_exit() (when we get around to catching up with the FFI spec, hs_exit() will probably be a synonym for shutdownHaskellAndExit()). Cheers, Simon

2 1

mainloop & return
by Andre W B Furtado 03 Feb '02

03 Feb '02

Is there any problem if the same function that calls "mainloop" returns a value? Ex.: main :: IO () main = do msg <- startGL putStrLn msg startGL :: IO String startGL = do -- init GLUT -- create window -- declare callback procedures mainloop return "ok"

2 2