Sprites other than 16x16 move unsmoothly?

To get some better practice with MakeCode Arcade sprite movements and animations, I have recently been playing around with the following help request from @jaturn68.

What I might have discovered(at least on my computers and browsers), and which baffled me, is that using the regular controller.moveSprite(vx, vy) function on a 16x16 sprite gives silky smooth movement on the x axis with any sprite image and at arbitrary vx speeds, while movement gets choppy for irregularly or different sized sprites, like 15x17 and 17x17.

To test and compare movement for differently sized sprites at various speeds, I made a small program with a 15x17 sprite for player1 and a 16x16 sprite for player2, where one can also change vx speed for both by pressing the A button:

Note:
-The uneven 15x17 sprite of player1 coincidentally(?) moves pretty smoothly at vx speeds 50, 100 and 150, but not at other speeds…
-This Sonic game, however, does not exhibit as clearly choppy movements if one changes its 21x27 sprite to other vx speeds than multiples of 50.

What am I doing wrong here or I do not understand? Is there a way to overcome choppy movements for sprites of other sizes than 16x16 and at any speed?

2 Likes

Filed:

make the sprite a paire size

1 Like

Yep, very choppy, don’t know why

1 Like

Thanks for the input, @YuHayate!

You are right, the deciding criteria for smooth horizontal movements appears - after having tried a couple of more alternatives based on your answer - to be even sprite sizes for width(x) X even/odd for height(y).

Here’s another example with 18x17 and 16x16 sprites, respectively, and both moving smoothly.

I will update the GitHub issue accordingly.

Is this a bug or a feature? And why is it like this?

2 Likes

Now I get why the floors on Floor 13 were moving unsmoothly :expressionless:
I’m pretty sure making something move too fast makes it choppy as well

2 Likes

When you first posted this, I was going to make an intricate thing to explain it, but I never ended up posting it.
why? Well, I have a history of AI looking posts, so i don’t want to post anything anymore in fear of being called out for it again even tho i dont use AI much
well anyways

2 Likes

it has choppy movement we just don’t see it because the sprite can stay in the middle of the screen if its diminutions allow it
if you want some way of knowing with math you can use
mod(screenWidth,SpriteWidth) == 0
if it outputes true then ou will have smooth movement otherwise yea

other way:
if the screen with is pair then the sprite width has to be pair too
same thing for odd screen size

3 Likes

How I understand it is: because the sprite can never be in the exact center of the screen with an odd X, the camera doesn’t update its position when the sprites is right or left of the center, but only moves when the sprite gets 2 pixels away from centered. So the sprite goes from one side of the middle to the other repeatedly instead of the camera making the sprite centered every time. (Does this mean you could fix this by writing your own camera movement code instead of using the [camera follow] block?!? I have not tested it.)

1 Like

I believe this has been fixed already:
https://github.com/microsoft/pxt-arcade/issues/6115

I also have some faint memories of testing it ok using my example in the original post, but forgot to update this thread.

1 Like

never fear, brainstorm is here. what you need to do is make an invisible body sprite that handles all the physics and has a different sprite kind than the main sprite, which handles all the animations. i would recommend making the body sprite kind “player” and adding a custom “display” kind for the main sprite, and setting the body sprite to invisible and the anim sprite to ghost.

3 Likes