ghc-6.0.1 and OpenGL enabled
Hi everyone. At this time the situation of HOpenGL and ghc --enable-hopenGl is very confusing to me. I tried to install the new HOpenGL package from Sven. But the make install doesnt seem to work. When I tried to compile a simple example of the Redbook the linker stops because of undefiened references to some c-functions. If theres some time I post the exact error-message .. Now I use the openGl that comes with the ghc and I've started to map the functions of HOpenGl to the corresponding ghc-openGl functions. Now my question: The push and popMatrix functions dont seem to be there in future. What should I use instead of this? If I have the following code: pushMatrix GL.translate $ vec2Vector3 pos let ANGLE adir = toAngle dir ANGLE aheadangle = toAngle headangle rotate adir $ Vector3 0.0 0.0 (1.0 :: GLfloat) callList $ head ownbodyDL rotate aheadangle $ Vector3 0.0 0.0 (1.0 :: GLfloat) callList $ ownheadDL popMatrix what are the lines I have to write, that ghc doesnt show errors? Cheers Patrick
Patrick Scheibe wrote:
The push and popMatrix functions dont seem to be there in future. What should I use instead of this? If I have the following code:
pushMatrix GL.translate $ vec2Vector3 pos let ANGLE adir = toAngle dir ANGLE aheadangle = toAngle headangle rotate adir $ Vector3 0.0 0.0 (1.0 :: GLfloat) callList $ head ownbodyDL rotate aheadangle $ Vector3 0.0 0.0 (1.0 :: GLfloat) callList $ ownheadDL popMatrix
What you need is matrixExcursion :: IO a -> IO a. matrixExcursion $ do GL.translate $ .... ... (I haven't checked the other functions you are using are all unchanged). Grüße, Wolfgang
Patrick Scheibe wrote:
At this time the situation of HOpenGL and ghc --enable-hopenGl is very confusing to me.
Sorry for the confusion. The current situation is as follows: * What you find on http://haskell.org/HOpenGL/ (versions 0.9 - 1.05) are basically snapshots from my private CVS repository. The API is more or less the same for all those versions. I do not intend to support these versions in the future, the work needed is simply too much. * The stuff in the fptools CVS repository and the source tar files and RPMs generated from it contain the new HOpenGL code base, offering a new API. It is under active development and almost finished, only NURBS and pixel-related things like texturing are missing. It should run on more platforms than the old stuff, including Linux, WinDoze, Mac OS X, OpenBSD, FreeBSD, and Solaris. Note that Hugs now uses the libraries from fptools, too, so the next Hugs release will have OpenGL/GLUT support, too. The transition to the fptools repository was not made randomly, it was made because I couldn't see a smooth transition: The new code doesn't require GreenCard (it's pure Haskell98 + FFI) and the API is now centered around the notion of state variables, just like the OpenGL/GLUT specs themselves.
I tried to install the new HOpenGL package from Sven. But the make install doesnt seem to work. When I tried to compile a simple example of the Redbook the linker stops because of undefiened references to some c-functions. If theres some time I post the exact error-message ..
It would be nice to see the transcript of the session plus config.log and config.status.
[...] The push and popMatrix functions dont seem to be there in future. What should I use instead of this? [...]
As Wolfgang has already pointed out, using matrixExcursion is the way to go. (BTW, I'm not very happy with this name, any suggestions are highly appreciated.) This highlights one of the design decisions for the new API: GL calls which come in pairs and are tightly coupled (like glBegin/glEnd, glNewList/glEndList, glPush/glPop, ...) are only available through a higher-order function. This ensures proper OpenGL operation, even in the presence of exceptions. You get some documentation when you have Haddock installed and do a "make html", but there is still a lot to be done. :-} Luckily, Sven Eric Panitz has written a fine tutorial, which is not yet complete, but already quite usable and contains *lots* of examples: http://www.tfh-berlin.de/~panitz/hopengl/ Apart from that, have a look at the examples in fptools/libraries/GLUT/examples. Cheers, S.
I do not really like the name 'matrixExcursion'. It is so technical a
name. Since quite often the code passed to a matrixExcursion is
in form of a do notation, I found the name locally quite appealing ,since
then your
code looks like:
locally = matrixExcursion
colorFigure n = do
locally $ do
currentColor $= Color4 1 0 0 1
translate$Vector3 0 0 (-n/2)
square n
locally $ do
currentColor $= Color4 0 1 0 1
translate$Vector3 0 0 (n/2)
square n
gruß
Sven Eric
On Tue, 07 Oct 2003 19:06:23 +0200, Sven Panne
Patrick Scheibe wrote:
[...] The push and popMatrix functions dont seem to be there in future. What should I use instead of this? [...]
As Wolfgang has already pointed out, using matrixExcursion is the way to go. (BTW, I'm not very happy with this name, any suggestions are highly appreciated.)
--
Sven Panne wrote:
(BTW, I'm not very happy with this name, any suggestions are highly appreciated.)
Sven Eric Panitz wrote:
I do not really like the name 'matrixExcursion'. It is so technical a name. Since quite often the code passed to a matrixExcursion is in form of a do notation, I found the name locally quite appealing [...]
Yes I don't like matrixExcursion either. But "locally" seems to general; the term "local" can mean too many things in a computer program. What about something like "saveMatrix"? While not being perfect, It fits with saveServerState and saveClientState, and it is easy to guess from the name that it has something to do with pushMatrix and popMatrix. Another remark: I would like "saveAttrib" and "saveClientAttrib" even better than save*State; While I agree that the save*State names are nicer by themselves, saveAttrib and saveClientAttrib are closer to the C "originals". I consider that very important. Cheers, Wolfgang
Based on the examples in the last few emails, would the name 'withLocalMatrix' work? (I'm thinking that drawing a parallel with the 'withX' functions in other libraries might be useful.) -- Alastair Reid www.haskell-consulting.com
Alle 16:20, mercoledì 8 ottobre 2003, Alastair Reid ha scritto:
Based on the examples in the last few emails, would the name 'withLocalMatrix' work?
(I'm thinking that drawing a parallel with the 'withX' functions in other libraries might be useful.)
I was just going to suggest withCurrentMatrix or withMatrix :) V.
On Wed, 2003-10-08 at 10:56, Nick Name wrote:
Alle 16:20, mercoledì 8 ottobre 2003, Alastair Reid ha scritto:
Based on the examples in the last few emails, would the name 'withLocalMatrix' work?
(I'm thinking that drawing a parallel with the 'withX' functions in other libraries might be useful.)
I was just going to suggest withCurrentMatrix or withMatrix :)
I don't like withCurrentMatrix ("with current" sounds like it should be a no-op). withLocalMatrix would be good; for a long, descriptive name, you could use whileRememberingCurrentMatrix (shorter versions might be whileRememberingMatrix or rememberingCurrentMatrix). Carl Witty
participants (7)
-
Alastair Reid -
Carl Witty -
Nick Name -
Patrick Scheibe -
Sven Eric Panitz -
Sven Panne -
Wolfgang Thaller