May 2009 - HOpenGL - Haskell.org

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

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

glGetBufferParameteriv
by David Duke 26 May '09

26 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 13 May '09

13 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 10 May '09

10 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 07 May '09

07 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

Re: [Haskell-cafe] Decoupling OpenAL/ALUT packages from OpenGL
by Tillmann Vogt 03 May '09

03 May '09

Sven Panne schrieb: > > * a tiny "ObjectName" package, consisting only of OpenGL's ObjectName class > (In "Data.ObjectName"? I'm not very sure about a good place in the hierarchy > here.) How about Data.GraphicsObjects ? > > * a package containing most of the data types/newtypes in OpenGL's > VertexSpec module (Vertex{2,3,4}, Color{3,4}, etc.) plus instances for the > base classes like Eq, Ord, Show, etc. I really don't know a good name for this > package and what a good place in the hierarchy would be (probably something > like "Data.Foo", but what is Foo?) Now that you mention it. I just looked through haskell hierachical libraries and there seems to be no standard data types for vector math. Am I getting something wrong or is every library that is using linear algebra stuff using its own data types? So if I use a numeric library for matrices inside HOpenGL I have to convert around? I think it would be nice to have data types and functions for dot produkt, scalar product, norms, ... together with HOpenGL types. Currently I am trying to embed a triangulation library from a ten year old diploma thesis (http://www.dinkla.net/fp/cglib.html) in my libary (I know that glu has tesselation). The author has developed a quite big and abstract type structure for all sorts of computer graphics algorithms and I didn't wanted to copy this into my library just for triangulation. But it is reasonable. It could be combined with HOpenGL types to maybe Data.VectorMath or Data.LinearAlgebra . I would favour the second. > > The point is: The first two package would be very small. Would this be OK? > Does anybody see other alternatives? What would be good names for those > packages and where in the naming hierarchy should they really go? > > Cheers, > S. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe

4 4

abstract linear algebra interface (was: Decoupling OpenAL/ALUT packages from OpenGL)
by Balazs Komuves 03 May '09

03 May '09

> These libraries are different in the way they store data and in the > interface. vectors-space is abstract, while your library offers an easier > interface. For example vector-space defines an additive group and an affine > space while you have a function translate3x. No, I too have an additive group (well, it's called AbelianGroup, not AdditiveGroup); translate3 and the like are just utility functions, in a separate module. But yes, I see now that this part of the vector-space interface is actually not that far from mine (though the linear maps part is very different). I think the best would be to have one abstract library. Then hmatrix imports > this library and overloads the functions. > Here are some random questions to think about, regarding a general abstract interface: - do you want to use type families? It's not really portable - what about type inference? The more abstract the interface, the more type annotations the user have to write (for example, with the current OpenGL binding you cannot simply write (Vertex3 1 0 0), which is somewhat annoying). - vectors are bimodules over both scalars and matrices. How would you encode this? If you want to go with the abstract way, you would want modules over rings. But that can be problematic. - are there performance costs associated with the abstraction? - the more concrete the types, the more operations and/or more efficient algorithms are possible. It's pretty hard to encode things like `algorithms working with matrices over principal ideal domains' with the Haskell type system. - what about dense/sparse matrices? How would the interface handle the fact that you would want to have different realizations of the same abstract type in the same program? - clearly one cannot expect a general interface to cover all the possible use cases. How to make it extensible? etc etc. Of course, prove me wrong if you can! I'm not at all against abstraction, just being pragmatic here. Balazs

1 0