[comp.sys.ibm.pc.programmer] Drawing circles with MSC 5.00

frisk@rhi.hi.is (Fridrik Skulason) (05/29/90)

I have noticed a minor problem when drawing circles in MSC 5.00, namely that
the circle sometimes seems be one pixel too large.

Take the following program for example: 

	#include <stdio.h>
	#include <graph.h>

	main()
	{
	    _setvideomode(_ERESCOLOR);
	    _moveto(50,90);_lineto(80,90); 
	    _ellipse(_GBORDER,61,90,69,95);  /* upper limit of circle = 90 */
	    getch();
	    _setvideomode(_TEXTC80);
	}

It is supposed to produce something like this:

line 90         *******************************
                            **   **                    
                           *       *       
                           *       *       
                            **   **   
                              ***

Instead I get something like this:

                              ***
line 90         *******************************
                           *       *       
                           *       *       
                            **   **   
                              ***

where the top of the circle seems to be one pixel too high. This effect
only happens in certain cases, which seems to indicate a minor bug in the
library.  My questions:

I only have MSC 5.00 - does this effect also appear in the latest versions ?

I could solve this by using Turbo C, (which should have been used
to start with), but then I would have to rewrite a considerable part of the
application.  Does anyone know of another C compiler with MSC-like
graphics functions, without this problem ?

-frisk

-- 
Fridrik Skulason      University of Iceland  |       
Technical Editor of the Virus Bulletin (UK)  |  Reserved for future expansion
E-Mail: frisk@rhi.hi.is    Fax: 354-1-28801  |   

everett@hpcvlx.cv.hp.com (Everett Kaser) (05/30/90)

The problem with the _ellipse function in Microsoft C giving you an ellipse
that is actually one dot too wide (or high) is this:  the function was written
to accept the corners of the bounding rectangle as the arguments, or ellipse
specifying parameters.  However, the actual code (or algorithm) used is based
on knowing the "center" of the ellipse and the lengths of the two axis.  Hence,
the _ellipse function must first find the "center" of the rectangle and the
distance from the "center" to the two sides, before beginning the actual
drawing.  This works fine if the "ellipse" (or the bounding rectangle) is an
odd number of dots wide (and high), because then you can find the EXACT center
of the figure.  But when the ellipse is an even number of dots wide (or high),
the center is at a half dot position, and you can't plot "half-dots" on a CRT,
so the center has to be adjusted a half-dot one way or the other.  The
algorithm for drawing the ellipse assumes that the "quarters" of the ellipse
are symetrical about the center, so this forces the ellipse to be drawn one
dot larger (or smaller) than the user actually requested.  Yes, you could come
up with an algorithm that would do a best fit to the bounding rectangle that
the user requested, but the REAL problem here is that Microsoft chose to have
the user specify the parameters from a different frame (or point of view) than
that which the algorithm actually uses, and accuracy is lost in the conversion.

Everett Kaser                   Hewlett-Packard Company
...hplabs!hp-pcd!everett        work: (503) 750-3569   Corvallis, Oregon
everett%hpcvlx@hplabs.hp.com    home: (503) 928-5259   Albany, Oregon