walter.h.brown at gmail.com
Sun Dec 6 13:44:40 EST 2015
I was trying to recreate "Boids" (but got distracted playing with the
muckingabout stack at the same time, more on that later :-).
I had each object post their position to a global list of objects when they
stopped moving (or when a new recalculation cycle is declared). Then each
object had it's own script to look at that list during next-move planning
and determine nearest neighbors. I compared the shortcut of just averaging
the XYZ differences but found getting the actual XYZ distance (the root of
the sum of the squares) took close to the same time for the number of
objects I was estimating. I used layer difference (multiplied by a suitable
factor to get in the same scale as the screen XY) as the Z distance to
emulate 3D. I created a parameter called MinDistance, and if the distance
was less than that, declared a collision (In boids, MinDistance is
variable, depending on if the collision was inter or intra species or
static objects). Each object then incorporated that fact in it's next plan
- typically going in a vector somewhat opposite of the collision point,
after disassembling the 3D diagonal vector into XY screen coordinates and
speed, and a Z emulation using layer changes.
If you wanted orthogonal adjacency (as in the muckingabout stack), you
could compare the position difference against the objects' sizes on each
axis. If they are equal, the objects are adjacent. Adjacency would have XY
differences of either 0,object height or object width,0.
Or you could fill a global XY array (ie a set of lines of lists, which is
what I am adding to muckingabout) which stores what (ie a tile) is at each
location (square) in the grid (along with rotational data) and each object
can query and update that list. In muckingabout, I am thinking of naming
each square their XY location, so a tile can query specific squares without
On Sun, Dec 6, 2015 at 10:12 AM, Richmond <richmondmathewson at gmail.com>
> I am aware that objects/controls are on different layers on a LiveCode
> but the end-users looking at a 2-dimensional screen they are all,
> on a flat surface.
> Has anyone any idea how a script within the mouseUp of one control could
> detect the presence of "adjacent" controls on the same card, and,
> read properties from those adjacent controls?
> This would seem to be mission-critical for games.
> The 'problem' is that adjacent controls cannot be detected by INTERSECT
> because they don't . . . intersect.
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
More information about the Use-livecode