smooth subpixel movement limits

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems. See the NESdev wiki for more information.

Moderator: Moderators

Post Reply
User avatar
nia_prene
Posts: 17
Joined: Sat Dec 04, 2021 2:50 pm

smooth subpixel movement limits

Post by nia_prene »

It appears that moving an object by half values diagonally seems to be the limit. I tried a moving a bullet a half pixel on one axis and a quarter subpixel on the other axis and it is very jittery. Any way around this? I'd ideally like to get a bullet pattern with 12 bullets blooming outward like hands of a clock at a half pixel rate but the jittery movement is something I cannot abide. I can get an 8 directional movement at 1 half px speed but I would like the 8 or 12 bullet bloom at half pixel. Totes understand if that just isnt possible without jitteriness, just seeing if the experts found a way around this
User avatar
nia_prene
Posts: 17
Joined: Sat Dec 04, 2021 2:50 pm

Re: smooth subpixel movement limits

Post by nia_prene »

nia-prene wrote: Sat Jul 03, 2021 2:20 pm It appears that moving an object by half values diagonally seems to be the limit. I tried a moving a bullet a half pixel on one axis and a quarter subpixel on the other axis and it is very jittery. Any way around this? I'd ideally like to get a bullet pattern with 12 bullets blooming outward like hands of a clock at a half pixel rate but the jittery movement is something I cannot abide. I can get an 8 directional movement at 1 half px speed but I would like the 8 or 12 bullet bloom at half pixel. Totes understand if that just isnt possible without jitteriness, just seeing if the experts found a way around this
it seems that just the 1/2 px by 1/4 px movement was jjittery, and things smoothed back out at 1/2 px by 1/8 px, and even smoother as the values further divided by 2. I feel it is an acceptable jitteryness, given the desire for a complex pattern, and I will leave this up for people in the future
User avatar
Controllerhead
Posts: 314
Joined: Tue Nov 13, 2018 4:58 am
Location: $4016
Contact:

Re: smooth subpixel movement limits

Post by Controllerhead »

I use two bytes for object and camera coordinates for both X and Y. One for pixel position and another for "256 subpixel values". The result is smooth as butter (relatively). An entire byte of subpixel values for each coordinate is a bit of overkill but the math is fast. There's no precision limit theoretically, but, i don't think any further precision would be necessary or wise.

Super Mario Bros gets away with 16 "subpixels" for X movement, and the result is, well, Super Mario Bros =p
Image
User avatar
Dwedit
Posts: 4924
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Re: smooth subpixel movement limits

Post by Dwedit »

If you want to be *really* crazy, you can use base-180 for your subpixel byte instead of 256. Then you can evenly divide 2,3,4,5,6,10,12,15,30,36,45,60,90 instead of powers of 2.

Not that hard to do either. Add to fraction byte, compare with 180, that gives you the carry bit for the integer part, and you can branch off to the case where you fix up the number by subtracting 180 from the low bit.
Negative numbers might be harder though.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
calima
Posts: 1745
Joined: Tue Oct 06, 2015 10:16 am

Re: smooth subpixel movement limits

Post by calima »

If subpixel movement is jittery, it means you need rounding instead of cutting. 0.6 -> 1 instead of 0.
User avatar
gravelstudios
Posts: 159
Joined: Mon Mar 13, 2017 5:21 pm
Contact:

Re: smooth subpixel movement limits

Post by gravelstudios »

I also use one byte for the pixel value and one byte for subpixel value. I do this for both position and speed. It always seems to look very smooth. in a few cases to save space, I use one byte for speed values where one nibble is the pixel value and one nibble is the subpixel value. (including the sign bit) it's pretty unusual for an object to move more than 7 pixels per frame, and then you have 16 subpixel values which seems like more than enough to me, but programming it that way is a little more complicated.
Post Reply