Camera Following Target Instance Should Regard Its Collision Mask

[ParodyKnaveBob]

Is your feature request related to a problem?

In issue #4529, I ask the question that brings all this together:

Does the camera care about its target instance's x and y or its mask_index?

When using the Room Editor or the camera_set/get_view_*() functions, following a targeted instance is entirely asymmetrical unless (easy answer) one centers the sprite origin for the target's collision mask or (difficult answer) jumps through hoops to dynamically change the border depending what direction the instance moves within the room.

For simplicity, let's say there's a camera with horizontal and vertical borders of 32 set to follow a 32x32 instance.

If one centers the origin, no big deal, the bounding box will get some 16 px from the sides and corners in all directions. If one keeps the origin at 0,0, however, or changes the origin to center bottom, one has to fight in every direction.

16,16 - Stays 16 px from the left, top, right, and bottom. 0,0 - Stays 32 px from the left and top. Sticks plumb to the right and bottom. 16,32 - Stays 16 px from the left and right. Stays 32 px from the bottom. Sticks plumb to the top.

Never mind if one has an asymmetrical sprite/origin to boot.

To keep these measurements in place, one must change the camera_set_view_border() when moving in different directions -- or one can simply forego using the camera target altogether and manually adjust the camera_set_view_pos() every step of the way.

Why have an entire system built into the Room Editor GUI and IDE/Runner if it requires one sprite-style to effectively use (center everything), making it unfriendly to newbies and old hats alike? Unfriendly == unused. I see plenty of advice instead telling people to create a sprite-less object purely for hacky camera following (or to manually change the cam's x,y position every step).

Describe the solution you'd like

Change the camera targeting system to look beyond mere x and y and start using that intuitive mask_index.

If there's no collision mask (such as no sprite assigned), then x and y it is, great -- but if there is a collision mask in use on the instance -- which would seem to be the number 1 desired use case anyway -- please take it into account so that the expected bbox_* values will intuitively push around the camera's border accordingly.

If you implement this, I figure I would also expect, upon the moment a camera is told to target an instance (via natural Room Start or some GML instruction), that a camera would target the mask's calculated center and not merely the instance's x,y.

Additional context

Technically, #4529, x,y vs. mask_index isn't even documented. Instead of a Feature Request, I 100% considered calling this a Bug Report -- operation not matching user expectation. $;^ ]

Afterthought: I highly doubt implementing this request will change much for current projects across the board. (Exceptions? Always. Rule?) Those who currently use this feature surely are already using centered (or sprite-less) objects in order to avoid the hassles.

[attic-stuff]

i definitely agree that the manual could be updated to explain the camera tool much better, but i disagree that this behavior needs to change or that it is unclear. the tool says "object following" and an object's position is its x and y, so it stands to reason that the camera would follow that object's x and y position.

that the camera would need to follow a calculated position rather than an explicit object position would be, imo, more confusing than the current behavior unless the tool changed to explicitly say that behavior in the room inspector. that would also be a more "advanced" camera operation, and like much of gm once you wanna get advanced then you gotta get into code.

also that change would be a far bigger wave of repercussion than you think it would. anecdotally, in my experience bunches of crunches of people actually use that tool to follow a sprite-less/mask-less cursor object to let them flip between mouse/gamepad based looking.

[ParodyKnaveBob]

@attic-stuff: Follow x, y, yes, but the border is the big issue. As for your concern about waves and repercussions, my last statement was as follows:

Those who currently use this feature surely are already using centered (or sprite-less) objects in order to avoid the hassles.

That's exactly what you described. There would be zero change there. Cheers. $:^ J

---

EDIT: Actually, I wanted to respond to this, too:

that the camera would need to follow a calculated position rather than an explicit object position would be, imo, more confusing than the current behavior unless the tool changed to explicitly say that behavior in the room inspector. that would also be a more "advanced" camera operation, and like much of gm once you wanna get advanced then you gotta get into code.

The current behavior already is needing to follow a calculated position -- unless, once again, you give the object a centered sprite origin or no sprite at all. The current behavior is already "advanced." The changed behavior would allow one to rely on the Room Editor exactly as the Room Editor GUI already stands -- no reworking there, and no extra GML necessary from the user -- to let the masked instance move around inside the camera until its mask (and not merely its x,y -- unless obviously it has no mask) bumps against the border of the camera, at which point the camera moves with the instance as expected.

[Alphish]

Another option to consider would be having different modes of camera following;

• follow position (current one) - camera follows x/y coordinates of the followed object
• follow sprite - camera follows the sprite area (so the left part of the sprite "pushes" camera left, top part of the sprite "pushes" camera up, right part of the sprite "pushes" camera right, bottom part of the sprite "pushes" camera down)
• follow bounding box - camera follows the bounding box area (just like with sprite, each side of the bounding box "pushes" the corresponding camera's side)

Then to prevent revolution, it would default to the current "follow position" behaviour, but people would be able to easily switch to another one as needed. Another option to consider would be having "follow sprite" and "follow bounding box" by default (or maybe even allow the user to set their default behaviour), but still set "follow position" when converting old projects for that backwards compatibility.

If any other behaviour is chosen but the object has no sprite/bounding box, it would fall back to "follow position" behaviour.

[RefresherTowel]

I think Alice's suggestion would definitely be the way to go if this is implemented.

[attic-stuff]

deffo, appending to the existing use instead of outright changing it would be much better

[ParodyKnaveBob]

If appending is the only way to get it implemented, then of course I'm for that, but fwiw, I suggested replacement instead of addition because 1. the less complexity YYG/GM has to deal with under the hood, the better, and 2. I see no special need for backward compatibility:

• If you use an instance with no sprite, there will be no change.
• If you use an instance with a fully centered sprite origin, there will be no change.
• If you use an instance with any other sprite origin, then you either have asymmetry (unlikely to be desired) or a gauntlet of hoops you've already jumped through. I can see the one lone hoop-jumper being simultaneously glad that one no longer has to deal with the convolution but sad that one already jumped through the hoops and now needs to unset all that. Realistically, though, who actually currently instructs a camera to auto-follow an instance with any other sprite origin? (It would be amazing if YYG had stats on that.) Wouldn't practically all folks either 1. desire it to work more symmetrically (thus benefiting from the change) or 2. have already added an invisible camera target to follow (thus seeing no change to one's project) or 3. have already written manual camera x,y changes to imitate following a target (thus seeing no change to one's project)?

Again, if people want all that, cool. I just thought I'd save YYG hassle by advising, "change it with no need for backward compatibility" because it's not the first time a change would break things, and this change would break very little (as already stated in various ways). Different camera-follow modes would require a change to the Room Editor GUI and more GML functions/actions, but if that's what's wanted. ::shrug::

---

I'm super curious about Alice's suggested different modes.

• I totally get why one would want to automate following an x,y only. Long live the x,y only (if no mask).
• I obviously also get why one would want to automate following a collision mask, so to speak.
• I don't see a clear use case for wanting to automate following an instance via its sprite pixels in lieu of a mask. In my mind, this can be accomplished using a mask just as well. It sounds (to me so far) like a thought exercise more than a useful technique to ingrain into the engine. What's the people's use case I'm missing on this one?

[attic-stuff]

I don't see a clear use case for wanting to automate following an instance via its sprite pixels in lieu of a mask. In my mind, this can be accomplished using a mask just as well. It sounds (to me so far) like a thought exercise more than a useful technique to ingrain into the engine. What's the people's use case I'm missing on this one?

if you want the camera to follow a specific object who's mask is changed dynamically for whatever reason like flopping masks on the fly for various hitbox or hurtbox reasons, plus it'd mitigate whatever nastyness the impending ability to turn collisions on and off by switching mask index to -1 could cause. this would keep you from having to have another mask index in the pipe just for dealin' with the camera.

[Alphish]

The reason for suggesting sprite-based camera movement is because both camera and sprites are about what the player sees, not the underlying gameplay mechanics/physics. In platformers in particular, the player character collision mask tends to be slightly narrower than the sprite to avoid phenomena like standing on air next to ledge or something similar.

Note that I didn't plan it to be strictly sprite pixel based - it might take into account sprite's own bounding box, which might be different from the custom-set collision mask bounding box. But I think it makes sense to provide an option to have the camera follow the player based on the visual element like the currently displayed sprite, rather than mechanical element like the bounding box of collision mask.

[ParodyKnaveBob]

Sold, ty.

(Sometimes, sprite can actually be simpler than mask. True, got it.)