This is an alternative way of fixing a glitch in Sam's game that I described in #1430. This fixes the glitch by calling the object following helper during the initialization of the views prior to the create or start events. It also required moving the view/window/screen initialization after the creation of objects and just prior to the firing of their create events.
Testing it with this pr shows the fix here does not behave anything like GM. This pr has both views at position (7,7) during the create/start events but GM8.0 and GMSv1.4 do not and have both at (0,0).
Josh said about this:
then toast it; anyone who asks for that information can get it by the proper venues
if someone wants to know where the view is, they want the most correct info
they can hard-code a 0 or reference view_w/hview otherwise
not the PR; toast the GM behavior
@@ Coverage Diff @@ ## master #1435 +/- ## ========================================= + Coverage 16.74% 16.9% +0.16% ========================================= Files 164 164 Lines 17095 17098 +3 ========================================= + Hits 2862 2891 +29 + Misses 14233 14207 -26
|Impacted Files||Coverage Δ|
I should mention, now that I have #1430 ready for you to review, I don't know about this pull request at all now. The object following actually shouldn't be updated if views are not enabled or the view is not visible, neither of which is being checked by this initialization loop. I should perhaps change this pull request.
We can close this, it's not actually what GM does. In fact, it introduces more inconsistency that may make compatibility worse, even if you do consider it the technically correct thing to do. TKG was happy enough with #1430 because it made us GM compatible.
A good reason to not make this change here is because the user may want the camera to slowly transition to the player while showing either some introductory/prologue or epilogue credits. If they truly want the camera to start at the followed object, then they can move it there themselves, just like in GM.