Explain the code:
var _center = bbox_left+(bbox_right-bbox_left)*0.5;

for example, there is a 32x32 sprite, what is bbox_left -bbox_right?
Where does 66 come from? Your calculation is correct until that number. It ends up being 116. Or the center of the x position in the room between bbox_left and bbox_right.


I haven't played around with negative image_xscale enough to know whether bbox_left could ever be greater than bbox_right. I believe the sprite_width would be negative in that case, but I would assume that bbox_left is the left edge of the bounding box without regard to the sign of anything.


Oh, I thought order of operation was honoured, but ok. Is this one of those "HTML export does it different" scenarios?
If GMS had a proper abstract parse tree of expressions before generating target platform code, it seems like it should be trivial (compared to the overall complexity of implementing GMS in the first place) to generate code that follows a very precise order of precedence. Since the manual states you should use parentheses a lot and gives examples where I'd normally not do that, I'm going to assume it does not do this. In essence, if I can insert parentheses to give a specific order of operations, so could GMS given a specific definition. As I wrote in a bug report I filed a while back, GML is its own language, and deserves to have an exact definition of things like this, that are possible to exactly define. Whether it is the same definition as some other language or platform doesn't matter, as long as it's strict and predictable.