frisk@rhi.hi.is (Fridrik Skulason) (09/12/90)
I have noticed what I believe is a minor error in the MSC 6.0 graphics
library - something which would normally not be noticed, but almost ruins
one application I'm writing.
The problem is that I cannot draw ellipses where the height is an even number.
See the following example - which was written to demonstrate the problem:
#include <graph.h>
main()
{
_setvideomode(_ERESCOLOR);
_ellipse(_GBORDER,10,10,15,13); /* draw ellipse of height 4 */
_ellipse(_GBORDER,20,10,25,14); /* draw ellipse of height 5 */
_ellipse(_GBORDER,30,10,35,15); /* draw ellipse of height 6 */
_ellipse(_GBORDER,40,10,45,16); /* draw ellipse of height 7 */
getch();
_setvideomode(_TEXTC80);
}
The second and third ellipse should be of different sizes - but they are not.
It is possible to get the ellipse of height 6 by writing something like
_arc(50,10,55,14,55,12,50,12);
_arc(50,11,55,15,50,13,55,13);
but what I wanted to ask is - what about other compilers, Watcom for example
do they have the same problem ?
-friskeverett@hpcvra.CV.HP.COM (Everett Kaser) (09/13/90)
frisk@rhi.hi.is (Fridrik Skulason) writes... >I have noticed what I believe is a minor error in the MSC 6.0 graphics >The problem is that I cannot draw ellipses where the height is an even number. >-frisk This could be considered a bug, but is really a ramification of the decision by Microsoft's engineers to have the parameters of the ellipse specified in a fashion different from the actual parameters needed by the algorithm to draw the ellipse. The algorithm they use is the fairly standard one which requires that you know the "center" of the ellipse (the point where the major and minor axis inter- sect), and the lengths of the major and minor radii. Based on this algorithm, for any ellipse the center will take one pixel and then you'll have an equal number (even OR odd) of pixels above and below the center. This will cause you to always have an ellipse that is an ODD number of pixels high, since 1+2*r is ALWAYS odd, regardless of the value of 'r'. The same applies to the x-axis, even though you didn't complain about that. So, instead of having the user specify the (x,y) of the CENTER and the rx,ry lengths of the two axis, the Microsoft engineers got cute and said, "Hey, I've got a good idea! Let's specify the ellipse by the diagonal corners of the bounding rectangle!" Well, the problem with that is that it allows the user to specify a height or width for the ellipse which is an EVEN number of pixels, when the algorithm they use requires an ODD number of pixels. So, what happens is that during the conversion from bounding_rectangle_corners to center_axis- _radii, there's a round-off error, you lose a 1/2 pixel off the length of the radii, which is equal to a full pixel for the diameters. I know this doesn't solve your problem, but hopefully it clarifies what causes the problem. Everett Kaser Hewlett-Packard Company ...hplabs!hp-pcd!everett work: (503) 750-3569 Corvallis, Oregon everett%hpcvra@hplabs.hp.com home: (503) 928-5259 Albany, Oregon