That's normal. Mouse position is in pixels, and the mouse cursor can't be between two pixels.
Player position, however, can. It's both because of dt and because of the angle. Imagine you have to move 17 pixels right and 1 pixel up. *Even* if the X coordinate moved in integer steps of say, 1 pixel every frame, then the Y should move 1/17 pixel every frame. If your positions were integers and did not have a fractional part, you wouldn't know when you have exceeded the threshold that makes the vertical position change. (Bresenham's algorithm tracks using integers what the fractional part should be, but the essence is the same.)
Also, the distance is rarely integer. In the above example, 17 is only the horizontal distance, but since the vertical distance is not zero, the actual total distance is a bit over 17: it's sqrt(17²+1²) which is approximately 17.029386. Even if you walked there in perfect integer distances, you would always overshoot, because after walking 17 steps, you would not be there yet and you would need another step.
Finally, you're doing cumulative floating point operations, and each of them is rounded to the closest number representable in floating point, so they are subject to rounding errors, and you can't expect to land exactly in the final position for that reason alone (unless each operation produces an exact floating point number that doesn't need to be rounded, which in this case doesn't seem to be possible).
If you don't like how the texture is drawn at non-integer coordinates, you can round the sprite position in the draw command.
If you want to show the numbers for debugging purposes, you can use string.format:
Code: Select all
-- change this:
love.graphics.print(user.x.."/"..user.y.." ! "..tostring(movev), screen.w /2, screen.h /20)
-- to this:
love.graphics.print(string.format("%.2f/%.2f ! %s", user.x, user.y, tostring(movev)), screen.w /2, screen.h /20)
Code: Select all
if dot <= 0 then
movev = false
user.x, user.y = mpX, mpY
end