An issue of correcting walking destination

[Crimson Wizard]

I'm posting in this general tech section to be able to gather more opinions (maybe people look here more often than in "engine development"?)

I will have to explain something first, so please bear with me.

AGS historically has a hidden problem: its pathfinder and walking algorithm uses math with relatively low precision. This may result in rounding mistakes. What this means in practice is that under some circumstances the "movement direction" (vector) is slightly off, e.g. more towards X than Y (or other way). In such case the character may reach the X destination while Y destination is still few pixels away. This difference mostly depends on the walk length. By experiment, I think, in 320x200 area it rarely exceeds 2-3 pixels, but in larger areas (walking fully across a scrolling rooms, or walking around high-res rooms) it may actually be bigger, like 5+ pixels.

In AGS 4 Alan Drake had changed the math to use proper floating-point math, which seems to improve this situation (but I did not experiment much with that yet).

In the AGS 3.* branch I am afraid to make such change, because of the backwards compatibility with games, which may be scripted to depend on how character walks exactly (that is unfortunate, but ags 3 is still used to run these old games, as well as its scummvm port).

How is this issue solved currently in AGS (and for a long time):
When AGS finds out that one coordinate is complete, but another is not (for example X done and Y is still not reached), it starts waiting until character reaches Y, but also accepts a certain "mistake", in 2-3 pixels.
If character is already within 2-3 pixels from the destination, then it just stops. This makes its real stopping point inaccurate, but nothing else happens.
However, if character is further away, then it keeps "walking", but because the movement vector is still pointing in the same direction, usually it takes few moments for it to reach the proper Y coordinate.
This results in a buggy effect known as "walking in place".
Here's the actual example:

Spoiler

[close]

In the end, not only the character may end up in a slightly wrong position (2-3 pixels away), but there's a chance this above animating in place happening, which looks quite weird.

I guess that there may be various approaches to solve this problem. Currently I'm experimenting with a solution where engine will, so to speak, turn the walking vector to make it point right along the unfinished axis, while keeping its length (that means - walking speed), in order to reach the destination faster. At the same time, I removed the "mistake acceptance" completely, forcing character to always reach the requested destination.
This should make character make some extra short move, properly animating, but this may look more natural than just moving legs in place.

Now, the reason why I explain all this here, is that a result of this solution is that the character may make a kind of a "final step" in a slightly different direction in the end. And I've been wondering how acceptable or non-acceptable this looks like.

Here's a compiled game i used for the test:
https://www.dropbox.com/scl/fi/r52c6zy1odiabeuwnautu/walk-problem-test.zip?rlkey=3e9yfgeze8dujeeb1n4ov6d3u&dl=0
I scripted this game to make a walk between very particular coordinates that illustrate this problem case: this is done by pressing Space button.
But in theory it may be possible to have similar effect when walking around the room for the long distances.

Of course I may be overthinking this too...