- HOpenGL - Haskell.org

"(±¤°í)´ëÇÑ¹Î±¹-ÀÎÅÍ³ÝÀÇ ÁöÃàÀ» Èçµé°ÔµÉ ¸Å¿ì ³î¶ó¿î»ç½Ç ÇÑ°¡Áö¸¦ ÀüÇÕ´Ï´Ù.@"
by ��ģ�� 23 Nov '03

23 Nov '03

1 0

ANNOUNCE: HOpenGL 1.05 released
by Sven Panne 15 Nov '03

15 Nov '03

HOpenGL, a Haskell binding for OpenGL and GLUT version 1.05 I am pleased to announce the sixteenth release of the Haskell binding for GL 1.2.1 / GLU 1.3 / GLUT 3.7beta. It offers easy access to *the* industrial strength 3D graphics API and a GUI toolkit. More details about HOpenGL can be found at http://haskell.org/HOpenGL/ This is a compatibility/bug fix release with the following changes: * Fixed a memory allocation bug for GL state queries. * Works with new hierarchical libraries now. * Always use the correct calling convention. * The build system works with recent versions of GHC and GreenCard now. As always, feedback and/or patches are highly welcome. A note for people on the bleeding edge: If you are interested in the future of HOpenGL and its new API, you might wish to build GHC from CVS, configuring with `--enable-hopengl'. This will result in a GHC with two additional packages `OpenGL' and `GLUT'. The APIs have improved quite a bit and are now modeled around the notion of state variables. Furthermore, OpenGL's extension mechanism is now supported on all major platforms, including Linux, Windows and Mac OS X. Note that this is still work in progress, but early feedback would be very useful. Have fun! Sven

3 4

Re: [HOpenGL] WinXP, ghc-6.0.1, HOpenGL-1.05 .. problems
by C.Reinke 15 Nov '03

15 Nov '03

- added GL/glut.h - applied HOpenGL-1.04 install patch - replaced evil hack with "ghc --print-libdir" - configure; make depend; make install again goes through, but this time there is a Graphics.UI.Glut (under HOpenGL, not in the main Graphics, btw). so far so good, but trying to compile the examples in my old FunWorld July snapshot doesn't get very far at all: Compiling Main ( Boids.hs, obj/Boids.o ) Linking ... c:/ghc/ghc-6.0.1/libHOpenGL.a(GL_Marshal__1.o)(.text+0x28):ghc2444.hc: undefined reference to `__stginit_CString_' c:/ghc/ghc-6.0.1/libHOpenGL.a(GL_Texturing__1.o)(.text+0x5a):ghc2844.hc: undefin ed reference to `__stginit_List_' c:/ghc/ghc-6.0.1/libHOpenGL.a(GL_BasicTypes__1.o)(.text+0x1e):ghc2944.hc: undefi ned reference to `__stginit_Bits_' make: *** [Boids] Error 1 Further suggestions?-) Claus

2 2

Debian&HOpenGL, undefined symbol: glPixelStorei
by Ville Tirronen 15 Nov '03

15 Nov '03

Hi, I'm trying to get HOpenGL working on a unstable debian box. Since there were suitable packages available (ghc6, ghc6-hopengl) I installed those. After trying to "ghci6 -package GLUT" I get the following error message: Loading package OpenGL ... ghc-6.0.1: can't load .so/.DLL for: GLU (/usr/ X11R6/lib/libGLU.so: undefined symbol: glPixelStorei) With packages for ghc5 this seems to work but I cannot get any example compiled. The result for "ghc5 --make -package GLUT Planet.hs" is: ghc-5.04.3: can't find module `GL' (while processing "Planet.hs") Any help appreciated, Ville Tirronen

4 9

WinXP, ghc-6.0.1, HOpenGL-1.05 .. problems
by C.Reinke 13 Nov '03

13 Nov '03

Having upgraded to ghc-6.0.1 since I last used HOpenGL, I once again embarked on re-installing.. - ghc-6.0.1 seems to lack GL/glut.h? copied that in.. - tons of warnings (most but not all about deprecation) - no errors stopping configure/make depend/make/make install.. there seem to be hidden errors, though, starting in make depend right after the green-card calls: cut: /cygdrive/c/ghc/ghc-6.0.1/bin/ghc: No such file or directory (`which ghc` on cygwin delivers the filename without .exe, but even if I add the suffix for cut, and try it out on the commandline, the filter doesn't find anything; I've got a feeling of deja vu on this one, btw..) - no Graphics.UI.GLUT in sight after install? I remember that ghc-5.04.2 with HOpenGL-1.04 and the usual patches worked without (visible) problems, so before I look for what is going wrong on my system, I just wanted to check whether the Subject-configuration is known to work on other people's systems? Cheers, Claus PS. Perhaps I shouldn't be looking at these old versions anyway, but this is still what HOpenGL users are most likely to have. Are there any plans for when the cvs-version will take over? And do I have a chance of building the cvs-version of HOpenGL without building any of the other stuff in fptools (ie. can I just use ghc-6.0.1 binary release to build it)?

3 3

Size and position of subwindows
by Patrick Scheibe 13 Nov '03

13 Nov '03

Hi there. I'm modifying an old API-Style program and want to compile it with the new OpenGL-Haskell-API. In the past one defined a subwindow in the following way: uniW<- createSubWindow mainW (WindowPosition space space) (WindowSize 600 400) Now the parameters are away. You define a normal window by setting the statevars and create one. initialWindowSize $= Size 100 100 initialWindowPosition $= Position 100 100 createWindow progName Whats about subwindows? What have to be done if you want to create a subwindow at position 50,50 relatively to mainwindow with a specific size? And how does the reshaping of subwindows work? If you resize your mainwindow, the mainreshape is called with the new size. When and with what size is the subwindow reshapecallback-func called by OpenGL? Or am I forced to call it by myself in the mainreshape? Greetings Patrick

2 1

problem with displayCallback and Double buffering
by Marc A. Ziegert 05 Nov '03

05 Nov '03

does anyone else have this problem? i want to use double buffering, but swapBuffers does not seem to work. to set the active window to... the active window (i think that has to work!) does not work, too. but i am able to compile and run glut examples with double buffering written in c. coeus@titan ~/Documents/haskell/hopengl/problem $ ghc -package GLUT -package OpenGL first.hs -lglut coeus@titan ~/Documents/haskell/hopengl/problem $ ./a.out displayModePossible? ...True begin swapBuffers

3 4

Confused about normals
by Patrick Scheibe 14 Oct '03

14 Oct '03

First I want to thank Sven for solving the problem with the missing normals. But now I am a little bit confused. I'm sure to heard about that if you specify the vertexes of a polygon (with glBegin GL_POLYGON in c) counterclockwise then the normalvector is set automatically. That means if you look at a plane the normal vector points to you. Is'nt that true? My example problem seems to show that this is definitly not true. So if I want to use light (and that will be very often) and I have to specify these vectors by myself then I can't use the renderPrimitive Polygon or Quad in situ because the calculation of a normal vector of a polygon isnt that trivial. The simplest way I see is to reduce this calculation to a normal vector calculation of a triangle. So I'm forced to define a new function makePoly taking a list of Points, calculating the normal and draw a polygon with this points. Otherwise I have to write down some points more then one time, the first time in the makenormal-function and in the secont at the render call. 1. Is this the way? 2. Where is it used that normals aren't right-angeled to the polygon-plan? 3. Exists there some higher-level function. With best regards Patrick

3 2

light sources.
by Patrick Scheibe 09 Oct '03

09 Oct '03

Hi everybody. I have problems to get a fixed light source. The light seems to rotate together with my model. Are there anywhere a few examples (these under GLUT/examples/.... are not so helpful) where I can have a look on other peoples work? Greetings Patrick

3 6

API names [was: ghc-6.0.1 and OpenGL enabled]
by Sven Panne 09 Oct '03

09 Oct '03

Thanks for all your replies, naming is obviously still one of the hottest topics in CS... Here are my thoughts: "locally" is (as already mentioned) too general, and "withFoo" is traditionally used for functions with a signature of the form: withFoo :: Foo -> ... But the current matrix is implicit, so this would not be a good choice for the combination of glPushMatrix/glPopMatrix. We are basically left with: saveFoo might not give a hint that a Foo is restored rememberingFoo same comment as above applies preservingFoo sounds good to me, but might be a bit long The current story for the combined GL calls is: glBegin/glEnd renderPrimitive glNewList/glEndList defineList glPushName/glPopName pushName glPushMatrix/glPopMatrix matrixExcursion glPushAttrib/glPopAttrib saveServerState glPushClientAttrib/glPopClientAttrib saveClientState The first two sound right to me, the third is actually a "withFoo", and the last three should be named in a consistent way. Combining your proposals I suggest: glBegin/glEnd renderPrimitive glNewList/glEndList defineList glPushName/glPopName withName glPushMatrix/glPopMatrix preservingMatrix glPushAttrib/glPopAttrib preservingAttrib glPushClientAttrib/glPopClientAttrib preservingClientAttrib Does this sound OK, especially for the native speakers on this list? Cheers, S.

2 2