- HOpenGL - Haskell.org

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 02 Jun '09

02 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 02 Jun '09

02 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

glGetBufferParameteriv
by David Duke 27 May '09

27 May '09

Does HOpenGL 2.2.3.0 have a binding for glGetBufferParameteriv, or at least an interface that provides the same functionality, in particular querying the size of a vertex buffer object? I haven't been able to locate something suitable through the index, but may be missing a combination. [By way of explanation, I'm currently running into a segmentation fault with a program that attempts to use a "large" vertex buffer object, ~500MB. Its likely the bufferData request exceeds resources, but I'm trying to confirm this, and the usual method seems to be calling glGetBufferParameteriv with GL_BUFFER_SIZE as an arg. If there is another way of checking vertex buffer allocation, that would also be useful to know ...]. thanks, David -- Dr. David Duke E: djd(a)comp.leeds.ac.uk School of Computing W: www.comp.leeds.ac.uk/djd/ University of Leeds T: +44 113 3436800 Leeds, LS2 9JT, U.K.

2 1

Re: [Haskell-cafe] Decoupling OpenAL/ALUT packages from OpenGL
by Sven Panne 16 May '09

16 May '09

Am Montag, 11. Mai 2009 12:04:07 schrieb Neil Brown: > [...] So possible additions to your type-class list are Foldable and maybe > Traversable (no harm, although I'd have to reach further for an example > for this). I guess the tricky decision might be whether to provide a > Num instance (again, probably more suitable for Vector2)? [...] OK, I've added a bunch of instances for all vertex attribute types in the OpenGL 2.2.3.0 package. Let me know if there are standard classes for which you would like to see instances, too. I've deliberately omitted instances for Num, because they are not correct from a mathematical point of view: You can't e.g. add two points (only a point and a vector), the difference between two points is not a point (it's a vector), etc. Cheers, S.

1 0

ANNOUNCE: OpenGL 2.2.3.0
by Sven Panne 16 May '09

16 May '09

A new version of the OpenGL package has bee uploaded to Hackage. This is a feature release, containing the following changes and additions: * Added support for GL_ARB_copy_buffer, GL_ARB_depth_buffer_float, GL_ARB_half_float_pixel, GL_ARB_texture_rectangle, GL_EXT_packed_float and GL_EXT_texture_shared_exponent extensions. * Added missing parts of GL_ARB_vertex_shader extension. * Announce that we support MESA_ycbcr_texture and APPLE_ycbcr_422 extensions. * Improved generic vertex attribute array API. * Added support for unsigned integral uniforms. * Added more GLSL type tokens. * Added missing query for texture size limits. * Include missing aclocal.m4 and README in source distribution and removed unused Makefiles and prologue.txt. * Added 2 hacks to determine the Haskell equivalents of GLchar/GLintptr/GLsizeiptr with ancient GL headers. * Added Vector1, Vector4 and Vertex1 data types for orthogonality. * Added Functor, Applicative, Foldable , Traversable, Typeable and Typeable1 instances for all vertex attributes plus all possible derivable instances. Cheers, S.

1 0

Texture Rectangle support
by Jeff Heard 14 May '09

14 May '09

I see it in there, but i get a ToDo: error. Is it entirely unsupported, or is there a workaround that doesn't involve making a nearest-power-of-two texture?

3 4

Re: [Haskell-cafe] Decoupling OpenAL/ALUT packages from OpenGL
by Sven Panne 11 May '09

11 May '09

Am Montag, 4. Mai 2009 13:33:33 schrieb David Duke: > Decoupling basic primitives for geometric modelling from OpenGL would be > useful. [...] > Even just data constructors and instances of these within Functor and > Applicative are a useful starting point. [...] I've taken a closer look at the available packages for vector math/linear algebra. They differ in a lot of respects, starting from their representations of vectors and matrices, use of the type system and its extensions, strictness, structure of their type classes, etc. This leads me to the conclusion that I should only lift the data types for vectors and matrices out of the OpenGL package, including only instances for standard type classes like Eq, Ord, Functor, etc. This means that the new package will *not* include type classes for things like scalars, vector spaces, etc. These can be defined by the other packages in their own "type class language". I really fail to see a common ground in this respect, even for basic things: Keeping things H98-compliant is a must for me, so putting things like fundeps or associated types in this new package is a no-go for me. Nevertheless, having a common set of (strict) data types for vector math will probably be very useful, even if it won't fulfill everybody's needs. What standard instances should be defined for those vectors and matrices? Things coming to mind are Eq, Ord, Show, Storable, Typeable1, Functor and Applicative. Have I missed some type classes? Regarding Functor/Applicative: The obvious instances for e.g. a 2-dimensional vertex are: data Vertex2 a = Vertex2 a a instance Functor Vertex2 where fmap f (Vertex2 x y) = Vertex2 (f x) (f y) instance Applicative Vertex2 where pure a = Vertex2 a a Vertex2 f g <*> Vertex2 x y = Vertex2 (f x) (g y) They fulfill all required laws, but are these the only possible instances? If not, are they at least the most "canonical" ones in a given sense? And finally: Does somebody have a real-world example where the Applicative instance is useful? Usages of the Functor instance are much more obvious for me. Cheers, S.

2 1

hello
by u5h 08 May '09

08 May '09

I feel a little bad spamming the list with this, but the number of people I've met who know how to work Haskell/OpenGL is about zero. I'm trying to find some sort of excellent guide to Haskell/OpenGL, if one is indeed written, to help me fill out an idea for a MMO??? that's been lingering in my head for a while - also, any excellent Haskell coders willing to assist with an open source, modular online game with amazing visuals and whatnot may as well contact me, right? I will probably receive replies telling me to do this in another language or something - but that's no fun, is it? The mathematical versatility of Haskell along with the ridiculous conciseness make it ideal for this project, even if I have to use some strange FRP approach. rjq(a)gmx.com

6 5