According to this article interpolation is needed to avoid stuttering and this seems to be true because removing the interpolation doesn't help. Maybe I should use the next position instead of the previous. I dont see any error in the way i am calculating the interpolation yet the movement of the sprite is not smooth. I tried putting some sleep calls and it does minimize the stuttering but it doesn't eliminate it completely.
It seems like there's way too much going on to accomplish not very much.
Interpolation is not a magical cure-all. It's just selecting a position between two endpoints.
1+1+1+0.5 = 3.5
So there's no reason to run a loop that adds to your total 1+1+1 times and then manually implements the 0.5 in the rendering because it's the halfpoint lerp value between 0 and 1.
Figure out the position of your sprite and place it in that position then render it where it sits. What you're doing right now is finding a position near where the thing is and then using interpolation to try and make it look like it is where it belongs.
If you want to re-invent floating point division that's up to you I guess, but this code tells lies all over the place. Your delta is not a delta, your position is not a position, your Render() is actually RenderSomethingSimilarButNotQuite().
As for that article, if you need pinpoint precision for positioning then the Runge-Kutta method is appropriate, but if you just let the star's position be its actual position then Euler will give smooth motion without the need to reinvent floating point division. Gaffer is using double precision and RK4 because he's probably thinking about large values in a large space, but for 'pixel per second' you can just use 'normal' Euler math. His use of a fixed 'delta' in that code progression is very misleading. The delta was a delta in the earlier code, but by the time he gets to the end it's just a scalar value for the frame time. The reason he's using interpolation is because he's separating physics simulation steps at specific points. Honestly when he gets to 'accumulator < dt' he should then feed accumulator into the physics instead of carrying it over to the next frame. There's no reason to do that in the code you have here since pixel-width is not high granularity. If you avoid having velocities that are ridiculously high then you should be okay without having to spoon-feed the simulation.
Even if you want to keep the loop for collision test dragging just let the position be the position and do away with 'accumulator' and 'p' and the messy game of 'catch-up'. If you want to interpolate a pixel-per-second motion with interpolation then set your velocity in terms of PPS and then get your delta T and put it in terms of a fraction of a second then multiply it by your motion.
Did you implement single-motion first and then move on to dragging?
Pseudocode:
[source]whatTickIsIt(&nowTime);
ticksPassed = nowTime - prevTime;
prevTime = nowTime;
secondsPassed = ticksPassed / tickHz;
position.x += position.x + (velocity.x * secondsPassed);
if(outOfBounds) {
//stuff
}[/source]
Meanwhile, putting this all in linear order and extracting irrelevant code I think I may see what's causing your stutter.
Try this:
lerp = (float)accumulator / UPDATE_TICKS;I really wish I had a compiler on this machine. A debugger makes it so much easier to find this kind of thing.
