Ellipsenalgo aus Formelsammlung kreieren

[Kas Ob.]

Zitat von Rollo62:

Zitat von Kas Ob.:

Step = 1/Sqrt(a^2+b^2)

Like said, it is the sqrt that makes me nervous, but its maybe needed here.
I think it depends a lot on the shape, how to handle it.
For lines, circles, squares, a pre-calculated step will work nicely.
For ellipses and other complex paths, maybe you always need varying step-sizes during drawing.

A overdraw pixel will happen for the suggested above for sure, but it will not affect the drawing, the only enhancement to do is to check if x and y changed from last pixel/point then draw, due to approximation of course, as for dynamic, it will return to the same check no matter what algorithm been used, for more accurate approximation you need to calculate the derivative of the speed of pixel on the slope then divide it by the radius, but not that radius you will calculate from (0,0) the center of the ellipse, this will be more complex for no, benefit visually or not.

the only case when it corrupt drawing is when the ellipse is more like a line then an ellipse, when one of the axis is barely moving while the other taking the full speed for the next step.

[Kas Ob.]

To calculate this accurately you need to take the last used step then calculate the length to move for current pixel based on the last step, draw it then adjust the step for the next one, so in theory we will be calculating the step for the next pixel but not for the current one.

after calculating the distance from the last pixel divide by the radius and use it for the next pixel.

[Rollo62]

Zitat von Kas Ob.:

the only case when it corrupt drawing is when the ellipse is more like a line then an ellipse, when one of the axis is barely moving while the other taking the full speed for the next step.

Yes, thats what I meant.
An algorithm sould be univeral and not break when it comes closer to extreme settings.
https://www.geogebra.org/m/AAx6FWka

If the dot is on top side, each of its step is maybe set to be dense enough.
If the dot is in right side, anbd the ellipse not very high, then the density will increase a lot, perhaps too dense.

Either you can accept these changes in density, or you try to optimize it in each step.
The whole world is a compromize

Maybe one solution would be to divide the ellipse into sections, where its equal to circle, where its more dense and where its not so dense, for switching to different optimized algorithms in each segment.

[Kas Ob.]

Zitat von Rollo62:

Maybe one solution would be to divide the ellipse into sections, where its equal to circle, where its more dense and where its not so dense, for switching to different optimized algorithms in each segment.

Think about it, no matter how much you divide it will return to check against the last pixel or calculating the new (next) pixel distance form the current:
1) in the first it is easier to simply compare (new pixel vs last pixel) then adjust.
2) in the other you must have the distance is close enough to 1 in four straight direction (up, down, left and right) and close enough to sqrt(2) in 4 diagonal direction, any less than that we are drawing on top of the current (or the last), any bigger we are skipping.

Whole problem is due the arithmetic is in float numbers while drawing and coordination in integers.

i don't think that there is quite real one liner algorithm that can be solve this.