shaunjs
patreon
Bounding box change in GameMaker Studio 2 version 2022.1
🕑 Added 2022-01-28 13:59:37 +0000 UTCHello everyone, big changes in the latest version of GameMaker! Video(s) coming soon, but here's some info regarding an important change to bounding boxes:
Previously, bounding boxes were always rounded to integer positions that were "exclusive" at the far sides. That is to say a 16 pixel square mask placed at an x/y of 0,0 will have the following bounding box coordinates:
As you can see, the position 15,15 *does* represent the bottom right pixel of the mask, however it more technically represents the top left *of* that pixel. As 15.5 for example would be half way across that pixel. That's what is meant by an "exclusive." coordinate. This all works very well as long as you only move at integer positions, something I've always recommended across my tutorials for this reason. The moment you start scaling and rotating or moving at non-integer positions you end up with a lot of situations where these masks are not precise enough and you can easily end up with sprites rendering overlaps while no collision is detected. As of this new version, bounding boxes will be calculated using floats rather than integers and will be "inclusive" of their far sides. So that same square mask will have the bounding box coordinates:
As you can see each coordinate is a "real" number or "float" rather than an integer as they can have decimal places. Also the right and bottom edges are now "inclusive" of the full mask. This also means that bbox_right - bbox_left is now equal to the true width of the mask. This has been done to better allow a mask to move and be transformed using non-integer values and be generally more accurate and precise.
However! This will cause some issues with old ways of checking for collisions when using bbox_right and bbox_down. As now when a mask is flush against another, the bbox_right value of the first mask is identical to the bbox_left value of the other mask.
Apparently, a tolerance value is applied so that situations like this won't "register a collision" and will require a distinct overlap. It's sadly not entirely clear exactly what functions and checks this applies to at this stage, and I'll comment if I get more clarification but my guess is that this is applies to checks like place_meeting, collision events and anything that directly compares one bounding box to another, rather than checking a distinct position. So you'll find collisions using most functions work the same unless they use bbox_values as inputs. However if you do rely on position checks using bbox_right and bbox_down you're likely to run into off-by-one problems where small gaps appear in your collisions such as if you follow my old slope collision tutorial. It's possible this could all change further so be vigilant and read the release notes as they appear.
If you're now panicking about how this affects your current project, do not worry. This version ships with a compatibility mode flag you can enable in global game settings. I'm told this would be on by default in current projects but I would check to be safe. This reverts the behavior by rounding the bbox_positions and making them "exclusive" again so if you're deep into a project you can use the old behavior.
Going forwards obviously I would try not to turn this on for every new project and would try to learn how to work with what should hopefully, be more accurate and robust bounding boxes.
Hope that helps!
-S
