[HOpenGL] GL utilities, toolkits, and questions..

[C.Reinke]

> In the last weeks I've been re-structuring FunGEn completely (that's why it
> is taking so long for version 0.2 to be released). I read Mark's CGL (Clean
> Game Library) thesis and found a lot of useful information and ideas. The
> main objective is to make FunGEn a engine that deals much more with
> worlds/leves/objects SPECIFICATIONS rather than programming all the stuff in
> a IMPERATIVE way (actually, its first version had a little bit of it).
> 
> BTW, I've got no FunGEn feedback at all (apart from Sven's notes just after
> releasing)... :(

Sorry, I booked it as "great, but not down my alley" - didn't
reckon that a game engine would build on a kind of scene graph 
as well, even if in 2d.

How do you deal with animating the scene graph? The combination
of declarative descriptions of scene graphs, animation, and
reactivity were just what Fran was designed for, but it has
traditionally posed some problems in efficient implementation.
I think those have their source in unfortunate aspects of Fran's
design which I'm currently trying to overcome. 

Guess I'll have to take a closer look at your stuff soon, but
from your FunGEn 0.1 example at 

  http://www.cin.ufpe.br/~haskell/fungen/example.html

it seems you've got separate data structures describing the game
resources, the collections of game objects and the possible inputs
(the later bundled with their callbacks).  The timing functionality
looks like a thin wrapper around the two GLUT timing callbacks?
The game object actions are then written as monadic actions with
easy access to other objects' properties. 

If that summary is not too far off, FunGEn 0.1 is still a mixture
of declarative and imperative descriptions. Will that change with
FunGEn 0.2? Game hackers might welcome the familiar style (as long
as noone tells them they'd be using monads;-).

Cheers,
Claus