[Haskell] GLUT gears speed

[Wolfgang Jeltsch]

Am Montag, 16. Januar 2006 22:12 schrieb Sebastian Sylvan:
> On 1/16/06, Wolfgang Jeltsch <wolfgang at jeltsch.net> wrote:
> > Am Montag, 16. Januar 2006 15:16 schrieb Sebastian Sylvan:
> > > [...]
> >
> > Hello Sebastian,
> >
> > thank you for your answer.
> >
> > > As long as you don't do it naively there should be no problems. I.e.
> > > do not draw the terrain using the vertex-calls, but rather use
> > > vertex-arrays,
> >
> > Hmm, this will make it rather complex for my students since they have not
> > much experience with Haskell programming.  In addition, where can I find
> > documentation about Graphics.Rendering.OpenGL.GL.VertexArrays?
>
> I suppose here:
> http://www.haskell.org/ghc/docs/latest/html/libraries/OpenGL/
> Graphics-Rendering-OpenGL-GL-VertexArrays.html

Hmm, this is not much of a documentation.  No explanation of the types, 
functions, etc.

> But it should correspond fairly well to any general documentation on
> vertex arrays (www.opengl.org will surely have reference documentation
> somwhere).

Yes, the only explanation on the above page is a pointer to the corresponding 
section in the OpenGL specs.  I hope that the correspondence between the 
Haskell module and the chapter of the specs is rather tight.  After all, the 
Haskell module uses Haskell classes, Ptr values, etc.

> > > or (better) vertex buffer objects.
> >
> > What's this?
>
> It's a fairly recent addition meant to be used instead of vertex
> arrays in most cases. I'm not sure if HOpenGL supports them, but I
> believe it does.

At least from skimming the HOpenGL module list, I couldn't find anything which 
has to do something with "buffers".

> The main benefit as far as I can tell is that unlike vertex arrays the
> data does not need to be validated everytime it's sent to the graphics
> card (the implementation is prohibited from assuming that the data in
> a vertex array hasn't changed, so it must be validated every time it's
> referenced).
> VBOs are managed by the graphics driver to a larger extent, so can be
> optimized "behind the curtains".

Sounds interesting.

> [...]

> > > You may want to find a good terrain-rendering library rather than
> > > implementing it yourself.
> >
> > Is there one for Haskell?
>
> Not that I know of, but if you find one for C it shouldn't be too hard
> to create a binding...

Too time-consuming for me. :-(

> /S

/W