[Haskell] GLUT gears speed
Sven.Panne at aedion.de
Sat Feb 18 14:16:16 EST 2006
Am Montag, 16. Januar 2006 21:52 schrieb Wolfgang Jeltsch:
> Am Montag, 16. Januar 2006 15:16 schrieb Sebastian Sylvan:
> > or (better) vertex buffer objects.
> What's this?
The basic idea behind buffer objects is a general mechanism which allows the
driver to keep huge amounts of data on the extremely fast on-board memory of
graphics cards, potentially in an already preprocessed form. Currently two
kinds of data are standardised: Vertex arrays and indices into those arrays.
This is a rather cool mechanism, making some more specialised extensions like
compiled vertex arrays (=> Quake :-) superfluous.
> > Furthermore you should do some hierarchical culling on the terrain
> > (using, e.g. a quad-tree) to avoid drawing things which are not visible.
> Too complicated for the practical course. Doesn't OpenGL already do
> something like this?
OpenGL is intentionally designed as a *rendering* library, onto which
higher-level libraries (e.g. Inventor) can be layered. Of course OpenGL
throws away invisible primitives as fast as possible, but even this takes
some time, so higher-level libraries can make OpenGL's life much easier.
> > To summarize: Drawing vast terrains quickly has much more to do with
> > algorithmic cleverness rather than miniscule overheads from library
> > bindings.
> I did not refer to the overheads of the binding but to "the slowness of
> Haskell" (compared to C, of course ;-) ). [...]
I think this is one of the strengths of a Haskell binding for OpenGL: You can
concentrate on the fun part (i.e. clever rendering algorithms etc.) much more
easily than in C. Given the same amount of time, I imagine that one can
implement much more elaborate stuff than in C, so you can actually get better
More information about the Haskell