So one thing that was kind of left on the table was fixing the axe passing through the bottom of the screen (because the axe’s y position is it’s top left corner).
I tried changing the code for moving the axe to:
Tested this out with the master project for the course. And the issue is an order-of-operations issue.
Since bottom_axe_y is being calculated before the axe is moved, it’s always one frame behind. So once it gets to the bottom of the screen it’s going to get it’s direction flipped a little too late and not be able to get from under the bottom of the screen before it flips direction again.
There’s viable two solutions to this:
Reverse the order of operations so that axe_pos_y is calculated before bottom_axe_y, this has the side benefit of collisions being more frame-accurate
Add a line in inside of the if-statement so that it not only flips axe_direction but also sets axe_pos_y to the bottom edge of the screen. But only if it’s reached the bottom.
Personally, option #1 feels like the more elegant solution here. Since it also resolves a second bug that isn’t easily noticeable at first glance.
Do you mean operations within the while loop? Because axe_pos_y is first calculated (or set) before the loop starts where we are defining the variables.
Should I move the code that updates the axe edges (in the while loop) after the code to move the axe?
I tried that and it doesn’t seem to make a difference.