Walk-to weirdness.

[After]

It all started when I noticed that, whenever a non-walkable end point was used, the point reached was always to the left. Not the nearest, or in some symmetrical relationship with the end-point's x, the left.
So I wrote a test program, and sure enough it always tends left and|or up (depending on angle).
In addition some points actually exchange relative positions, e.g. the walk-to of the left end-point is to the right of the walk-to of the right end-point.
The ratio of perimeter-points to found end-points was about 10:1 in my test, but it wasn't really suited to measuring that.

I was also getting the hang of scrolling rooms at the time. Now I haven't done a proper test for this, but it seems to be much slower at coping with the above situation.

I'm not saying that anything has to be done about it, these are just some quirks that tech folk might want to be aware of -- or possibly misconceptions that I can be corrected on.

[Pumaman]

How far to the left are you talking about? If you click to move somewhere non-walkable, AGS finds the nearest walkable pixel and sets that as the destination instead. This is rounded down to the walkable area granularity, so it could be up to 2 pixels left of where you clicked - is this what you're referring to, or is it more serious than that?

[After]

It is certainly more than that. It's about 16px in the room in which I first noticed it, and the test program shows variable but large exclusion zones around the walkable perimeter.

This test was just a centred circular walk area with the character centred and given each point on the 320*200 boundary.

I have a more informative test in mind when I can get the time to write it.

I don't entirely believe it myself, which is why I'm checking; there could be something odd about my coding instead.

[Pumaman]

Perhaps you could provide an example room? I haven't noticed anything like this myself.

[After]

I've just finished a function for computing angles which I intend to use to make an angular displacement map for the entire screen. If there's anything in it, I'll send complete source (and screenshots. My function is pretty slow).
I have an image of the first test already, but I'm going to redo it with a clean room.

[edit]
Tests are done. I will find somewhere to post everything next.
(Actually, it wasn't so much the functions that were slow as having to put Wait(1) in the deepest loop.)
[edit2]
Done.

[Pumaman]

Thanks for that - very interesting to see the results in that fashion.

I believe the cause of this due to the fact that if you click outside a walkable area, then AGS checks the screen as a 64x40 grid, checking the distance from every 5 pixels on the screen to where you clicked (ie. 0,0  5,0  10,0  etc). The closest one it finds then becomes the walkable target.

This probably explains the behaviour with a circular walkable area, since it gradually curves round, the next pixel location divisible by 5 will by some way further round.

I'd welcome any suggestions you might have on how to improve the accuracy of the algorithm without making it too slow.

[After]

Ahh... It all makes sense now.
[edit: Well, to some extent. I'll have to do some more experiments to convince myself that the higher magnitude differences can be eliminated by rounding.]

I haven't dabbled in this area, so I have no suggestions. Although now that the problem has been posed it's going to linger in my thoughts for a while, so something might occur to me.