• Hello [name]! Thanks for joining the GMC. Before making any posts in the Tech Support forum, can we suggest you read the forum rules? These are simple guidelines that we ask you to follow so that you can get the best help possible for your issue.

GMS 2.3+ Bug with image_xscale and bounding mask?

Warchamp7

Member
I'm running into a weird off by one issue when referencing bbox_left/bbox_right relative to the objects x position when xscale is changed

xscale = 1
bbox_left: 192
x: 224
bbox_right: 256

Left and right of the bounding box are both 32 as expected

xscale = -1
bbox_left: 191
x: 224
bbox_right: 255

Left of bounding box is now 33 away from x, and right is 31 away


I'm sure I'm doing something very silly to even run into this problem, but it still shouldn't happen, no?
 

Warchamp7

Member
Not sure if bumps are against the rules or anything (Can't find anything about it in any of the rules/guidelines posts)

Anyone else able to replicate this and know if it's a bug or not?

Non integer xscales seem to make it even worse
 

chamaeleon

Member
Not sure if bumps are against the rules or anything (Can't find anything about it in any of the rules/guidelines posts)

Anyone else able to replicate this and know if it's a bug or not?

Non integer xscales seem to make it even worse
Bumps are allowed after some period of time. You are perhaps using a manually defined collision bounding box, perhaps with values 0 and 64 for left and right sides, instead of 0 and 63. With a width of 65 for it, GMS cannot to have it stay exactly in place without moving the instance in the x position one pixel when you mirror it (and GMS will not modify x by itself just because you mirror the image). If it is 65 wide, assuming centered origin, 32 will be on one side, 33 on the other. Mirroring will swap 33 and 32, resulting in the shift in values for bounding box left and right, relative x. If you really need the values to stay the same, either make the left edge -1 or the right edge 31 in the bounding box definition to get an even number of pixels covered.
 
Last edited:

Warchamp7

Member
Bumps are allowed after some period of time. You are perhaps using a manually defined collision bounding box, perhaps with values 0 and 64 for left and right sides, instead of 0 and 63. With a width of 65 for it, GMS cannot to have it stay exactly in place without moving the instance in the x position one pixel when you mirror it (and GMS will not modify x by itself just because you mirror the image). If it is 65 wide, assuming centered origin, 32 will be on one side, 33 on the other. Mirroring will swap 33 and 32, resulting in the shift in values for bounding box left and right, relative x. If you really need the values to stay the same, either make the left edge -1 or the right edge 31 in the bounding box definition to get an even number of pixels covered.
That wouldn't explain why the bounding box is 32 on each side when it's not flipped though, no?

If it was 65 wide, then it should be 33 on one side, and 31 on the other, and changing the xcale to -1 should just swap those values
 

chamaeleon

Member
You need to remember that these values, just like pixel positions in the sprite, are not referring to the center of pixels, but the top left corner of them. If it was a 3 pixel wide bounding box you would say it is one pixel on each side, but as it turns out, the origin, which is not a pixel, would have one pixel on the one side and two on the other.
 

Warchamp7

Member
You need to remember that these values, just like pixel positions in the sprite, are not referring to the center of pixels, but the top left corner of them. If it was a 3 pixel wide bounding box you would say it is one pixel on each side, but as it turns out, the origin, which is not a pixel, would have one pixel on the one side and two on the other.
I understand that, but those numbers should be identical or appropriately reversed when flipping the sprite, should they not? Not to mention my sprite is even in boundaries, not odd

If we consider those values as top left of pixels, then considering the following 4x4 sprite

1616541491686.png

With origin in the center of the sprite (2, 2), bbox_left is at -2, and bbox_right is at 2

If we flip this sprite
1616541505501.png

The sprite is still at (2,2) and bbox_left and bbox_right despite flipping are also still -2 and 2

Instead, what I'm getting is more like the following
1616541632421.png

Where the sprites x position is still correct, but the bbox_values are misaligned, as if their now relative to the top RIGHT of the pixel, instead of top left
 
Last edited:

chamaeleon

Member
bbox_left being -2 and bbox_right being 2, means you have an uneven number of pixels covered because you have two pixels to the left of 0, two pixels to the right of zero, plus the zero offset pixel, for a total of 5 pixels worth of bounding box width. Coupled with the fact that these values are not in the center of the pixels, you will find that you have two pixels worth of the bounding box to the left and three pixels to the right of the origin, which is the mirroring point.

An instance with a sprite the size of 4x4 pixels, placed at 0, 0 in the room will by default show -2, 1 for bounding box left and right, not -2, 2. -2 and -1 are to the left of origin, 0 and 1 is to the right. If you had -2, 2 for your bounding box, you would instead have -2 and -1 to the left, and 0, 1, and 2 to the right.
 
Top