Timeline for Why does my sprite jitter when it arrives at its destination?
Current License: CC BY-SA 3.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 8, 2011 at 19:00 | comment | added | dadoo Games | Read over my last comment again, slowly. We are talking about 2 different types of jitter. If you move to rendering only at integer positions (still storing positions as floats) then slow moving objects will jump from pixel to pixel at a not-smooth rate. The movement will be in steps due to the rounding from float to integers. Fast moving objects in this scenario have less issues, because they move more pixels in one update. For the original problem, yes, fast moving object will cause the jitter to be more obvious because it will overshoot by more in each direction. | |
| Dec 8, 2011 at 18:28 | comment | added | sam hocevar | @dadooGames: No it will not fix itself. And you will not have more jumpiness for very slow moving objects, but instead for very fast moving objects. The jitter is not caused by a float-versus-integer issue, it is caused by the failure to clamp the object displacement. Again, your solution does work, but your explanations are terrible and misleading, and this last comment of yours is an indication that you still did not understand where the jitter comes from. | |
| Dec 8, 2011 at 18:18 | comment | added | dadoo Games | Also, as pointed out above, if you track movement using floating point numbers and render to integer pixel positions the jitter will fix itself in most cases. You may have more jumpiness for very slow moving objects, but your other option is to render at sub-pixel locations which has its own set of issues (blurrines, etc) | |
| Dec 8, 2011 at 18:15 | comment | added | dadoo Games | I never said it was due to floating point precision issues, I said the difference between the goTo point and the current point will never be zero. So you will go past the target point, then back past it in the other direction over and over until you happen to get close enough that the jitter is not visible. How long this takes depends on a bunch of factors, not limited to the speed of the moving object, the framerate, etc. | |
| Dec 8, 2011 at 16:58 | comment | added | sam hocevar |
I am afraid using integer numbers will not work. You will not get sufficient precision for diagonal movements. Also, I believe you did not understand the problem exactly: dadoo's solution in the second paragraph is correct, but his explanation in the first paragraph is just plain wrong. The jitter is absolutely not caused by floating point precision issues. The jitter would be smaller that a billionth of a pixel. The problem, as I said, is not that you never reach goTo, it's that you go past goTo.
|
|
| Dec 8, 2011 at 16:26 | vote | accept | Graham M | ||
| Dec 8, 2011 at 16:26 | |||||
| Dec 8, 2011 at 16:26 | comment | added | Graham M | Thank you for your input! The framerate issue is something which I will definitely take into consideration. I did have it stopping when it reached its destination, but because of the floating point maths behind it all, it was only occasionally "spot on". I will look into the length of the vector as some side research, but as my project is very simple I might try the method from dadoo about using non-floating point numbers to start with! Thank you for your help! | |
| Dec 8, 2011 at 16:04 | history | answered | sam hocevar | CC BY-SA 3.0 |