VBLANK player movement problem

[rfunes]

Hi Friends,

 

I update my player0x and player0y variables in inside the VBLANK session. I do this as my code is complex and using VBLANK has been great to avoid going over the cycle limit.

 

I noticed that when my player0 sprite is moving diagonally (for example: down and right at the same time), even though I update both its player0x and player0y variables at the same time in the same frame, when debugging in Stella (especially visible when slowing down Stella to 10% speed: press Ctrl+Shit+S), I see that the sprite is first moving down, and only after that movement is complete it then moves right, instead of moving down AND right at the same time.

 

This creates an "stairstep" effect when moving diagonally.

 

Debugging in Stella, I see that my code is correctly updating both coordinates at the same time.

 

Have you seen something similar in your games? How can I avoid this stairstep effect? I want a smooth diagonal movement, and this stairstep creates a "jitter" in the sprite movement.

 

EDIT: Just noticed that in the RT tutorial, it mentions in the VBLANK section: "Note that running code here means that certain changes won't take effect until the next drawscreen. Particularly, changing x-positions of objects or the score will be delayed." which seems to be my problem. Is there anything I can do to avoid/hide this delay?

 

I also had an issue when positioning the ball object in VBLANK. The problem was that even though I was hiding the ball object by moving it to coordinates 255,255, the ball would briefly appear for a single frame in the screen. I solved it by moving the code out of the VBLANK section, but that was a smaller code with little impact on my cycles.

 

Edited May 26, 2022 by rfunes

[orange808]

You are updating the variable associated with the horizontal position after the kernel has positioned the VCS objects. Just for clarity, this is not a bug; it's because you changed the value of the variable after the position of the VCS objects were set. Essentially, you really are changing the position in the next frame.

 

"Getting around it" would require dropping to assembler (and probably changes to the batari Basic code as well). That will take you out into the weeds.

 

TLDR:  You have to work around this and make sure you have updated the "x " positions for your VCS objects before VBLANK. There's no reasonable way to change it.

Edited May 26, 2022 by orange808
Only the X position. The kernel checks the y position during scanout.

[rfunes]

Thanks, I fixed it by doing the X and Y coordinate calculation inside VBLANK, but actually applying the movement to the player0x and player0y variables on the main loop (outside VBLANK).

 

I suppose that was the same problem that I had with the ball object as well.

 

This is a pseudocode of how I am doing it now, which fixed the issue:

 

__main_loop

 player0x = _pos_x

 player0y = _pos_y

 drawscreen

 goto __main_loop

 

vblank

gosub __movement_calculation ; returns the new position in "_calculation_x" and "_calculation_y"

_pos_x = _calculation_x

_pos_y = _calculation_y

return

[+Karl G]

I don't have more to add, but I discovered this issue as well when developing Space Game. Using vblank for extra cycles is handy, but as you discovered, you need to update your positional variables in your main code to avoid these kinds of oddities.