ID:1626682
 
(See the best response by Ter13.)
I've been playing around a lot with pixel movement and came across the values in the help file, it claims that it simply offsets the bounding box, for situations such as where you have smiley face of 16x16 centered on a 32x32 icon and want the bounding box to match up with the smiley.. but isn't that what pixel_x and pixel_y are for?

Without thinking much of it I put it into practice under such use thinking I'd try it because I could and new things were fun, only to discover that it acts extremely strangely with step_x and step_y, sometimes resulting with negative numbers in those values when such would usually be impossible, where other objects without bound_x/y offsets of the same bound location would have 0 in those values.

My question is simply, what situations would you actually want this, as my mind is blank as it seems like its only use would be a more confusing method of what pixel_x and pixel_y already accomplish. Curiosity is distracting.
pixel_x/y are only visual effects, whereas bound_x/y affect the object's bounding box position. In a setting where 32 pixels is a full tile, setting pixel_y to 96 would set an object to appear three tiles north of its original position, however, its bounding box position would remain unaffected.
In response to FKI
FKI wrote:
pixel_x/y are only visual effects, whereas bound_x/y affect the object's bounding box position. In a setting where 32 pixels is a full tile, setting pixel_y to 96 would set an object to appear three tiles north of its original position, however, its bounding box position would remain unaffected.

I understand that, but I don't understand why you would ever want to use bound_x/y. I understand how it works, I just don't know why it would be used. And would like to know, because it's eating at my curiosity.

My main trouble is that you can accomplish changing bounding box size by simply working with bound_height and bound_width, and then change icon position with pixel_x and pixel_y (or just use an icon that fits your new bounds to your liking)
You could, but I don't see why you would do that; I think it makes more sense to adjust where the bounding box is than to use pixel offsets that way. I also feel it's easier to track later on. You can look at a line like bound_x = 16 and automatically tell what it's for. I'd stick to using pixel offsets for visual effects and nothing more.

Maybe that's just me though.
Well, admit-ably I would do that, but doing so messes up step_x and step_y in manners that are odd, for example, an object with a bound_x=10 set, while at 2,2 on a map pushed as far to the bottom left of the tile as possible would have step_x at -10, while an object without bound_x would regularly have a step_x of 0 in that situation.

That means that your object will act out of the ordinary compared to other objects, meaning you have to calculate the current value bound_x of any object if you want to find the 'true center' of their current location for things such as determining where to point an arrow or a projectile at, which means extra calculations required.

It might not influence you if you don't make use of such things, but it grandly confuses me when the bottom left of an object isn't actually part of its bounding box, and in fact is capable of being calculated to be in a tile that isn't even one of your locs, not to mention how weird that is when you're getting close to the true bottom left of the map.
Pixel_x and Pixel_y also come into play with Matrix transforms as well. The Center of the atom will still be calculated at the same spot no matter how you change the pixel offsets, changing bounds will also change the center of the bounding box.
In response to Bravo1
Bravo1 wrote:
Pixel_x and Pixel_y also come into play with Matrix transforms as well. The Center of the atom will still be calculated at the same spot no matter how you change the pixel offsets, changing bounds will also change the center of the bounding box.

I fully understand how bounds variables work and how pixel_x and pixel_y only influence visual, I only made this question for the purpose of finding out if anyone actually knew any 'real situations' where they could use bound_x and bound_y that would work better or accomplish something other than the method I described by simply using bound_height and bound_width to set the bounding box with pixel_x and pixel_y offsets to center the icon after.

I am asking, because I don't understand why bound_x and bound_y would exist if everything you can do with them can be more efficiently accomplished in another method.
I am asking, because I don't understand why bound_x and bound_y would exist if everything you can do with them can be more efficiently accomplished in another method.


Again, bound_x and bound_y modify the physical left and bottom edge of an atom.

pixel_x and pixel_y cannot do that.

Simply put, what bound_x and bound_y do, cannot be emulated by other (more complicated, not easier) methods, without also changing how matrices apply to that atom.


Essentially, along with bound_width and bound_height, it allows you to create any kind of bounding box you'd like, while keeping the matrix focused on the center of the atom.

Changing pixel_x and pixel_y cannot do that. They do different things and even though it looks the same on the surface, they both behave very differently.

I don't know how else to explain it besides using multiple drawn out examples which should be, normally, easy for you to imagine yourself.
I'm not saying pixel_x and pixel_y have anything whatsoever to do with bounding boxes, I'm simply saying they can be used to center an icon after setting the exact dimensions you want with bound_width and bound_height alone without making use of bound_x and bound_y.

For example, in the event you have a 32x32 icon with a 16x16 smiley face in it, you could simply set bound_height/bound_width to 16 and then just have a pixel_x/pixel_y of -8 to center the icon onto your bounding box.

I just ran several tests, and this yields an identical result with matrix transformations and overall display of icon, and movement behaves identically in either case excluding the few exceptions related of how step_x and step_y evaluate. I don't quite see what you mean about it changing how matrixes interact with it, as I cannot find such a situation.

Sorry if my wording had confused you of what I meant or if I'm missing something really obvious. If I'm frustrating you you need not feel bad for just giving up on explaining, as honestly this is simply a question of curiosity rather than my actually encountering something that's stopping my progression.

If there's a flaw in my method I would love to know it, but I sure can't seem to find one on my own. And so long as no flaw exists I cannot understand a practical use for bound_x and bound_y when they cause such a unique effect upon step_x and step_y compared to objects not modified in this manner.
I'm simply saying they can be used to center an icon after setting the exact dimensions you want with bound_width and bound_height alone without making use of bound_x and bound_y.

Yes. Visually. Only visually.

That's why bound_x and Bound_y exist because they do it Physically.

There's a difference.


For example, in the event you have a 32x32 icon with a 16x16 smiley face in it, you could simply set bound_height/bound_width to 16 and then just have a pixel_x/pixel_y of -8 to center the icon onto your bounding box.

Or you could set bound_x and bound_y to 8 each and then bound_width and bound_height to 16 each.

Why do this? Well, what happens if you want to change pixel_x and pixel_y frequently in an icon?

Using your pixel method, every time you change pixel_x and pixel_y you'll have to take that -8 into account for every single calculation

Want to set pixel_x to 48. Great, but it's not 48 anymore, it's always going to be 48-8, You'll have to remember to do that math each and every time you modify pixel offsets.

Or you could just modify bound_x and bound_y once and play with pixel offsets till your legs fall off.

Especially if your matrix transforms are using pixel offsets, like I mentioned.

It allows pixel offsets without messing with pixel_x and pixel_y, and should be used over pixel_x and pixel_y for permanent bounding boxes so that you're free to manipulate the pixel offsets without having to code in exceptions so that the offsets always return to -8 in order to appear centered.
In response to Bravo1
Bravo1 wrote:
Using your pixel method, every time you change pixel_x and pixel_y you'll have to take that -8 into account for every single calculation

Want to set pixel_x to 48. Great, but it's not 48 anymore, it's always going to be 48-8, You'll have to remember to do that math each and every time you modify pixel offsets.

The opposite of that argument is my main argument against bound_x and bound_y's use to begin with. To determine the ultimate pixel location of an object you would use the calculation as follows:

ultimate_x = (x*world.icon_size)+step_x
ultimate_y = (y*world.icon_size)+step_y

(and if you wanted the centre of an object you would simply add bound_width/2 and bound_height/2)

This value is important in some more complicated targeting systems and movement systems. On a regular object this value would reflect the bottom left of an objects bounding box, however if you use bound_x and bound_y the calculation would result in a location minus the bound_x/bound_y value, and thus you would have to add "+bound_x" the the equation severely raising the processing involved, and for those who use this kind of evaluation it often is required to be evaluated multiple times per frame for a single object's targeting. Also of note is that while using bound_x and bound_y, directly setting x/y and step_x/step_y to the same values as an object that isn't sharing the same bound_x or bound_y will result in the bottom left of their bounding boxes being in different locations, again needing to apply it into such calculations.

In addition to all that if you're changing pixel_x and pixel_y that often you might be better off just using matrix.Translate() with or without animate() to make it smooth. But that's unrelated to the point.

So far your argument has only strengthened my standing on that both methods seem to have a pretty much identical effect. (Though I've never been in a situation where an object with a bounding box would actually need pixel_x and pixel_y changed rapidly, so for me my method seems better with the points so far risen, but I suppose that much varies from opinion).

My point isn't that my method is "strictly better" but rather that it's pretty darn tootn' the same final result with pretty darn tootn' same amount of trouble involved in calculating it with no difference in capability that can be found.

Either way by the fact that you haven't presented any points of the magnitude my curiosity was looking for, it appears my question has been answered in that there isn't really anything that the bound_x/y method could exclusively accomplish compared to my own method. (which for me happens to be better on processing) So thank you for answering, as you have in fact placed solidity in my original theory.
Best response
@Felix: Your argument is that bound_x/bound_y don't have a purpose because pixel_x/pixel_y serve the same role.

Therefore, I posit to you that pixel_x/pixel_y is useless because atom.transform serves the same role.

Your argument is invalid. All your base are belong to me.

Moreover, Bravo has explained the same thing to you a number of times. You aren't understanding what he's saying, and calling that a victory.

The opposite of that argument is my main argument against bound_x and bound_y's use to begin with. To determine the ultimate pixel location of an object you would use the calculation as follows:

ultimate_x = (x*world.icon_size)+step_x
ultimate_y = (y*world.icon_size)+step_y

The point is that it's easier to set a variable than to do constant operations to find out that same variable.

bound_x and y are for the sake of simplicity.

You keep on overlooking the entire point of the variable. It doens't matter if you consider it easy to do the operation, the fact of the matter is that it's easier to use bound_x and y.

My point isn't that my method is "strictly better" but rather that it's pretty darn tootn' the same final result with pretty darn tootn' same amount of trouble involved in calculating it with no difference in capability that can be found.

Except it isn't. It's more work. What's easier? Set it and forget it? Or "hang on, let me do this calculation for every single step I do, no no, trust me it's totally easy to calculate."

however if you use bound_x and bound_y the calculation would result in a location minus the bound_x/bound_y value, and thus you would have to add "+bound_x" the the equation severely raising the processing involved

wut

You literally have no idea what bound_x and y do, even after I explained it to you.

That doesn't happen. bound_x and bound_y change the physical box of an atom. Meaning that, once the change is done, there's no other math involved.

In the meantime, editing pixel_x and pixel_y since they're visual changes only, results in the image of the mob being displayed askew from it's normal position. This means exactly what you explained for bound_x and bound_y would happen.


I cannot fathom how you are this dense.

Either way by the fact that you haven't presented any points of the magnitude my curiosity was looking for, it appears my question has been answered in that there isn't really anything that the bound_x/y method could exclusively accomplish compared to my own method. (which for me happens to be better on processing) So thank you for answering, as you have in fact placed solidity in my original theory.

You don't have an argument because you completely miss the purpose behind the variables after I explained them to you, so you're going to say that you're right and you knew it all along, and just because I'm saying "You're not right, but you won't listen to why you're not right" you believe it must be some kind of trick and that it confirms your suspicions.


Here's a final answer for you, let's see if you can wrap your head around this:

bound_x/y = physical change to lower left edge of bounding box

bound_width/height = physical change to upper right edge of bounding box

pixel_x/y = visual change to image position


using bound_x/y with bound_height/width = physical change to bounding box

using pixel_x/y with bound_height/width = physical and visual change to bounding box and image position

Please understand that just because something can be emulated perfectly doesn't mean that it doesn't need to exist, especially when s A: Emulating it is slightly more complicated and B: Not having it would remove functionality from the system.


Really, it removes functionality. You can change the position of the box, the position of the image, and finally, you can transform the image, to display a different position.

You propose that bound_x/y is useless, even though neither pixel_x/y or transforms can change the position of the bounding box itself.


Here's another fact you don't fathom: If you just set bound_width/height and pixel_x/y, changing the loc of that mob via loc=locate() will place that mob at the lower left of whatever turf it's moved to. Bound_x/y moves it to the center.
Do you really needa insult my intelligence? Here I thought we were having a friendly conversation but now you've gone and insulted me! D; My feelings are hurt so much.

Irregardless, I do understand what you're saying, and I do understand perfectly that bound_x and bound_y have a use, but it varies more from project to project than it does situation to situation.

Obviously I really suck at explaining things as what I explained of my method is clearly going right over everyone's head. I know for a fact my method works perfectly as I've been using it for quite a while on my project after switching out the usage of bound_x and bound_y per the fact that they complicated how particular operations were decided in my own project.

Your point about setting loc via locate() resulting in the end result being in the middle of the tile instead of the bottom left is exactly one of the things that I 'dislike' about setting bound_x and bound_y, as it means I have to keep note that the bounding box isn't going to be the bottom left of the tile when at a location with 0 step_x and 0 step_y, which means it will act irregularly to that of an object without bound_x and bound_y. That is just personal opinion though.

You say my method doesn't work half as efficiently at all, but in my project it does in fact work more so efficiently. If you really so desperately want to make rude remarks on my intelligence just for my poor capability at putting information to words go ahead, but if you'd like I can actually show you my project to display the actual usage, and how in 'my' project using bound_x and bound_y would be impractical, or you could just take my word for it.

Regardless, you've actually answered my question. There's no point in continuing this thread to just call me an idiot, as I know for a fact that I understand all of what you're saying, even if you don't think I do. I appreciate you trying to make me see I'm missing something but all that's happening is I'm failing to explain to you properly of exactly what I mean to say, probably because I'm really bad at writing on forums.
In response to Ter13
Ter13 wrote:
@Felix: Your argument is that bound_x/bound_y don't have a purpose because pixel_x/pixel_y serve the same role.

Therefore, I posit to you that pixel_x/pixel_y is useless because atom.transform serves the same role.

Your argument is invalid. All your base are belong to me.

Moreover, Bravo has explained the same thing to you a number of times. You aren't understanding what he's saying, and calling that a victory.

More accurately, I didn't start with an argument, I simply asked what people used it for, as in my experience I didn't really have a usage for it. I have in fact now learned what exactly people expected from it and usually want from using it vs just setting bounds with bound_height and bound_width. Thus I see it has a use, it just doesn't have a use for my project.

And I did and do understand what Bravo's explaining, it's simply not relevant to that of which I wanted to know, as he was only mentioning it based on my poor explanation of my own method.
I simply asked what people used it for

Well there's your problem. Nobody uses the pixel movement stuff because they are terrified for some reason that it will "cause lag" (which is stupid because pixel movement and tiled movement use the exact same code to do their work, tiled movement actually does more because it has to trigger the gliding behavior too...).

What people use it for is irrelevant to what the feature does. Your rationality that pixel_x/y is in some way better, though, is completely wrong. Bravo pretty thorougly explained to you that your argument is irrational.
In response to Ter13
Ter13 wrote:
What people use it for is irrelevant to what the feature does. Your rationality that pixel_x/y is in some way better, though, is completely wrong. Bravo pretty thorougly explained to you that your argument is irrational.


pixel_x and pixel_y have nothing to do with my point really, which probably proves how bad I am at explaining. Rather my point was that you can create any 'size' of square with just the use of bound_width and bound_height without using bound_x and bound_y at all.

The only time pixel_x and pixel_y came into the question was for if your icon needed to be offset to fit into the bounding box, for the same reasons you would need to use pixel_x and pixel_y to center an icon on a tile-based movement game.

For me it works better in my project, as if I made use of bound_x and bound_y it would complicate some calculations that have to made rather constantly, which I won't explain the details of because I'm bad at explaining, but if you have the spare time I'd gladly show you in real time. You seem like a nice enough person after all, even if I feel almost insulted by how ready you are to believe I'm incapable of understanding basic concepts.

Either way I should stop watching this thread before I get too defensive and say something rude to someone when it's my own fault for explaining poorly in the first place..
The simple answer is that pixel_x and pixel_y were around before the advanced pixel movement system, and we wanted to have a notation where the entire bounding box could be described in a single field. If DM had a more organized built-in datum notation, we would have just had something like rect/bounds (maybe we will do it this way one day). You are free to implement things however you'd like though!