Talk:Midpoint circle algorithm

message: I created this article based on content from the Bresenham's line algorithm article's section Circle variant (this article used to point to that section). That section had been removed, probably because it is was not about the algorithm developed by Bresenham. Lakeworks (talk) 21:06, 12 January 2008 (UTC)
thread_title: Untitled

message: there's an algorithm for lines; there's an algorithm for circles. is there an equivalent algorithm for spheres? pauli133 (talk) 21:51, 6 October 2010 (UTC)
replies: text: Project the sphere to a circle (x, y, r) first, then use the circle algorithm. x and y can be found by projecting the sphere's center, and r can be found by solving a right triangle for the projection, where the right angle corner of the triangle lies on the sphere's surface (i.e. find a ray tangent to the sphere). There are an infinite number of right triangles available; pick one that makes the math easy. -- 70.124.59.176 (talk) 03:28, 29 November 2010 (UTC)
thread_title:  spheres 

message: There is currently a note asking for this article to be clarified. Here's some text that might be a little clearer. It should replace the first 3 paragraphs of the "The Algorithm" section:
"The equation for a circle centered at the origin, with a radius r is x^2 + y^2 = r^2. We can use this equation to draw a circle. Furthermore, we can use the fact that a circle is radially symmetric to reduce the amount of work necessary for drawing it. The algorithm presented here will only calculate points in the first octant of the circle and use the symmetry to fill in the rest of its circumference.
Ideally, we'd like the algorithm to work on a pixel-by-pixel basis, so we can increment a counter and traverse the circle, drawing points on its perimeter. The algorithm presented will advance 1 pixel in the Y-direction each iteration through the loop. It will accumulate fractional values in the X-direction, advancing in the X-direction only when those accumulated fractions equal at least 1 pixel in the X-direction."  --Dcardani (talk) 23:20, 18 October 2010 (UTC)
replies: text: The link helpfully provided by Alexis59, http://www.cs.unc.edu/~mcmillan/comp136/Lecture7/circle.html, is dead as of 2024-02-12. The replacement course as of Fall 2023 may be "Comp 475. 2D Computer Graphics", as described in the currently-most-recent course catalog, but I"m giving up trying to track down the "more detailed description" that Alexis59 saw. )-: DavidHolmes0 (talk) 14:59, 12 February 2024 (UTC)
thread_title:  Clarifications 

message: I'm not 100% sure how to phrase this.  Maybe someone could help with this.  Basically for a radius r, the midpoint circle algorithm generates 4*sqrt(2)*r points.  I think this has something to do with the algorithm for generating lines: for a line connecting (x1,y1) -> (x2,y2), max(abs(x2-x1),abs(y2-y1)) points are generated.  In the picture of the midpoint circle algorithm, this would be something like (x=r,y=0) -> (x=r*cos(pi/2),y=r*sin(pi/2)).  Any suggestions on how to incorporate this?  — Preceding unsigned comment added by Drnathanfurious (talk • contribs) 08:46, 3 June 2011 (UTC)
thread_title:  Total Points Generated 

message: In the book "Steve Jobs", Walt Isaacson describes Bill Atkinson's algorithm for drawing circles quickly on the original Macintosh.  This routine eventually became part of the Apple Quickdraw library.  The algorithm involves a clever observation about the sum of odd numbers. The algorithm is probably a variant of the midpoint circle algorithm — Preceding unsigned comment added by 66.92.48.217 (talk) 20:14, 22 December 2011 (UTC)
thread_title:  Bill Atkinson's algorithm 

message: This comment appears to be inaccurate:
"The following test may be implemented in assembly language in most machines by testing the carry flag after adding 'y' to the value of 'error' in the previous step, since 'error' nominally has a negative value."
Since 'y' is added twice (once pre-increment and once post-increment), if the carry occurs the first time 'y' is added to 'error', then the carry flag won't be set the second time after incrementing 'y' and adding it to 'error' again. I had to use the sign flag instead of the carry flag (in x86 assembly language).
In general it seems like most machines would only set the carry flag after an addition if the left hand operand was negative prior to the addition and non-negative afterward. Or is this in fact peculiar to x86?
Clone53421 (talk) 14:50, 29 July 2013 (UTC)
thread_title:  Inaccurate comment in "Optimized" algorithm 

message: While researching ellipse algorithms, came across this page. Paper by John Kennedy is no longer available at the address uri, flagged it as a dead link. Will update if I find a replacement. Akoi Meexx (talk) 19:18, 17 April 2014 (UTC)
thread_title:  Flagged dead link 

message: The final step in the derivation substitutes x^2+y^2-r^2 with the previously defined RE(x,y) function.
As defined the RE function additionaly takes the abs value of this expression and is therefore not equivalent,
which makes the resulting condition simply wrong as stated.
Someone with the patience to futz with markup and editorial politics - please fix.  — Preceding unsigned comment added by 5.102.221.219 (talk) 01:49, 7 February 2015 (UTC)
thread_title:  Error in Section "Variant with Integer-Based Arithmetic" 

message: In the C-function in the current version of the article, first the variables are being updated, then the block, drawing the 8 octants follows. Given there is a discussion about the "last pixel" and the fact, that the init values of x and y are on a perfectly fine pixel (error = 0), why not move the putpixel block in front?
    void DrawCircle(int x0, int y0, int radius)
    {
        int x = 0, y = radius;
        int dp = 1 - radius;
        do
        {
            putpixel(x0 + x, y0 + y, 15);     //For the 8 octants
            putpixel(x0 - x, y0 + y, 15);
            putpixel(x0 + x, y0 - y, 15);
            putpixel(x0 - x, y0 - y, 15);
            putpixel(x0 + y, y0 + x, 15);
            putpixel(x0 - y, y0 + x, 15);
            putpixel(x0 + y, y0 - x, 15);
            putpixel(x0 - y, y0 - x, 15);
                
            if (dp < 0)
                dp = dp + 2 * (++x) + 3;
            else
                dp = dp + 2 * (++x) - 2 * (--y) + 5;
        } while (x < y);
    }
I also noticed this, and the circles drawn by the sample code are somewhat diamond-shaped. Following the mathematical description directly above it, I am contributing an implementation that fixes the above issue and also produces a more circular-shaped rasterization. HoldTheDoor (talk) 01:31, 8 June 2016 (UTC)
thread_title:  Why is the putpixel(..) block after the update of x and y?  

message: I mean, it'd affect the already-poor performance, make the algorithm about 9000% harder to follow by a beginner, and provide basically no benefit beyond that of a simple "line pitch" constant. Hope the writer doesn't teach IT...  — Preceding unsigned comment added by 95.232.30.145 (talk) 02:49, 23 January 2017 (UTC)
thread_title:  The closure in the javascript example is priceless 

message: Most of the contents in this article are only some kind of "proof" saying that the algorithms makes sense. And the actual algorithm is hidden in this proof. To make it clearer what the algorithm does, there should be at least some implementation (e.g. PseudoCode). David Eppstein removed previous code without much of a comment. In its current form the article is extremely unhelpful.
--2A02:8071:699:B700:224B:DCD2:B994:76F5 (talk) 22:18, 3 February 2021 (UTC)
replies: text: One implementation in pseudocode, ok. Multiple implementations of the same method in multiple real programming languages, not ok. Without published sources for that code they are original research, and with sources they are probably a copyright violation. And compared to pseudocode these implementations are too bogged down with irrelevant programming details to be as helpful to human readers. Wikipedia is not a code repository. There are other sites for that, that do it better. —David Eppstein (talk) 23:33, 3 February 2021 (UTC)
thread_title:  Code Example 

message: The text in question reads that:
This statement is slightly confusing on the last part because as-is implies that any 2d curve, regardless of degree, can be derived from Bresenham's original algorithm. As far as I know, considerable arrangements should be made to rasterize curves other than quadratic ones (I don't want to say impossible because I am not sure yet).
So should that text be reworded to say, "...or any other two-dimensional quadratic curve."?
Dv-id.061 (talk) 01:51, 11 July 2021 (UTC)
thread_title:  Inaccurate wording on the Generalizations