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.

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).

Okay. I read every single comment and have thought about what Forum_account, Tom and LummoxJR have discussed here.

Would it not be feasible to add one extra var called something like bounds_mode that is used to determine what the bounds var is used for? I know this goes somewhat against the KISS principle, but let me explain what I mean.

Basically, there would be constants that it could be assigned to: NO_BOUNDS (default), RECTANGLE_BOUNDS, CIRCLE_BOUNDS, ICON_MASK_BOUNDS, etc.
What this means is that the bounds var would be interpreted based on the bounds_mode, instead of what kind of data it is assigned to.

You could add another rectangle mode (RECTANGLE_NUMERIC_BOUNDS?) that allows use of a couple vars (bound_width, bound_height) that are otherwise ignored (internally, and by the developer) in all other modes that instead use bounds (since they only require a single var for say, the icon mask, the bound string "8,8 to 24,24", the radius, etc.).

It seems to me, something like this would please everyone. (It adds more vars, but Tom said he was already considering to do that.) Plus, having a mode var that requires a single integer comparison seems much more efficient than parsing a string to determine what mode the bounds are using. Not to mention, it's much easier for the developer to make a small typo in the string and not realize it, when a macro like that would give a compiler error right away.

I do see an extra comparison being needed to now check that the bounds var is of the form that bounds_mode says it is, but that doesn't seem like it would be more than a single integer comparison.

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:

// 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.

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.

Actually, you just gave a great example of how the string makes things more extensible, because your example can be coded as a library to do exactly the notation you want. You just have to call some kind of update() after setting your width, height, angle etc. It's kind of ridiculous to have us hard-code ROTATED_RECTANGLE or all of these other arbitrary shapes when you can just do it yourself.

That said, this proposed notation is actually feasible so we'll keep it in mind (you could also assign shape/bounds to an icon).

You make it seem like pixel-based collision is a good solution to everything.
Correct me if I'm wrong, but isn't pixel-based collision ridiculously inefficient compared to almost any other collision detection and almost never used because of it?

Sure, it would be great if we could make icon masks for any imaginable shape we want and just do pixel-based collision for anything, but I thought that wasn't feasible.

Correct me if I'm wrong, but isn't pixel-based collision ridiculously inefficient compared to almost any other collision detection and almost never used because of it?

In 2D-space it's actually not that hard of a problem and certainly something we could do without much overhead. It would involve storing either a grid of opacity bits or a depth value to the nearest opaque pixel for each point on the perimeter. I'm not saying we'll have it in immediately but it's an option and hence something to consider in the notation.

Just FYI, we took the suggestions here and changed to a numerical notation and added a few handy accessibility functions. Furthermore, we decided (also as per comments here) to keep pixel_x/y/z as purely visual (so as to reduce conflicts with existing games/libs) and use new movable step_x/y vars for the physical offsets. There are a few new functions that we'll describe in the upcoming post. I'm hoping that people can use this without having to resort to hacks, and the main purpose of the demos/testing is to get case studies (as will the beta test). Obviously we won't cover everything but hopefully it'll be pretty good.

I don't know if I'd call this "interesting" since you can do most of this already with the excellent libraries people have written up, but it is faster for many cases and does seem like something that should be built into the language, since it is expected of modern games (I believe this was the crux of Falacy's argument). I believe that for more extensive operations (eg, Forum_account's sidescroller and gravity implementations), people will want to continue to use libraries but those libraries can leverage this new functionality to be more efficient.