Add conditions/expressions to get AABB coordinates in events

[4ian]

In the Stay On Screen extension (see GDevelopApp/GDevelop-extensions#298), we would have needed the bounding boxes of the object to properly handle the cases where the object origin point is not 0;0.
More generally, I remember another extension where AABB would have been needed (@Bouh @Silver-Streak @tristanbob - remember which one? I think we end up using JS events to access the AABB).

So I'm thinking, should we expose some expressions to get the bounding box coordinates? I see this like this:

• Expressions (and conditions) X()/Y() are still there as usual to give the X;Y position of the object, which means the X;Y position of its origin point (which can be changed for sprites).

• Expressions (and conditions) Width()/Height() are unchanged - and still useful.

• Expressions (and conditions) CenterX()/CenterX() are also unchanged. Note that the "center" point can also be moved in an object (only sprites for now). So this is to be understood as "center of rotation".

• We would have 4 new expressions (and maybe conditions): BoundingBoxLeft, BoundingBoxTop, BoundingBoxRight, BoundingBoxBottom. Maybe also BoundingBoxCenterX and BoundingBoxCenterY.

The names are fairly long (though I did not put "axis aligned" in the name!), but they are also showing that this is more for an advanced usage. Note that for an unrotated object, this bounding box has the same widht/height as the object... but this is not the case if the object is rotated.

This also means that the BoundingBoxTopLeftX/Y can change even if you're not moving the object. Rotating an object can indeed modify its bounding box (see getAABB and updateAABB in the game engine).
But this means that we will correctly ensure that rotated objects are properly handled in extensions that are doing things like ensuring an object is in an area.

Let me know what you think of this. Also pinging @D8H and @arthuro555 who might have an idea about this.

[D8H]

I remember another extension where AABB would have been needed (@Bouh @Silver-Streak @tristanbob - remember which one? I think we end up using JS events to access the AABB).

It was something like "is on screen". Bouh did the JavaScript.

* We would have 4 new expressions (and _maybe_ conditions): `BoundingBoxTopLeftX`, `BoundingBoxTopLeftY`, `BoundingBoxBottomRightX`, `BoundingBoxBottomRightY`. Maybe also `BoundingBoxCenterX` and `BoundingBoxCenterY`.

Why not just:

• BoundingBoxLeft
• BoundingBoxTop
• BoundingBoxRight
• BoundingBoxBottom

[arthuro555]

+1

[4ian]

Totally! Updating my original post.

[tristanbob]

Having native access (non-javascript) to the bounding box is a great feature. I would use it in a few extensions, including these:

• Values of multiple objects (pending review)
• Room based camera movement (pending review)
• Follow multiple objects with the camera
• Screen wrapping
• Align object on the screen

[4ian]

I've made a PR here: #3275, let me know what you think of the interface!