Hi,
I am not sure what you're trying to build but in most cases
Director's
precision is good enough. Basically the less scripts need to
be executed
and the less graphics need to be drawn, the higher the frame
rate and
the higher is the 'time resolution'.
How many timeout events per second do you need to generate
max? If you
really want to generate 1000 events per second then I would
advice you
to try something else than Director. If you want to generate
(let's say)
less than 150 events per second then Director is an option.
For example I did an interactive video installation where I
jumped and
looped in a video. The video had to keep sync with a
(separate)
soundtrack. The timing was controlled by director and it
worked perfect.
These kind of things Director can do very well.
> There are a couple of things you should note about
timing in
> Director. First of all, timeout objects are *not*
> interruption events. This means that they will not
always
> occur exactly when they should, just as soon after as
the
> Director engine is able to. This means that if a
timeout
> event occurs just as the screen is being updated
between
> frames, or during some other 'hard' engine operation,
you're
> out of luck. Only timeouts that occur while Lingo is
> executing will occur exactly when expected.
This is true. When you use the timeout objects from Director
is possible
that you miss a 'beat' (timeout event) while Director is
busy
calculating something. You can overcome this problem by
writing your own
custom timeout object and do not use Director's timeout
objects. That is
what I did for my video installation. When you miss a beat
then your
custom timeout object can 'catch up' making sure that you
never miss and
skip a beat. For example when you want to generate 100 bps
and you use
the catch up method then you are sure that you always get
100 beats.
When you do something with music then it is essential that
in all cases
100 beats are being generated and not sometimes 99. A beat
may be a few
milliseconds late but that offset will be compensated during
the next
beat.
The trick is that you do not do your calculations using
delta time
between the last beat and the current beat but the delta
time between
the very first beat and the current beat. In practise a beat
can be a
fraction of time too late but your program will know exactly
how much
time has passed and next beat can be in sync again.
I don't know whether this catch up method is of any use for
your
application.
Good luck.
Marco.
_______________________________________________
dirGames-L mailing list - dirGames-L nuttybar.drama.uga.edu
http://nuttybar.drama.uga.edu/mailman/listinfo/dirgames
-l
|