[bugs] problems when using selfmade hatches

I pushed a patch: df719241f

it solves some rotation issues, but doesn't solve the "arc" -> "line" bug.

I just copy and pasted the patched lines into my .cpp file and this is what I get:
(btw. the hatch is moved 1/2 pattern sizes downwards and 1/2 pattern sizes to the left)


dxli, could you reproduce the bug ("missrotated arcs") on one of your machines? If so, were they 32bit only?
If not, that would mean I'm the only one who can reproduce this ->maybe I did something wrong?

".. that the issue wasn't present on my 32 bit Ubuntu."
I guess it was a release version?
The problem is, I don't get when the bug appears. Cause on both my 32bit linux machines I could reproduce the bug but you could not reproduce this on your 32bit machine. What else could cause such a bug?

Hi,

I can remove the offset of 1/2 size.

I need to find a 32bit machine to test this, but please post the pattern and contour dxf files here, as I reached some expired links before.

The "arc" -> "line" bug needs to be fixed still. Looks like it only happens to 64bits.


Dongxu

The pattern is the standard pattern (comes with librecad) called "arcs" (librecad/support/patterns/arcs.dxf).
The contour is just a rectangle from 0,0 to 350,370.

I think I have the solution for this problem.
My computers are just evil!
Here is the same hatch/contour on XP:
(installer from here http://forum.librecad.org/dimensions-reading-between-librecad-and-other-softwares-tp5708262p5708967.html)

ok, here is a test on a real 32bit cpu using xp
( ↓ lacad older version(beta5???))




(↑installer from here http://forum.librecad.org/dimensions-reading-between-librecad-and-other-softwares-tp5708262p5708967.html)

I guess you already found that out but I thought I tell it anyway.
So I nailed the weird arc behaviour down to tmp2 (actually is2).
The order of the start angle and the end angle of the weird looking arc is transposed. That's because the start point and the end point are transposed in is2 as well!!!
Normally (on correct arcs), the first angle in tmp2 is the angle of the start point and is followed by the angle of the end point.
For the weird looking arcs it's the opposite (end point/angle comes first and then the start point/angle).
That's why I think the problem has to be somewhere in the sorting code.
Somewhere in rs_hatch.cpp at about line 335
         // sort the intersection points into is2:
        RS_Vector sp = startPoint;
       ...

The problem is, if I just step through the code, it looks like librecad bahaves correctly.
Another thing I found out is, when I add
qDebug("angle centerToNextIntersection: %f",a);

after these lines of code in the sorting process:

case RS2::EntityArc:
                case RS2::EntityCircle:
                    a = center.angleTo(*v);
                    dist = reversed?
                                fmod(sa - a + 2.*M_PI,2.*M_PI):
                                fmod(a - sa + 2.*M_PI,2.*M_PI);
->here->

the weird behaviour seems to be gone!
 ->

Maybe there is something wrong with *v in  a = ellipse->getEllipseAngle(*v); ???
or here:
is2.append(std::shared_ptr<RS_Vector>(new RS_Vector(*av)));  ????