Constrained actors not stopping instantly as THEY SHOULD!!!
So, in my "runner," I have the Hero actor that dashes through a 25000 pixel wide scenario. I have a HUD in which these "HUD" actors are constrained to the invisible "camera that follows hero actor" When I press my custom made PAUSE, everything stops instantly as it should BUT, the constrained HUD actors shift like 20 pixels to the right and stay there... then when I unpause, they go back to their correct position (as they are in motion now).
My pause is custom built; all actors are linked to a universal PLATFORM SPEED, and when I press PAUSE, the universal PLATFORM SPEED instantly becomes 0.
I'm sure there are a million things to explain and info I'm not including, but, does anyone see this issue as common and have some quick suggestion/fix?
So, basically, constrained actors are not staying true to their "oath" when I pause, for they shift like 20 or 30 pixels to the right (X), breaking their constrained "oath" so to say.
Comments
What position, in the layers is the HUD ?
What position in the layers is the code that makes the camera move ?
What position in the layers is the instruction that makes the camera stop/pause ?
@Socks Let me check/play with that! thanks, will get back.
@Socks, question... is there a specific order that they should be in?
@Socks
What position, in the layers is the HUD ? Way at top
What position in the layers is the code that makes the camera move ? Furthest down (same actor that has "instruction that makes the camera stop/pause")
What position in the layers is the instruction that makes the camera stop/pause ? Furthest down (same actor that has "camera follow")
GameSalad scans the layers from bottom to top, as it encounters each actor within each layer, it scans the code within that actor from top to bottom, it then moves up (through the layers) to the next actor and again scans the code within that actor from top to bottom . . . and so on . . . finishing with the final actor right at the top of the stack . . .
Once this whole process has been completed when GameSalad has scanned the topmost actor - hopefully (and usually) taking 1/60th of a second - it pieces together the finished frame based on all this information and displays that frame on your device (iPad, iPhone . . and so on), it then moves onto generating the next 1/60th of second frame through the same process.
@Socks Thank you Obi-One-KaSocks
Great piece of info there. Ok, so this means I must cut down on the amount of codes or something?
@Socks I only have 2 layers by the way.
Top layer: 80 actors
bottom layer: 20 actors
No, I was thinking it might have been a layer issue, that as GS prepares the frame it is generating the location for the HUD, and then being told to move the camera - and then placing the HUD . . . the result of which would be that the HUD would be offset.
@Socks case solved!!!
Ok, so I UNLOCKED my ACTOR whom the camera follows... TURNED OFF "Camera Follows" and Constrained Scene.Camera.Origin X and Y to self.pos X and Y. I think the game is running smoother with this if I'm not mistaken, which made me shed a tear of joy. (I found this method in one of @JohnPapiomitis posts I believe, THANKS!)
Then, I unlocked the PAUSE button (HUD actor) and placed him on top right by constraining him to Scene.Camera.Origin X and Y (with an offset of course). So now when I pause, it doesn't add extra nudges to the right as it used to
The following formulas take care of ZOOMING IN in the scene while keeping HUD same size and position. (Yes, my levels/missions have a "zoom-in" effect in the beginning)
Glad you sorted it out !
TIP: Better have a non-action-useless actor unlocked somewhere in the game scene, and use him to constrain all scene.attributes to some game.attributes... that way you don't have to unlock every actor to have access to these scene.attributes... perhaps this is obvious but anyways, it's clearer now than before.