built-in 'bounds' variable

ID:227863
 
Jan 30 2012, 3:02 pm
Keywords: bounds
I just discovered this, because it shows up in the vars list. Why isn't it documented?

mob
    bounds = "16,16"
    Login()
        src << "[bound_width]x[bound_height]"
        bounds = "24,24"
        src << "[bound_width]x[bound_height]"
// Output:
//  16x16
//  24x24


I'm liking the variable aliases, like fps<-|->tick_lag, glide_size==pixel_step_size, etc., but they're only useful to me after I find out about them. Maybe the bounds variable is unstable or buggy or something, somehow. Or maybe you just forgot about it. I'm using it from now on, anyhow.

I would like, though, if vectors were supported natively. That is, like in Coggoid, properties that belong together should be the same variable.
For example, an equivalent of your x, y, and z would be pos = vec3(x, y, z). Colors would be vec4(r, g, b, a). Setting pos=1 would be the same as setting pos=vec3(1, 1, 1) since pos is defined as a vec3.
Vector calculations are definitely okay already (jt_vectors creates and garbage-collects new /vectors each operation), but a built-in alternative would be nice. Maybe I could make something using lists, but lists can't have chlidren.
#1 Jan 30 2012, 4:22 pm
I second everything Kaiochao said, especially about the native support of vectors. In nearly all graphic libraries that I have tried there are at least one form of a vector type. It seems odd that there isn't one for BYOND, and as far as I know no one has put effort into trying to softcode one. In fact, would it be possible to softcode one?
#2 Jan 30 2012, 8:21 pm
When I asked Lummy about it before he said, and I copypasta;

Lummox JR (12:47:04 PM): Yeah. It's just a shortcut for using the others. We didn't document it because Tom felt it would be too confusing on the first pass, just too much to absorb right now, and since it only covers rectangular bounding boxes it wasn't considered important to document.
#3 Feb 2 2012, 1:25 am
I wish the developers weren't down-grading the users... Maybe they should come up with a better presentation of the information if they're afraid its going to be too confusing. There's people who have use for these things, and many others. Like the "glide-size only" or "step_size only" modes that you're forced into, instead of being able to have a mixture of both because it was "too confusing" for the community.
#4 Feb 3 2012, 6:48 pm
In response to FIREking (#3)
FIREking wrote:
I wish the developers weren't down-grading the users... Maybe they should come up with a better presentation of the information if they're afraid its going to be too confusing. There's people who have use for these things, and many others. Like the "glide-size only" or "step_size only" modes that you're forced into, instead of being able to have a mixture of both because it was "too confusing" for the community.

Agreed. If the staff is afraid that bounding boxes are too much for users to handle they're bound to attract the type of user who will struggle to understand bounding boxes. If the staff added features that pushed users to work and learn new things, BYOND would both grow and attract better developers.

Most of my libraries aren't geared towards complete idiots and they bring out the BYOND users who aren't complete idiots. I get a lot of people asking me good questions and not a lot of people saying "can u write this 4 me my goto loop isn't working rite". I have a better outlook than most BYOND users because I get to deal with better-than-average users. I'm pulling users from BYOND's set of game developers. BYOND is pulling from the internet's set of game developers. They could apply the same idea but they cater to BYOND's lowest common denominator.
#5 Feb 4 2012, 6:11 am (Edited on Feb 4 2012, 6:37 am)
Kaiochao wrote:
Maybe I could make something using lists, but lists can't have chlidren.

Why do they need children? You can make procs that operate on lists instead of making procs that belong to lists. Instead of saying "a.add(b)" you'd say "add(a, b)".

Edit: You can also do a lot with macros. I didn't realize DM supported things like "list(1,2)[1]", which lets you do things like:

#define vec(x,y) (list(x,y))
#define vec_add(u,v) (list(u[1]+v[1],u[2]+v[2]))
#define vec_print(a) "\[[a[1]] [a[2]]]"

world << vec_print(vec_add(vec(1,2), vec(3,4))) // outputs "[4 6]"


It'd still be nice to have this built-in so procs that deal with colors could use the built-in vectors.
#6 Apr 20 2012, 9:44 pm
Reading the 'bounds' variable at runtime shows another syntax that integrates the bound_x/y variables.
"[x1],[y1] to [x2],[y2]"

I think this should definitely be documented, because although it's nice to have separate variables for each property of the bounding box, bound_width/height and bound_x/y (why doesn't world.icon_size do this too?), setting the bounds using one simple text string is much easier.
#7 Apr 20 2012, 11:41 pm
In response to Kaiochao (#6)
Kaiochao wrote:
Reading the 'bounds' variable at runtime shows another syntax that integrates the bound_x/y variables.
"[x1],[y1] to [x2],[y2]"

Yes, this was my preferred notation as well, and it is easier internally for us to have a single variable that takes care of all dimensions. With something like this, we could have maptext_bounds and support, for instance, the requested maptext_x/y. Otherwise we have to add two new variables (which is do-able but adds more clutter and actually isn't as trivial to implement as it might sound).

Unfortunately, a few very vocal users here cried about having numerical vars in the form of text strings even though I pointed out that it would be trivial to soft-code the numerical versions and translate (basically a single proc) when these needed to be rewritten (which is pretty rare for most games).

Obviously a vector notation would be the proper way to do this but this is quite difficult to add to the existing language since we want these to be set at compile-time.
#8 Apr 21 2012, 5:17 am
Tom wrote:
Unfortunately, a few very vocal users here cried about having numerical vars in the form of text strings even though I pointed out that it would be trivial to soft-code the numerical versions and translate (basically a single proc) when these needed to be rewritten (which is pretty rare for most games).

There's nothing wrong with having this form, but requiring it is what would be detrimental. The string representation is an internal convenience to BYOND but it's not that useful to the developer.

Obviously a vector notation would be the proper way to do this but this is quite difficult to add to the existing language since we want these to be set at compile-time.

You can define a list at compile-time, why wouldn't this work for built-in vectors?

mob
    var
        list/some_list = list(1, 2, 3, 4)
        vector/some_vector = vector(0, 5)

// you can do things like this with lists:
var
    list/my_list = list(1, 2)
    list_1 = my_list[1]
    list_2 = my_list[2]

// and objects:
vector
    var
        x
        y

    New(i, j)
        x = i
        y = j

var
    vector/my_vector = new(3, 4)
    vector_x = my_vector.x
    vector_y = my_vector.y