Line Tracing
Jim Hurley
jhurley at infostations.com
Fri Jan 31 03:21:02 EST 2003
>
>Message: 11
>Date: Thu, 30 Jan 2003 19:52:22 -0800
>Subject: re: Line Tracing
>From: Roger Guay <rogerguay at centurytel.net>
>To: use-revolution at lists.runrev.com
>Reply-To: use-revolution at lists.runrev.com
>
>Thanks to Gary Rathbone and Jim Hurley for their suggestions, but the
>Lockscreen property does not work, and although Jim's script is very
>clever, it results in a very choppy motion compared to repeatedly
>setting the loc of an object via an equation of motion (such as a
>projectile.) Any other ideas?
>
>Thanks, Roger
Roger,
I'm not sure why the motion should be choppy for you. Runs very
smoothly on my older Mac Powerbook (233 Mhz). You might try "set the
grid to false". And I'm not sure what you mean by "setting the loc of
an object via an equation of motion." Actually that is sort of what
I did, using a finite difference solution of the differential
equation of motion. Perhaps you mean using the solution of the
differential equation, simply incrementing the observation point.
But that shouldn't in any way affect the speed or choppyness.
If, as Sarah suggested, you only want to see the finished product of
the motion, the resulting trajectory and not its evolution in time,
you should try vector graphics. The script below bounces a ball
across the screen using a graphic line tool:
on mouseUp
put the width of this stack into w
put 1 into vx
put 4 into vy
put 0 into x
put 200 into y
put .1 into gravity
set the style of the templateGraphic to "line" -- Polygon closes
the end points
create graphic "aGraphic"
put "" into gPoints
--lock screen
put the tick into startTime
repeat until x > w
set the loc of button "ball" to x,y
put round(x +vx) &comma &round(y - vy)& return after gPoints
set points of graphic "aGraphic" to gPoints -- Try moving this
line outside the repeat loop
add vx to x
add -vy to y
subtract gravity from vy
if y > 200 then
add gravity to vy
multiply vy by -1
end if
end repeat
--set points of graphic "aGraphic" to gPoints
-- unlock screen
choose the browse tool
put the ticks - starttime
end mouseUp
If you run this as is, it will produce the *evolving* path of the
button "ball." It actually runs more slowly than the pencil tool
(1000 ticks for graphic tool, 600 ticks for the pencil on my
machine.) A second problem is that it evolves more and more slowly
as it moves across the screen. You have to successively create a
larger and larger list of points, about a thousand at the end, and
redraw this graphic at each step.
But if you comment out the "set points" *within* the repeat loop and
instead "set points" *outside* the repeat loop, it is blazingly fast,
just 39 ticks. (See the commented lines above. Also lock and unlock
the screen.) Most of the time is taken creating the graphic points
and very little drawing the result.
(Shameless plug. This is all much easier in Turtle Graphics. See
RunRev web site.)
http://www.runrev.com/revolution/education/usercontributions.html
Jim
More information about the use-livecode
mailing list