[Haskell-cafe] Decoupling OpenAL/ALUT packages from OpenGL
Sven.Panne at aedion.de
Sun May 3 06:44:04 EDT 2009
Am Sonntag, 3. Mai 2009 00:56:00 schrieb Tillmann Vogt:
> 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 ? [...]
Thanks for all the suggestions so far, a few remarks from my side (I just
picked the last mail for the reply, no strong reason for this...):
"Data.GraphicsObjects" is a bit misleading, because OpenAL's Buffers and
Sources are instances, too, and they have nothing to do with graphics.
Instances of ObjectName are just opaque resources from an external API, which
you have to allocate and deallocate explicitly.
> I think it would be nice to have data types and functions for dot
> produkt, scalar product, norms, ...
> together with HOpenGL types.
I fear that this might open a can of worms and could lead to even longer
discussions than the ones about a collection framework. The design space for a
vector math package is quite large, and I fear that e.g. a mathematician
trying to implement some linear algebra package has vastly different
requirements than somebody trying to implement the n-th incarnation of the
Quake engine. Some points to consider:
* Should the components of vectors etc. be strict? In OpenGL they are, and
Data.Complex is similar in this respect. In my experience non-strict
components lead to space leaks too easily, and I guess this is the rationale
behind Complex, too. But non-strict components have some benefits, too, of
course, especially if you do symbolic computation.
* Should we abstract over the number of dimension of vectors, etc.? If yes,
how strong can our compile-time type checking be?
* If we really make this a more general vector math package, things like
colors etc. should probably stay in the OpenGL package. But there are a few
other packages needing color data types, too...
* If the package is not general enough, it might be a bad idea to steal
names/hierarchy locations which *are* general.
Nevertheless, I'd be happy to see some proposals for a sensible, compact
vector math package. Probably we can fulfill most of the common use cases with
And one word about lumping the 3 packages together: Any function, module, and
package should have *one* clearly defined task, this is crucial for every SW
design. I would have a hard time explaining what this "super package" is all
about, even if we throw only 2 of the 3 packages together. Personally I feel
that this is a strong argument for 3 separate packages.
> (I know that glu has tesselation). [...]
But GLU is basically dead with OpenGL 3.x. :-)
More information about the Haskell-Cafe