[fluxus] interactivity issues

[Claude Heiland-Allen]

nik gaffney wrote:
>>> the example script works the other way round, checks if the mouse is over
>>> an object and only does something if it is. 
>> Mmm, but this only works for trivial "somethings to do" - it's hard to
>> do anything complex if you can't find (by comparison operations) which
>> 'concept' in the scheme world the object you clicked on corresponds to.
> 
> hmmm.. how about if the trivial something was to check an id (stored as a number
> in an alist, when the 'actor' is created for example) which if sucessful, calls
> a single function, using the id. 

I'm not sure I follow - how can you look up in an alist when
eq/eqv/equal are not defined on the primitives?

But!  Maybe I can use a pdata float as a temporary workaround?

What I want to do, and have mostly working so far is basically have a
main loop...

(define (each-frame) (update universe) (render universe))
(every-frame (each-frame))

...where universe is a collection of 'actors', so (update universe)
would be something like (for-each (lambda (x) (update x)) universe) and
(render universe) would be similar.  Then any actors that need to
respond to user input would check a cached (mouse-over) to see if they
have been hit.

Ah, now I see where you are getting at with your paragraph (belatedly),
seems to me to be too complex - spreading logic across different parts
of the program (having the program do things to the actors) instead of
in nice little individual capsules (which are my 'actors' - I did mean
it when I said they were "semi-autonomous", doing things to themselves).


> to avoid further complexity related to events,
> perhaps store any state in whatever data strucutre you are using for each
> instance of the actors.

At the moment each of my actors has an alist, it seems to work well
(generally the number of named 'instance member' variables is small so
it doesn't cost too much to search for them).


>  
> nzk



Claude