>>b) Or you want the timer to reset on exitFrame. In this case you
>>would not get a timer - you'd get something that stutters every
>>exitFrame.
>
>I'm not sure of having well understood this second case you posed
>as a distinction.
By 'resetting' I meant something like (Alpha):
'Make the timeOutObject output its Handler Call Now and make it count
from 0 up to its timeoutObject.period (as if it was just created)'.
as opposed to 'unmuting' which would just (Beta):
'Let the timeOutObject output its Handler Call at the next occurance
of a timeOut, which might be anything from 0 ms to
timeOutObject.period'.
I think its the former you want.
>I seem a timer can't be never reset, whether you was meaning that
>the internal time count is resettable to zero. Just from its birth a
>timer shows an initial time value that is related with the system time.
>But I guess you referred to a reset timer as to a forgotten one
>and not to a particular value of its internal time.
>If so, I'd agree with you. But, from the point of view of an
>object that is getting events from it, I can't see the difference:
>the object would hear as stuttering a timer that periodically resets.
>Though also a periodically muted timer stutters, doesn't it?
in case of Beta it will not stutter, but it will omitt a number of
handler calls. When unmuted it starts outputting handler calls again,
at the exact moment of:
n*timeOutObject.period, where n is the number of omitted calls; (the
time since muting, in milliseconds)/ timeOutObject.period.
As I realize what you want to use it for, I don't think case Beta is
interesting for you. The actual pace-keeping is not important, you
rather want to output a certain number of handler calls very rapidly.
For me, the pace-keeping is the main use for to-objs, e.g. in
sequencing applications for music or asynchronous ftp and www stuff.
>Working e.g. with multiple collisions I found that the FPS decreases
>dramatically when the program is busy in long repeat loops.
>(Some people use to move part of the code to the idle event handler).
>A fact is that FPS seems decreasing a lot cause more of the
>loop itself than for the amount of code contained in a loop cycle.
Repeat loops are inefficient in any language, but maybe even more so
in Lingo. Try to unfold them whenever possible ( = when you know the
number of repeats at the moment of coding).
-Andreas
[To remove yourself from this list, or to change to digest mode, go to
http://www.penworks.com/LUJ/lingo-l.cgi To post messages to the list,
email [EMAIL PROTECTED] (Problems, email [EMAIL PROTECTED])
Lingo-L is for learning and helping with programming Lingo. Thanks!]
