jorotroid
Member
This is probably only relevant to anyone doing a game without the built-in HUD that includes moving up and down screens. If you set the play area of the game to encompass the full screen, then when your player transitions to up a screen, you will instead warp down a screen. This happens because the game checks to see if your position is greater than the value for the top bounds, if not, then it executes the up transition. But if the top bounds is set to zero, when you cross that boundary, you position loops around and by the time it does the check it sees that you position is now at the below the visible screen (which is greater than zero), so it moves on to do the bottom check and sees that you are past the bottom bounds, so it transitions down a screen. Here is what I did to fix it for now and what is still not quite right about it.
I had a real hard time figuring out a way to distinguish between a negative signed value and an unsigned value that is greater than 127. What I ended up doing is adding 127 to the y position before adding velocity and checking the Overflow flag to determine if the position crossed 0. To do this, open up the CheckPlayerCameraPosition MACRO script and go down to line 31 where you will see the following:
Replace that code with this:
This will make the upward screen transitions mostly work as expected now. But there is one drawback. If you have any platforms near the top of the screen such that the top of your player will poke over to the bottom of the screen while standing on that top platform, the game will keep on swapping up and down a screen until you move the player elsewhere. To avoid this issue, just don't placing platforms too high. If your player is 16 pixels tall, then avoid placing platforms in the top two rows. If 32 pixels tall, then avoid the top 3 rows. You can have solids there, just nothing that the player can actually stand on.
Hope this is useful to somebody
I had a real hard time figuring out a way to distinguish between a negative signed value and an unsigned value that is greater than 127. What I ended up doing is adding 127 to the y position before adding velocity and checking the Overflow flag to determine if the position crossed 0. To do this, open up the CheckPlayerCameraPosition MACRO script and go down to line 31 where you will see the following:
Code:
LDA Object_y_lo,x
CLC
ADC Object_v_speed_lo,x
LDA Object_y_hi,x
ADC Object_v_speed_hi,x
CMP #BOUNDS_TOP
BCS notAtBoundsTop
Replace that code with this:
Code:
LDA Object_y_hi,x
CLC
ADC #$7F
STA temp
LDA Object_y_lo,x
CLC
ADC Object_v_speed_lo,x
LDA temp
ADC Object_v_speed_hi,x
BVC notAtBoundsTop
This will make the upward screen transitions mostly work as expected now. But there is one drawback. If you have any platforms near the top of the screen such that the top of your player will poke over to the bottom of the screen while standing on that top platform, the game will keep on swapping up and down a screen until you move the player elsewhere. To avoid this issue, just don't placing platforms too high. If your player is 16 pixels tall, then avoid placing platforms in the top two rows. If 32 pixels tall, then avoid the top 3 rows. You can have solids there, just nothing that the player can actually stand on.
Hope this is useful to somebody