Jump to content

VBLANK player movement problem


Recommended Posts

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 by rfunes
Link to comment
Share on other sites

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 by orange808
Only the X position. The kernel checks the y position during scanout.
Link to comment
Share on other sites

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:



 player0x = _pos_x

 player0y = _pos_y


 goto __main_loop



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

_pos_x = _calculation_x

_pos_y = _calculation_y


Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...