[plt-scheme] FrTime implementation

On Tue, 2008-01-08 at 12:01 -0500, Gregory Cooper wrote:
> Hi Dave,
> 
> > Sorry for the delay, I seem to be trying to do too many things at once...
> 
> No worries.  ;-)  However, did you get my last message (written on
> Dec. 9 and copied to the plt-scheme list), in which I described a
> different implementation strategy?  I'd be happy to resend and/or
> elaborate on it, and I would strongly recommend taking that approach,
> which doesn't use any lifting.

Yes, I'm looking at that - I just wanted to make sure I was getting the
animation.ss way straight in my head first. Part of the reason this is
taking me so long is because it's all completely new to me (and the
reason I'm interested too :)

> > Firstly, I still seem to be getting the case where both time behavours are
> > expressed at the same rate - i.e. in the example below the action given
> > the seconds is called as many times as the milliseconds one, implying that
> > my list is not created properly.
> 
> This is what it means to lift over a list.  The A and B change at
> different frequencies, but their "union" changes whenever either of
> them changes.
> 
> If you're rendering a scene, it's easiest to start from an empty
> buffer and draw everything.  Otherwise, you'd need somehow to "undraw"
> just the B and redraw it in its new state.  Sorry if you expected it
> to do something more clever.  :-)

Gotcha. That's fine.

For immediate mode drawing this is quite simple to implement, it'll be
very like animation.ss, updating every frame.

The big deal for me is that re-specifying everything every frame using
immediate mode primitives is going to be far too slow for anything other
than the simplest of scenes. 

The other way to use primitives in fluxus is using a retained mode where
the redrawing of objects is taken care of inside the game engine where
it can be optimised for sending to the GPU. This way scripts only have
to update things when they need to - inherently stateful, but required
for bigger models and more complex operations.

None of this is much to do with frtime, but I hope that I can do some
sort of simple dependency checking to hide this statefulness away. e.g.
I could require the user to name objects so I can reuse the vertex data
over multiple frames, and only update transforms.

Thanks a lot for your help. I'll probably have more questions soon :)

cheers,

dave