> > (I also did some quick timing tests, and my function seemed
> > to be about 3 times faster for a 10 x 10 and about 10 times
> > faster for a 100 x 10 ellipse, with an empty callback function
> > though.. so it probably won't matter when actually drawing
> > something.)
> The test program shows a 30% speed increase for ellipses and
> a 1.4% speed decrease for circles on my system (DOS).
Yes, do_circle just calls do_ellipse, so it's slower. I was thinking
about having a single function which could do ellipses, circles
and ellipse-arcs, and the other functions would all just call it.
Of course it would be slower than specialized versions, and I'm
not sure how good it would work to also reuse the function for
> > The attached patch adds a do_ellipse_diameter function,
> > which has the same parameter format as rectfill, and
> > makes do_circle and do_ellipse call this new function.
> + /* Cheap hack to get elllipses with integer diameter, by just offsetting
> + * some quadrants by one pixel. */
> What do you mean by "ellipses with integer diameter" ? Strictly speaking,
> ellipses don't have a diameter; moreover, aren't the dimensions always
> integers ?
The function doesn't take 2 (integer) radii, but 4 edge-points for the
ellipse (just like rectangle) - so this makes it possible to have integer-
diameters, in contrast to the current ellipse function, where you can only
have odd diameters. (Diameter = 2*radius for me, I have no idea how it is
> You recently mentioned some problems at the joint between the two parts of
> the drawing. What are they exactly ?
Yes, just when I had cleaned everything up and did the final tests before
proposing a patch to [AD], I found my algorithm has this problem..
Is is just a plain bresenham (I think) algorithm, i.e. starting at the top
of the ellipse, it draws the arc line as long as the gradient is < 1. This
means it just always goes one pixel right, and checks with bresenham if it
should also go one pixel down at every step to approximate the ellipse line.
For gradients > 1, everything is rotate 90° and the same algorithm is done
starting at the right of the ellipse, and going left and up. The problem now
is, they don't necessarily meet exactly:
The first arc line aproximates pixels from the top, i.e. comparing pixel y
coordinates with the exact ellipse position .. the second arc compares x
coordinates. If I compare always x or always y, everything works, but then
the ellipse might not be 100% symmetric, i.e. it could produce something
x xxx x x x
x x for 3x5 and x x for 5x3, instead of x x or xx xx
x xxx x x x
A solution would be to compare x-radius and y-radius, and chose a different
direction to approximate the pixels depending on if it's a 'lying' or
'standing' ellipse, and maybe also make circles a special case where half
the arc is approximated from top and the other half sideways.. but this
looks messy to me (and maybe the Allegro code is better then). Maybe I can
still find a way to make my current one work, after all it's just a few
pixels missing/overdrawing at the 'gradient = near 1' point. I looked for
some other ellipse code with google, but most seems to be like the current
one in Allegro, i.e. with 'extra pixels' along the line.
I'm not sure when I will have time to experiment some more with the code,
all I really wanted for my own program was the ability to draw circles with
an even diameter. E.g. if I have a square, I want to draw a circle into
it which touches all sides. As an example, if you use the d_radio_button_proc
from the Allegro GUI, it can draw the circle if the button has odd
dimensions.. but if you use e.g. a 32x32 button, it will draw a circle
which is too big, because it can only draw 31x31 and 33x33 circles. A
solution would be something like 'ellipse_in_rect' which would draw an
ellipse, but use the same parameter format as rectangle. It's quite simple to
do, but I got carried away with trying to also make the ellipses look nicer,
which proved to be more complicated than I first thought :)