Incorrect position update of background and barriers

[TheBoringEdward]

When moving the player far beyond the wrapping point of the background, the background and barriers will hitch and update their positions incorrectly.

I've added a print command to the part of the code responsible for updating the positions of the barrier. The following image is the output of that print command. As one can see, at a certain point the coordinates jump backwards to their starting positions. This error occurs several times, when moving the character. Will investigate further.

[TheBoringEdward]

JumpAndRun.GAME_INSTANCE.getGameHandler().getMap().getLastMiddleBackgroundX() This function/variable/whatever the hell you call it, appears to be the culprit. It is integral for the movement of the barriers, however, whenever it reaches the value of -615, it always jumps back to 0. My best guess, as to why does this, is, as its name might allude, that, as it always grabs the middle coordinates of the last background, whenever the background wraps back around, the getLastMiddleBackgroundX gets logically reset, causing the incorrect position update of the barrier.

[TheBoringEdward]

The boolean isMovingBackground appears to be dysfunctional. Always reports true...

[TheBoringEdward]

The boolean isMovingBackground appears to be dysfunctional. Always reports true...

player.getScreenPositionX() <= Player.MAX_LEFT_POINT_ON_SCREEN guess why ... It'll always fulfill this condition if at the edge of the screen, even if the background has stopped moving.

[GemueseHasser]

The boolean isMovingBackground appears to be dysfunctional. Always reports true...

player.getScreenPositionX() <= Player.MAX_LEFT_POINT_ON_SCREEN guess why ... It'll always fulfill this condition if at the edge of the screen, even if the background has stopped moving.

This is how it should work, as this is the state of whether the background SHOULD move. Then the method may be named incorrectly.

[GemueseHasser]

This is how it should work, as this is the state of whether the background SHOULD move. Then the method may be named incorrectly.

Or maybe we change the method so that it only returns True if the background is actually moving. You would have to test it, but that shouldn't actually lead to any complications.

[TheBoringEdward]

Or maybe we change the method so that it only returns True if the background is actually moving. You would have to test it, but that shouldn't actually lead to any complications.

Nah, I was just confused due to its name and tried to use it as a check, whether the bg is moving. Changed it to isBackgroundMovable.

[TheBoringEdward]

Made a sloppy attempt at band-aiding the issue, by adding a counter for the x-Coordinates. Not quite working as intended, as, once the barriers have passed the screen on the left, when you move left again, the barriers appear to be stacked ontop of each other, due to the counter getting reset for some reason.

Edit: German is hella difficult.

[TheBoringEdward]

Got a hunch, that the whole Xcounter not updating thing, might have something to do with the barriers being potentially unloaded, when leaving the screen, leading to their Xcounter values not getting updated. Have to check whether that's true first, tho.

[TheBoringEdward]

My suspicion has been proven right, as barriers just cease to exist, once past the screen at a certain point. Once they reappear (by some magical means), their Xcounter gets fudged up.

On second thought.... My way of approaching this issue might be flawed. If certain barriers start out on the first screen, their Xcounter values get updated with the same values, which might make it quite logical, as to why the barriers appear to be stacked, once they return to the screen. Will tinker with that idea...