VectorLib Coordinate Bug PB573
Posted: Fri Apr 02, 2021 11:32 pm
VectorLib Coordinate Bug PB573
Here's an explanation, since it's all rather convoluted.
Now finally after developing the Vector based Rotate and Mirror tool my findings.
https://www.purebasic.fr/english/viewto ... 12&t=77009
Thread because the bug :
https://www.purebasic.fr/english/viewto ... =5&t=76988
A basic problem is that the coordinate origin is offset by one pixel.
So you have to set MovePathCursor(-1, -1) like this to get to zero.
Therefore the Vector output starts at 1, 1, not at 0, 0
This results in problems with truncated image edges when rotating, for example, because the drawing area is
ends 1 pixel outside a given plane.
You can compensate this by setting the path cursor accordingly.
Up to now, however, everyone had failed in the handling, because everything seems very suspect.
FlipCoordinates has a real bug.
I think it is due to the Vector Lib.
The coordinate origin shifts x and y by an amount of +-1, depending on the dimensions of the source plane.
For example, at 340*340 there is no offset, but at 420*420 there is. ( Try simple different values )
420*421 is OK 420*422 gives an offset,
422> then goes again, until at some point it doesn't. (As far as I can remember these sizes )
Horizontal mirroring, for example, gets an offset when the tarp is enlarged vertically and vice versa.
Absolutely no pattern or coherence can be found in this.
On Linux and Mac everything works fine, except that the zero coordinate is not correct either.
Here's an explanation, since it's all rather convoluted.
Now finally after developing the Vector based Rotate and Mirror tool my findings.
https://www.purebasic.fr/english/viewto ... 12&t=77009
Thread because the bug :
https://www.purebasic.fr/english/viewto ... =5&t=76988
A basic problem is that the coordinate origin is offset by one pixel.
So you have to set MovePathCursor(-1, -1) like this to get to zero.
Therefore the Vector output starts at 1, 1, not at 0, 0
This results in problems with truncated image edges when rotating, for example, because the drawing area is
ends 1 pixel outside a given plane.
You can compensate this by setting the path cursor accordingly.
Up to now, however, everyone had failed in the handling, because everything seems very suspect.
FlipCoordinates has a real bug.
I think it is due to the Vector Lib.
The coordinate origin shifts x and y by an amount of +-1, depending on the dimensions of the source plane.
For example, at 340*340 there is no offset, but at 420*420 there is. ( Try simple different values )
420*421 is OK 420*422 gives an offset,
422> then goes again, until at some point it doesn't. (As far as I can remember these sizes )
Horizontal mirroring, for example, gets an offset when the tarp is enlarged vertically and vice versa.
Absolutely no pattern or coherence can be found in this.
On Linux and Mac everything works fine, except that the zero coordinate is not correct either.