May 2011 - HOpenGL - Haskell.org

Render fonts in HopenGL
by er9999 25 Jul '11

25 Jul '11

Hello, Can anyone give me an example for fonts rendering? I tried to use FTGL library, but it is too complicated on Windows(compile). Is it possible to do it in a simple way? I need more than the given example in red book(Font.hs), something like outline font. By the way, I am new in OpenGL and Haskell, so the real exmaple should be the best. Thanks!

4 6

Hello HOpenGL
by Alexander Göransson 16 Jun '11

16 Jun '11

Hi! I'm the person who will be working on the libraries this summer. I've been very busy with school lately (and still am), but I've written a blog post with some thoughts on the project: http://unsafeperformpastorn.blogspot.com/ I will keep posting stuff there, on a weekly basis, throughout the summer. // Alexander

6 11

Re: [HOpenGL] Haskell or C First?
by Danny Charbonneau 29 May '11

29 May '11

I want to make a CAD application. On Sun, May 29, 2011 at 12:55 AM, Danny Charbonneau < novo.charbonneau75(a)gmail.com> wrote: > I want to make a CAD application. > > > On Sun, May 29, 2011 at 12:37 AM, Isaac Dupree < > ml(a)isaac.cedarswampstudios.org> wrote: > >> The Haskell OpenGL binding is one of the best OpenGL bindings around... I >> find it slightly nicer to use than the native C bindings, and with no loss >> of power (it's a pretty direct mapping to OpenGL; just a few things like >> glBegin()/glEnd() are made more Haskell-idiomatic IIRC). >> >> What kind of application though? That probably makes more difference in >> this case than the OpenGL. >> >> -Isaac >> >> >> On 05/29/11 00:57, Danny Charbonneau wrote: >> >>> I have an ambition to eventually create a large graphics application >>> dependent on OpenGL I don't have much experience with C or Haskell, >>> though I >>> feel somewhat comfortable around C code. Should I devote some time to >>> learning C and going through the red book or the opengl bible, or is it >>> possible that I could learn Haskell and have no trouble creating and >>> manipulating objects with the bindings offered? >>> >>> >>> >>> >>> _______________________________________________ >>> HOpenGL mailing list >>> HOpenGL(a)haskell.org >>> http://www.haskell.org/mailman/listinfo/hopengl >>> >> >> >> _______________________________________________ >> HOpenGL mailing list >> HOpenGL(a)haskell.org >> http://www.haskell.org/mailman/listinfo/hopengl >> > >

2 1

Haskell or C First?
by Danny Charbonneau 29 May '11

29 May '11

I have an ambition to eventually create a large graphics application dependent on OpenGL I don't have much experience with C or Haskell, though I feel somewhat comfortable around C code. Should I devote some time to learning C and going through the red book or the opengl bible, or is it possible that I could learn Haskell and have no trouble creating and manipulating objects with the bindings offered?

2 1

New programmer => some comments/suggestions
by L Corbijn 07 May '11

07 May '11

Hi everyone, I was wondering if anyone is working on improving the OpenGL package. As the git repository [1] on github looks rather quiet, beside my (Laar, not my real name) casual editing. In that process of adding extra functions to improve the library to some higher version of OpenGL I ran into some structural inconveniences. But as I'm not that experienced with Haskell nor with collaborating in open source projects. The major problem in my opinion is the boat load of deprecated functions and objects that make finding and having an overview of the code rather difficult. This is not helped by the fact that there are a lot of files that could be marked as deprecated. Therefore I think that something more serious should be done than only adding deprecated pragma's as Jason Dagit suggests in [2]. I think it should improve the overview of the code if all deprecated functions/code/etc. are move to a different namespace, say ...OpenGL.GL.Deprecated. This would help a lot as with coding new stuff the files would be quite a bit smaller as you wouldn't see the deprecated stuff. Though this will probably be quite a hard break with older code. Though quite a lot of code to refactor I think it would lead to a better structured project that is easier to maintain. Furthermore in it's current state importing ...OpenGL.GL does import everything, whether it's deprecated, usefull or even only usable for higher versions of OpenGL-contexts than you use. Although the exported functions/Types wouldn't lead to clashes it would be nice to have modules that only export the stuff that is usable for a certain OpenGL-context (e.g. importing ...Core31 or ...Core31Compatibility). This would lead to a compile error when using unsupported functions, which is a lot more pleasant than having to debug why code doesn't work (talking from experience). And if the future brings better auto-complete for Haskell it might lead to better suggestions (all the unused stuff out). Greetings, L Corbijn [1] https://github.com/dagit/OpenGL/network [2] http://www.haskell.org/pipermail/hopengl/2011-April/001002.html

2 3