Bound Shape

ID:2000600
 
Dec 19 2015, 12:09 pm
Applies to:Dream Maker
Status: Open
Issue hasn't been assigned a status value.
I propose a new variable for atoms called 
bound_shape (atom variable)
. For more advanced shapes, we currently have to make multiple objects. For the format, there could either be parameter format or string format, whereas you'd do something like:

atom/bound_shape = "1:width=6,height=4;2:width=10,height=2;3:width=2,height=10"


This could easily create a complex bound shape without having the inconvenience of making multiple objects.
The numbers in the example specify which initial shape they pertain to, though in reality they'd not be necessary.
Dec 19 2015, 12:14 pm
I agree with this becoming a feature; it could be really useful in a project I'm coming to develop.
Dec 19 2015, 12:19 pm
Ahem

I think you'd need to somewhat simplify that format though, it took me a few reads over to understand it. Perhaps instead of a new var, bound_width, bound_height, bound_x and bound_y could accept lists. All would have to be lists for it to compile, and the lists must be of identical length.

So you'd have

bound_width = list(10,10)
bound_height = list(10,10)
bound_x = list(1,5)
bound_y = list(1,5)


This would make two 10x10 bounding boxes at coords 1,1 and 5,5. They would overlap, but be considered the same atom, so no collision checks would happen between them.
Dec 19 2015, 12:25 pm
Upon re-reading and then re-re-reading (wtf man), I see you're saying to have a bunch of different shapes instead of just a box. This'd be obviously fantastic, but I don't really understand the need to have more than one shape per atom.

Perhaps instead, using my above example, your bound_shape could also take a list, something like this

//One bounding box, of the pentagon shape
bound_shape = BOUND_PENTAGON
//Two bounding boxes, of the square and triangle shapes
bound_shape = list(BOUND_SQUARE,BOUND_TRIANGLE)


This would work in tandem with the other bound_vars being assigned as a list.

The difficult part is parsing "height" and "width" to use it on other shape types. Does it just try to fill a box as far as possible until it reaches those limits? I guess that's the most logical way, not sure on how feasible it'd be.
Dec 19 2015, 2:23 pm
This is a badly needed feature lol tho I'm sure someone could think of better syntax
Dec 19 2015, 2:25 pm
Dec 19 2015, 2:55 pm
In Hobnob's Spacewar demo, he defines polygons like this one using a list of coordinate pairs:
    red
        get_hull_points()
            return list(6,5, 13,28, 20,28, 27,5)

(6, 5), (13, 28), (20, 28), and (27, 5) are the pixel coordinates of where the polygon's vertices are within the icon. The center is assumed to be (16, 16) (although it should probably be (16.5, 16.5)).

Using a list of coordinate pairs is fairly common syntax for defining a polygon. You really shouldn't be trying to think of new syntax for something that isn't new at all (outside of BYOND).
Dec 19 2015, 3:07 pm
In response to Kaiochao
And it's also extremely easy to build a regular polygon from sine and cosine. There's not really a need to make this a feature request, just a library.
Dec 19 2015, 4:08 pm
Honestly, I'd prefer that the polygon hulls not actually be interpreted from variables, but rather objects in their own right. That way you only have to store a reference to the polygon upon creation.

Ideally, I think a bitmask would be the better option. Bitmasks can be very fast to solve collisions for if you use multiple mips for detection.

Just using a monochrome DMI would be a pretty decent way to define bounding areas.
Dec 19 2015, 4:13 pm
In response to Ter13
This is how Land of Fire does it, it's very smart but the amount of workaround you have to do to soft-code it is a LOT of hassle.
Dec 19 2015, 4:22 pm
In response to Ter13
Ter13 wrote:
Honestly, I'd prefer that the polygon hulls not actually be interpreted from variables, but rather objects in their own right. That way you only have to store a reference to the polygon upon creation.

Ideally, I think a bitmask would be the better option. Bitmasks can be very fast to solve collisions for if you use multiple mips for detection.

Just using a monochrome DMI would be a pretty decent way to define bounding areas.

I think Tom or Lummox mentioned using DMI masks back when pixel movement and bounding was first implemented.
Dec 19 2015, 8:22 pm
its not practical to do all that work around stuff in a multiplayer setting
Aug 3 2019, 7:54 pm
Bump, I also think it should belong to atom/movable
Aug 18 2021, 6:56 am
BUMP?