Closed nical closed 7 years ago
Hey! How's it going with this, is there a solution in sight?
Absolutely. Nobody had complained about it so far so I was looking into other things but I can at least easily improve the numerical stability of strokes in the 180 degree case. I'll look into that shortly.
Great! It's totally ruining my ggez-based project's rendering so I'm super grateful if it can be fixed soon :) Thanks!!!
I could solve it temporary by generating points a long the line and draw a dotted line instead.
@johalun The issue is hopefully fixed in lyon 0.6.2
. Could you cargo update
and see if the glitch is gone?
Seems like ggez was using a rather old version, 0.4.1. Need to update it in some places to work with 0.6.2. Seems like basic_shapes::fill_ellipse is gone.. What can I use instead?
Ok I ended up removing the ellipse code in ggez (which I don't use) and move fill circle code from fill ellipse to fill circle. I got ggez to work with 0.6.2 and can confirm that problem is solved.
I indeed removed fill_ellipse with the idea that using fill_circle and stretching the vertices would do, I can add that boilerplate back if need be, let me know if you miss that feature.
I will let the ggez developers decide that and comment at ggez repo that this has been solved upstream.
Thanks for the help!!
Happy to help :)
The code that computes normals (using intersections) in the stroke tessellator does not behave very well when the angle between two consecutive segments is very close to 180 degrees because the lines that we are intersecting are almost parallel. PR #109 fixed the same issue for angles close to zero degrees.