The obvious method for generating the points of an oval—use a loop that
generates sin(x) & cos(x) coördinate-pairs—has already been mentioned. What's
*not* so obvious, is that the points generated by that method are not evenly
spaced! Not unless you're working with a perfect circle, anyway. For non-circle
ovals, the distance between any two consecutive points will rise with the
distance between those points and the origin. So if you're using those points
in a "move [whatever] to the points of"-type command, the thing you're moving
will not move at a constant speed… well, not unless your 'oval' is a circle, in
which case the distance to the origin will be constant, hence the resulting
speed of motion will also be constant.
The closer your 'oval' is to a perfect circle, the less obvious the deviations
from constant speed will be, of course. You'll have to decide for yourself
whether those deviations are of great-enough magnitude to be worth worrying
about.
If deviations from constant speed *are* worth worrying about? Depending on what
you're actually doing, you may actually want to have the oval-path-constrained
motion vary in speed, and the particular mode of variance you end up with may
be exactly the mode of variance you get from using the obvious method. But in
any other case, you may want to look into a different method for generating the
set of oval-points you use.
"Bewitched" + "Charlie's Angels" - Charlie = "At Arm's Length"
Read the webcomic at [ http://www.atarmslength.net ]!
If you like "At Arm's Length", support it at [
http://www.patreon.com/DarkwingDude ].
_______________________________________________
use-livecode mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
