So here is a question I have. There is this common issue in Pico-8 that comes up when you move things on the screen diagonally. If the vertical/horizontal speed is not an integer number the moving object will exhibit a jagged, jittery motion. This is due to the fact that Pico-8 doesn't do sub-pixel rendering. So the coordinates of objects snap to integer positions. In certain cases this leads to a kind of "stair-step" trajectory that can look very jittery.
My question: is there a good workaround to deal with this phenomenon? It is not always possible to use integer values for movement speeds after all.
So I think that particular issue that you are having only happens when the step size is a negative power of two. (ex: 1/2, 1/4, 1/8, etc)
In this case, you start at an exact coordinate. Subtract half from one and it rounds down. Add half to the other and it stays the same after rounding down. Step again and you reverse the behavior. One rounds to the same value while the other goes up a value. If you make the step size 0.5001 it won't have the issue.
If Pico8 used infinite precision rational numbers, you'd have the same problem for 1/3, 1/5, etc, but since they are converted to a fixed precision binary number, the values end up not being exact and the problem goes away.
There is probably some sort of dithering you could apply to either the velocities or the positions that might help solve the problem in general, but I'm not sure.
It's a pretty hack-y solution, but if you are certain something is always going to move at a speed of one pixel every 2 frames (and subpixel collision checking or whatnot isn't important) you could simply update it once every other frame.
@Krystman -- to alleviate this problem, you'd have to write your own sub-pixel plotter using a look-up table. I took a rough stab at it below. (Also helps to be running at 60fps.)
Oh, hrm. I guess that might be "technically correct" for (0.3, -0.4), though it's certainly undesirable.
What about Bresenham's line algorithm. I forget how that work off the top of my head, but it seems like it might be relevant here. Since you are tracing movement over time instead of across space, you'd probably have to store the error in addition to the position. I might try coding that up for fun this weekend.
[Please log in to post a comment]
