smooth subpixel movement limits
Moderator: Moderators
smooth subpixel movement limits
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
Re: smooth subpixel movement limits
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 futurenia-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
- Controllerhead
- Posts: 314
- Joined: Tue Nov 13, 2018 4:58 am
- Location: $4016
- Contact:
Re: smooth subpixel movement limits
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
Super Mario Bros gets away with 16 "subpixels" for X movement, and the result is, well, Super Mario Bros =p
Re: smooth subpixel movement limits
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.
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!
Re: smooth subpixel movement limits
If subpixel movement is jittery, it means you need rounding instead of cutting. 0.6 -> 1 instead of 0.
- gravelstudios
- Posts: 159
- Joined: Mon Mar 13, 2017 5:21 pm
- Contact:
Re: smooth subpixel movement limits
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.