Re: adjacent objects
Richmond, 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 loops. Walter On Sun, Dec 6, 2015 at 10:12 AM, Richmondwrote: > I am aware that objects/controls are on different layers on a LiveCode > card, > but the end-users looking at a 2-dimensional screen they are all, > apparently, > 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, > subsequently, > 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. > > Richmond. > > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode > ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
adjacent objects
I am aware that objects/controls are on different layers on a LiveCode card, but the end-users looking at a 2-dimensional screen they are all, apparently, 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, subsequently, 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. Richmond. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: adjacent objects
Hi Richmond and Walt, I tried to find out your definitions of "adjacent". Walt has its own clever situation-dependent, sometimes self-adapting definition of 2D- or 3D-neighbourhoods, perhaps too complicated for your project. You, Richmond, think at first of 'nearby' rects. I suggest to do that with LC's intersect in the following way. It's just an idea. Give each of your object the points of a surrounding "inflated polygon" as custom property, changing with each change of the object's rect: d is the non-negative "inflation amount", r the rect of the object1. The (hidden) *opaque* polygon "poly1" has points -d+item 1 of r, -d+item 2 of r d+item 3 of r, -d+item 2 of r d+item 3 of r, d+item 4 of r -d+item 1 of r, d+item 4 of r -d+item 1 of r, -d+item 2 of r Having done that for each object use for example if intersect (poly1, poly2, "opaque pixels") to check for 'adjacency' of object1 and object2. Note that d could be set in an adaptive way, dependent of a game status, or as a fixed proportion of a size parameter of the object or the card or ... For more complicated shaped 2D-objects than rects one could create surrounding N-gons or surrounding (elliptic) ovals and check with these, using again LC's intersect. TMO, LC is when creating polygons (even "on the fly") and checking objects for intersection pretty fast. Hermann ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: adjacent objects
Coincidently, I am facing the same problem as I too am trying to recreate Boids in LC. However, I’m confining myself to 2D, thinking I need to learn to walk before I can fly like the Boids! How about this: create a graphic “Region” that corresponds to your desired size/region of adjacency, and set it’s blend level to 100. Then simply set the loc of grc region to loc of grc “A” and check for Intersection(grc “region”, theOtherGraphics). That should work!! BTW Walt, what is the muckingabout stack? Is that something I should know about? Roger > On Dec 6, 2015, at 10:44 AM, Walt Brownwrote: > > Richmond, > 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 > loops. > Walter > > > On Sun, Dec 6, 2015 at 10:12 AM, Richmond > wrote: > >> I am aware that objects/controls are on different layers on a LiveCode >> card, >> but the end-users looking at a 2-dimensional screen they are all, >> apparently, >> 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, >> subsequently, >> 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. >> >> Richmond. >> >> ___ >> use-livecode mailing list >> use-livecode@lists.runrev.com >> Please visit this url to subscribe, unsubscribe and manage your >> subscription preferences: >> http://lists.runrev.com/mailman/listinfo/use-livecode >> > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: adjacent objects
On Mon, Dec 7, 2015 at 3:33 AM, Richmondwrote: > > If we imagine a chessboard . . . > > ... > > Of course, the main criticism about my idea of using a field to store prop > details is that looking up info in it > will be significantly slower than using an array. > > As the base game of Carcassonne uses 72 tiles this may involve quite a hit. > > I'm not familiar with Carcassonne but if it were Chess I'd approach it this way: For each piece I'd store in a custom property (no I wouldn't use fields) a list of legal positions the piece could move to. For instance at the very start of a game the King on either side has no legal positions to move to. I'd then keep an array (sorry) of all the possible legal positions (the keys) that can be used and which pieces can use them (the elements) .i.e some squares could be moved into by one of a number of pieces. (key) (a3) wp1 (w = white, p = pawn) (a4) wp2 (a6) bp8,bkn2 (b = black, kn = knight) ... When a piece is moved it's new position is compared to it's own custom property list of legal position and if it matches it's allowed and all new legal positions for that single piece are recalculated. The ALL legal position array would then be checked to see which other pieces could move to that position and then those pieces have their individual legal positions recalculated. Finally the ALL legal positions array would be updated to reflect the new list of legal positions and the pieces that can use them. The thing to note is that with any 'move one piece at a time game' it doesn't matter if there are 32, 72, or 720 pieces, you do not have to calculate ALL the possibilities of all the pieces but typically it is only a very small subset; so you have to nut out how to quickly and easily maintain a list of valid moves. Again, using chess as a basis, 1) I'd be using behaviours as much as possible. All the pawns, whether black or white, would use the same algorithm. 2) I'd store their legal position in custom properties - easy to double check during development 3) I'd store ALL legal positions of ALL pieces in an array - but his could be printed out to a field during development to ease the troubleshooting process. 4) Updating would only occur after the placement of a piece and would be restricted to ONLY those pieces that are effected. I appreciate that you don't want to use an array and really for such a slow turn by turn based game it would be possible to figure out a grid based system i.e. line 5 item 11, and store the details of the pieces that can legally use that position. HTH ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: adjacent objects
On 06/12/15 20:44, Walt Brown wrote: Richmond, 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 loops. Walter Sounds good. Although now I am storing the characteristics of sides in 4 custom properties (e.g. TOP, BOT, LEFT, RIGHT) there is no need to store their rotation at all: you can pop the value of those custom props into places in your array. If we imagine a chessboard . . . And each row of the chessboard stores the properties of each tile in each 'square': loc1, loc2, TOP, BOT, LEFT, RIGHT, 2 further spaces for other things that may crop up . . . Or, as I have felt extremely negative about arrays ever since wrestling with one during an end-of-year PASCAL project (to make a concordance of the English translation of Leibniz's /Monadologie/), one could store "all that" as a set of comma delimited values in a multi-line field . . . . . . at which point all sorts of heavy types will jump out of the LiveCode bushes to pummel me into pulp for (among other things . . .) using fields when one can use variables, arrays and other less concrete things. The tiles can have screamingly original names such as "t1", "t2" and so on, and their sets of properties that we need to know [ location of tile, side characteristics, and so on ] can be stored in lines corresponding with the numeric parts of their names. Then, I would jalouse, as soon as one drops a tile 2 things can happen: the "where" and the "how" of the tile when it is dropped can be written to its line in the props field, and, should it have been dropped on a drop-target, the "where" and the "how" of all the other tiles can be accessed to see if they are 'kissing' our tile. The drop-targets (consisting of square graphic objects) should have a custom property ("OC" = occupied) that should, initially be set to 0 (zero) and set to 1 when a tile is dropped on it, therefore giving us a way to stop the end-user dropping a tile on a drop-target that is already taken by another tile. Of course, the main criticism about my idea of using a field to store prop details is that looking up info in it will be significantly slower than using an array. As the base game of Carcassonne uses 72 tiles this may involve quite a hit. Best, Richmond. On Sun, Dec 6, 2015 at 10:12 AM, Richmondwrote: I am aware that objects/controls are on different layers on a LiveCode card, but the end-users looking at a 2-dimensional screen they are all, apparently, 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, subsequently, 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. Richmond. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___