June 2009 - HOpenGL - Haskell.org

ANNOUNCE: Cal3D animation library
by Gregory D. Weber 27 Jun '09

27 Jun '09

The Cal3D for Haskell project provides a partial binding to the C++ Cal3D animation library. The project homepage is http://haskell.org/haskellwiki/Cal3d_animation There are three packages available on hackage: * cal3d-0.1 is a Haskell binding to the Cal3D library itself. * cal3d-opengl-0.1 adds a few functions for using Cal3D with OpenGL. * cal3d-examples-0.1 provides a simple example based on the Cally Demo. Cal3D is a C++ library for skeletal-based character animation. It is platform-independent and independent of any particular graphics API. In fact, it does not actually render the animation, but provides hooks that the graphics API (such as OpenGL) can use to do the actual drawing. (As far as I know, though, the only graphics API available for Haskell is OpenGL.) For more information about the (C++) Cal3D library, please see * Cal3D FAQ: http://cal3d.sourceforge.net/docs/api/html/cal3dfaq.html * Cal3D Homepage: http://home.gna.org/cal3d/ -- ___ ___ __ _ / _ \ / _ \| | | | Gregory D. Weber, Associate Professor / /_\// / | | | /\ | | Indiana University East / /_\\/ /__| | |/ \| | http://mypage.iu.edu/~gdweber/ \____/\_____/\___/\__/ Tel. (765) 973-8420; FAX (765) 973-8550

1 0

Re: [Haskell] ANNOUNCE: OpenGLRaw 1.0.0.0
by Tillmann Vogt 23 Jun '09

23 Jun '09

Sven Panne schrieb: > Am Donnerstag, 11. Juni 2009 19:23:17 schrieb Bryan O'Sullivan: >> [...] I think that "Graphics.Rendering." is clutter, and "OpenGL.GL." seems >> redundant to me. [...] > > I forgot to mention one thing here: "OpenGL.GL" is currently *not* redundant, > there is "OpenGL.GLU" in the OpenGL package, too. GL and GLU are separate > libraries, even living in separate DLLs/*.sos, having separate headers, etc., > so they should be kept separate in Haskell at some level, too. > > Nevertheless, with OpenGL 3.1 GLU is dead, Are you sure? glu is mainly for converting an arbitrary polygon into triangles. This is an art and so obviously wasn't put into hardware or driver. From a previous post I remember that tesselation was mentioned. But looking at some presentation slides from AMD/ATI I understand that tesselation in directx11 is using the following primitive patches: Triangles and Tri-patches, Quads and Quad Patches, Lines and Line Patches, see http://ati.amd.com/developer/gdc/2008/Tatarchuk-Tessellation_GDC08.pdf slide 31. I haven't found a lot of information in the OpenGL 3.1 Spec, so I assume they will do it similar to directx11. So, if glu is still needed, until I use a better algorithm in my library. > anyway, so in future versions there > will be no ".GL" part in the package names. > > Cheers, > S. > > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell

3 2

Re: [Haskell] ANNOUNCE: OpenGLRaw 1.0.0.0
by Sven Panne 17 Jun '09

17 Jun '09

Am Donnerstag, 11. Juni 2009 19:23:17 schrieb Bryan O'Sullivan: > Since this is a new package, is there any possibility that the naming could > be more economical? > > Graphics.Rendering.OpenGL.GL.CoordTrans is awfully long. > > I think that "Graphics.Rendering." is clutter, and "OpenGL.GL." seems > redundant to me. I'd very much like to encourage the idea that tremendously > long package names ought to be considered poor form. While I consider this a bit long, too, there are a few reasons why it was done this way. The OpenGLRaw package exports 1025 functions, 1673 tokens and 20 types, so one clearly needs some way of structuring this, the only question is how. You rarely import on such a fine-grained level, most of the time you simply use the rather short import Graphics.Rendering.OpenGL import, where you can even add "as GL" if you like for short explicit qualification later. Another example: If you explicitly only want to use pure, modern OpenGL 3.1 "the raw way", use: import Graphics.Rendering.OpenGL.Raw.Core31 If you additionally want to use the ARB_compatibility extension, use: import Graphics.Rendering.OpenGL.Raw.Core31 import Graphics.Rendering.OpenGL.Raw.ARB.Compatibility If you want the OpenGL 3.1 core plus all ARB extensions, use import Graphics.Rendering.OpenGL.Raw.Core31 import Graphics.Rendering.OpenGL.Raw.ARB And if you are very lazy, you can simply pull in the whole raw binding with import Graphics.Rendering.OpenGL.Raw This leaves the decision about the granularity of the import to the user of the package, which is a good thing IMHO. The ".Raw" part is necessary to distinguish between the raw and the nice interface, leaving the dot out or replacing it with "_" wouldn't really buy us much. One point here is debatable: Do we really need the ".Rendering" part in the package name or would simply "Graphics.OpenGL.Raw" be enough? We discussed the structure of the hierarchy when hierarchical packages were in their infancy, many years ago, and it was consensus then to distinguish between "Graphics.Rendering" and "Graphics.UI". I don't have very strong feelings about ".Rendering" and ".UI", and if the consensus nowadays is to remove it, I'll be happy to change this. But let's move the discussion about this to the libraries mailing list. A few final remarks: Leaving out "Graphics." completely would be a very bad idea, the naming hierarchy should reflect the underlying conceptual hierarchy. The only problem with hierarchies in general is that sometimes the position in it is not very clear. I have e.g. never fully understood why "Monad" and "Applicative" are below "Control", but "Foldable" is below "Data"... Cheers, S.

2 1

[bug] error in unmarshalMouseButton
by Claude Heiland-Allen 17 Jun '09

17 Jun '09

Hi, I'm developing a mouse-driven user interface using HOpenGL/GLUT. However, it sometimes crashes if I'm too clumsy on my laptop's trackpad: $ ./gulci gulci: unmarshalMouseButton: illegal value 5 $ ./gulci gulci: unmarshalMouseButton: illegal value 6 The offending code calls error: --8<-- unmarshalMouseButton :: CInt -> MouseButton unmarshalMouseButton x | x == glut_LEFT_BUTTON = LeftButton | x == glut_MIDDLE_BUTTON = MiddleButton | x == glut_RIGHT_BUTTON = RightButton | x == glut_WHEEL_UP = WheelUp | x == glut_WHEEL_DOWN = WheelDown | otherwise = error ("unmarshalMouseButton: illegal value " ++ show x) --8<-- http://www.haskell.org/ghc/dist/current/docs/libraries/GLUT/src/Graphics-UI… Suggested fix: modify the MouseButton type to have an additional constructor, eg: data MouseButton = ... | OtherMouseButton CInt and handle that case in the obvious way in the (un)marshal code (and suitably adjust any other code that pattern matches on MouseButton) BTW, I noticed I'm not the first to suffer from this crash issue, see for example #haskell IRC log from 2008-05-16. Claude -- http://claudiusmaximus.goto10.org

2 2

ANNOUNCE: OpenGLRaw 1.0.0.0
by Sven Panne 12 Jun '09

12 Jun '09

As a first step to make the OpenGL package easier to install, more modular and a bit more flexible, a low-level binding for OpenGL has been uploaded to Hackage. From OpenGLRaw's package description: ------------------------------------------------------------ OpenGLRaw is a raw Haskell binding for the OpenGL 3.1 graphics system and lots of OpenGL extensions. It is basically a 1:1 mapping of OpenGL's C API, intended as a basis for a nicer interface. OpenGLRaw offers access to all necessary functions, tokens and types plus a general facility for loading extension entries. The module hierarchy closely mirrors the naming structure of the OpenGL extensions, making it easy to find the right module to import. All API entries are loaded dynamically, so no special C header files are needed for building this package. If an API entry is not found at runtime, a userError is thrown. OpenGL is the industry's most widely used and supported 2D and 3D graphics application programming interface (API), incorporating a broad set of rendering, texture mapping, special effects, and other powerful visualization functions. For more information about OpenGL and its various extensions, please see http://www.opengl.org/ and http://www.opengl.org/registry/. ------------------------------------------------------------ Version 1.0.0.0 covers the OpenGL 3.1 core, all ARB extensions and all EXT extensions. Great care has been taken to introduce as few build dependencies as possible, so neither autoconf is required, nor any OpenGL headers. Future versions of the OpenGL package will basically be a convenience layer above this package, but you can always fall back to the raw binding if required. To get a taste for it, have a look at http://aedion.de/haskell/SmoothRaw.hs, which should look extremely familiar to anyone who has used OpenGL's C API. Any feedback is highly appreciated. Cheers, S.

2 2

Re: [Haskell] ANNOUNCE: OpenGLRaw 1.0.0.0
by Sven Panne 12 Jun '09

12 Jun '09

Am Donnerstag, 11. Juni 2009 19:23:17 schrieb Bryan O'Sullivan: > [...] I think that "Graphics.Rendering." is clutter, and "OpenGL.GL." seems > redundant to me. [...] I forgot to mention one thing here: "OpenGL.GL" is currently *not* redundant, there is "OpenGL.GLU" in the OpenGL package, too. GL and GLU are separate libraries, even living in separate DLLs/*.sos, having separate headers, etc., so they should be kept separate in Haskell at some level, too. Nevertheless, with OpenGL 3.1 GLU is dead, anyway, so in future versions there will be no ".GL" part in the package names. Cheers, S.

1 0

get Scale of the window in HOpenGL?
by yu yang 02 Jun '09

02 Jun '09

I want to move one object to the border of window, then go back to the start point. Does anyone one have an idea to implement it ? Thank you! ___________________________________________________________ 好玩贺卡等你发，邮箱贺卡全新上线！ http://card.mail.cn.yahoo.com/

3 2

Re: [HOpenGL] renderString not working in ghci
by Sven Panne 01 Jun '09

01 Jun '09

Am Montag, 1. Juni 2009 22:48:56 schrieb Duncan Coutts: > I don't know how the problem reported in that message is related to the > renderString problem (which I do not understand), but the behaviour you > see there is not terribly surprising. It's an artefact of the way > dynamic linking works and should not generally cause any problems. The word "generally" is a problem in itself. ;-) The main point is that GHCi'l dynamic linker behaves differently from the system's dynamic linker, so this is a very good reason to consider this a bug. It might not surface very often, but it is nevertheless a different behaviour a.k.a. bug. > The only case where it should make a difference is if code is assigning > any meaning to the address of functions, eg to compare them for > identity. In that case going via a thunk will make a difference. Is that > what freeglut is doing do you think? It is not about the address of functions, it is about data addresses. Here is the relevant snippet from GLUT's/freeglut's header file for non-Windows platforms: ---------------------------------------------------------------------- /* * I don't really know if it's a good idea... But here it goes: */ extern void* glutStrokeRoman; extern void* glutStrokeMonoRoman; extern void* glutBitmap9By15; ... /* * Those pointers will be used by following definitions: */ # define GLUT_STROKE_ROMAN ((void *) &glutStrokeRoman) # define GLUT_STROKE_MONO_ROMAN ((void *) &glutStrokeMonoRoman) # define GLUT_BITMAP_9_BY_15 ((void *) &glutBitmap9By15) ... ---------------------------------------------------------------------- As you can see, GLUT's fonts are represented by the addresses of global variables. This might not be the nicest way to do this, but it has to be done for binary compatibility reasons and there is *nothing* dubious about this. Note that e.g. we are very lucky that "errno" is a macro for a function call on all platforms for which -fPIC is relevant, otherwise we would have the same problem with it, too. The GLUT Haskell package uses a simple C wrapper around these macros: ---------------------------------------------------------------------- void* hs_GLUT_marshalBitmapFont(int fontID) { switch (fontID) { case 0 : return GLUT_BITMAP_8_BY_13; case 1 : return GLUT_BITMAP_9_BY_15; case 2 : return GLUT_BITMAP_TIMES_ROMAN_10; case 3 : return GLUT_BITMAP_TIMES_ROMAN_24; case 4 : return GLUT_BITMAP_HELVETICA_10; case 5 : return GLUT_BITMAP_HELVETICA_12; case 6 : return GLUT_BITMAP_HELVETICA_18; } return (void*)0; } ---------------------------------------------------------------------- For reasons explained in great length in the mail thread quoted, GHCi's linker doesn't link the wrapper correctly on some platforms when -fPIC is not used for its compilation. > I rather suspect it's freeglut doing something dubious with comparing > function pointers. The only one doing dubious things is GHCi's dynamic linker... ;-) > On most platforms -fPIC imposes some overhead and so it is only used > when it's advantageous or necessary. On most platforms code that will > live in a shared library should or must be compiled with -fPIC. x86-64 > is one of the few architectures where the overhead is relatively low. So my question is again: Why is -fPIC not the default for GHC on x86_64? If we don't want the overhead, that's OK (any benchmark numbers?), but then GHC's documentation should really contain a big, fat warning that GHCi's dynamic linker gets cases like the one above wrong. Cheers, S.

1 0

renderString not working in ghci
by Matthijs Kooijman 01 Jun '09

01 Jun '09

Hi all, I've been playing around with GLUT (latest version from hackage, on Debian) a bit yesterday and am having some troubles with renderString. It works fine when I compile a binary using ghc, but when running from ghci I get an error similar to the following (I don't have the actual error at hand atm). freeglut(<interactive>): font 0xsomething not found From looking at the freeglut code, it seems this means that the font pointer passed in does not match the address of any of the font variables in the library. I'm not completely sure how the linking works in ghci, but it appears that something goes wrong with dynamic linking? Is this a known problem, or does anyone have any pointers where to debug this? Gr. Matthijs (Please CC me, I'm not subscribed)

2 4