<-> Aug 11 2011, 1:36 pm Are icon masks the ability to make non-rectangular bounds? For example, an L-shaped collision box? I know for a fact I would use that first thing.
 <-> Aug 11 2011, 2:06 pm Lummox JR wrote: For this reason I get where FA is coming from when he mentions preferring two numeric vars to represent x*size+pixel_x and y*size+pixel_y, for instance. You're simplifying it there. I think it'd be something like: absolute pixel x = x * icon_width + pixel_x + bounds.left x is the atom's x var icon_width is parsed out of world.icon_size pixel_x is the atom's pixel_x bounds.left is parsed out of the bounds string (if you set bounds to something like "8,8 to 24,24", it'd be the first 8) I'm still confused about how you can store it as separate numbers internally but think that it'll be easier for DM developers to have a single string. If you have any questions about how to make it work by exposing a set of new variables to the developer, pose some questions to the community. I'm sure we can come up with something.
 <-> Aug 11 2011, 2:12 pm Forum_account wrote: I'm still confused about how you can store it as separate numbers internally but think that it'll be easier for DM developers to have a single string. Since bounds can theoretically represent many things besides a simple width x height, it is more flexible to use a text string. Yes, assigning to a datum would be nicer but that is a lot more work and has some limitations, which Lummox JR and I have both gone over multiple times. If there is really this huge need to constantly read or write the bounds, and for whatever reason people don't want to use the extremely simple method I proposed, I suppose we could provide width/height in addition to bounds (which could store more complex information).
 <-> Aug 11 2011, 2:13 pm Mista-mage123 wrote: Are icon masks the ability to make non-rectangular bounds? For example, an L-shaped collision box? Yes, with an icon mask you could assign any shape bounding region you wanted. Using the atom's icon for its mask would give you true pixel-level collision detection.
 <-> Aug 11 2011, 2:27 pm Tom wrote: Yes, with an icon mask you could assign any shape bounding region you wanted. Using the atom's icon for its mask would give you true pixel-level collision detection. If that's the case, then would non-square icons work as well, like triangles and circles? Would they bump based on pixel collision? I'd love to see this.
 <-> Aug 11 2011, 2:27 pm Tom wrote: Neblim wrote: Tom has only played MUD based games. This is not true! I am an avid Halo player but I can't reveal my gamer tag because of my penchant to teabag and trash talk. ^Lol'd.
 <-> Aug 11 2011, 2:29 pm Bravo1 wrote: Tom wrote: Yes, with an icon mask you could assign any shape bounding region you wanted. Using the atom's icon for its mask would give you true pixel-level collision detection. If that's the case, then would non-square icons work as well, like triangles and circles? Would they bump based on pixel collision? I'd love to see this. .... is it even possible to have an image with a non-square canvas? ..
 <-> Aug 11 2011, 2:32 pm Yut Put wrote: .... is it even possible to have an image with a non-square canvas? .. Not the canvas, If you take opacity into account, the technically, yes.
 <-> Aug 11 2011, 3:26 pm What I'd rather see is something like this: ```var const RECTANGLE = 1 CIRCLE = 2atom var shape = RECTANGLE width = 32 height = 32 ``` If the shape is set to RECTANGLE, BYOND uses a rectangle with the specified width and height as the bounding box. If shape is set to CIRCLE, it uses a circle (or maybe an oval) that fits inside that rectangle as the bounding shape. If you added another bounding type you'd add another constant and maybe some additional vars (if they're needed). For example, if you wanted to support rectangles that could rotate, under each method (bounds string and vars), you'd do: ```bounds = "5,21 to 10,5 to 26,10 to 21,6"// orshape = ROTATED_RECTANGLEwidth = 18height = 18angle = 20 ``` To support this using vars you'd need to add a new constant and the angle var, but think about what it takes under each method to rotate the rectangle: ```// using vars:angle += 5// using a string:proc rot_x(x, y, cx, cy, angle) x -= cx y -= cy . = x * cos(angle) - y * sin(angle) . += cx rot_y(x, y, cx, cy, angle) x -= cx y -= cy . = x * sin(angle) + y * cos(angle) . += cy// scroll to the right, this line's a doozy!bounds = "[rot_x(x1,y1,cx,cx,angle)],[rot_y(x1,y1,cx,cx,angle)] to [rot_x(x2,y2,cx,cx,angle)],[rot_y(x2,y2,cx,cx,angle)] to [rot_x(x3,y3,cx,cx,angle)],[rot_y(x3,y3,cx,cx,angle)] to [rot_x(x4,y4,cx,cx,angle)],[rot_y(x4,y4,cx,cx,angle)]" ``` It's been said that using a string makes things more extensible, and that sounds good, but I don't see any examples. It just looks much more complex to parse as you have more advanced bounding methods and, in this case at least, it even becomes difficult to set.