+- HP Forums (https://www.hpmuseum.org/forum)
+-- Forum: HP Calculators (and very old HP Computers) (/forum-3.html)
+--- Forum: HP Prime (/forum-5.html)
+--- Thread: Bresenham Circle VS others (/thread-17205.html)
Bresenham Circle VS others - matalog - 07-04-2021 01:10 AM
On the thoughts of Bresenham circles drawn in BASIC languages, I have taken the opportunity to create a VS here, and there is not a lot of difference.
What led me to show this, was my post on FILLPOLY_P(). Although, I suspect that Bresenham's method can't even help the FILLPOLY algorithm, because that algorithm seems to be flawed in some ways, especially for shapes described in more than a rough description of their outline.
Fillpoly() seems to need a distance farther than 2 horizontal or vertical pixels, while still connected by pixels, or it does not work correctly.
Code:
EXPORT BRES2()
BEGIN
RECT_P(0,0,320,240,0);
LOCAL COORD:={};
LOCAL A,R,ST;
LOCAL XC,YC,X,Y,R,D;
R:=100;
XC:=160;
YC:=120;
X:=0;
Y:=R;
D:=3-2*R;
ARC_P(160,120,100,RGB(255,0,0));
WHILE Y>=X DO
IF D>0 THEN Y:=Y-1;D:=D+4*(X-Y)+10;ELSE D:=D+4*X+6;END;
PIXON_P(XC+X,YC+Y,RGB(0,255,0,0));
PIXON_P(XC-X,YC+Y,RGB(0,255,0,0));
PIXON_P(XC+X,YC-Y,RGB(0,255,0,0));
PIXON_P(XC-X,YC-Y,RGB(0,255,0,0));
PIXON_P(XC+Y,YC+X,RGB(0,255,0,0));
PIXON_P(XC-Y,YC+X,RGB(0,255,0,0));
PIXON_P(XC+Y,YC-X,RGB(0,255,0,0));
PIXON_P(XC-Y,YC-X,RGB(0,255,0,0));
X:=X+1;
WAIT(0.05);
END;
REPEAT
WAIT (-1);
IF ISKEYDOWN(4) THEN BREAK(3); END;
UNTIL 0;
END;Obviously the Bresenham method has been slowed down here to show the beautiful way that it draws.
RE: Bresenham Circle VS others - C.Ret - 07-04-2021 06:41 AM
Hi,
Nice implementation indeed, you now have an efficient way of filling your circles without lost of detail or no fill gaps !
Code:
EXPORT FCIRCLE_P(XC,YC,R,Col)
BEGIN
LOCAL D:=3-2*R, X:=0, Y:=R;
RECT_P(#0);
WHILE Y>=X DO
IF D>0 THEN Y:=Y-1; D:=D+4*(X-Y)+10 ELSE D:=D+4* X + 6 END;
LINE_P(XC+X,YC+Y,XC+X,YC-Y,Col); LINE_P(XC-X,YC+Y,XC-X,YC-Y,Col);
LINE_P(XC+Y,YC+X,XC+Y,YC-X,Col); LINE_P(XC-Y,YC+X,XC-Y,YC-X,Col);
X:=X+1 END;
FREEZE
END;But, you may have explained a bit more the trick you are using with the indicator variable D. Are the definition correct for any value of radius R or is there any hidden beast in the eke ?
It also a bit of a shame, you don't have post this related subject in your previous thread, since it is closely related, this will have help readers and subscribers to easier follow your progress.
RE: Bresenham Circle VS others - Liamtoh Resu - 07-04-2021 12:17 PM
I find these graphics programs fascinating.
I had to grok m's code to figure out how to get an output from c's code.
(eg. 160,120,100,255) gave me a blue circle.
Explanations of bresenham's algorithm tend be very detailed.
Meanwhile I found this link for the bitmap/midpoint circle algorithm:
http://rosettacode.org/wiki/Bitmap/Midpoint_circle_algorithm
Thanks again.
RE: Bresenham Circle VS others - C.Ret - 07-04-2021 03:05 PM
(07-04-2021 12:17 PM)Liamtoh Resu Wrote: [...]I had to grok m's code to figure out how to get an output from c's code.
(eg. 160,120,100,255) gave me a blue circle.[...]
Sorry, I don't have commented the code in my previous post. The Col variable is expecting regular color code for the HP Prime.
The best way is to use the RGB(r,b,g,α) function or a valid structured #rrggbbαα binary integer.
Beware that in this code, I produce the method used by matalog and I am not sure that the variable D is correctly set.
RE: Bresenham Circle VS others - Mark Power - 07-07-2021 09:13 PM
The true beauty of Bresenham’s algorithm is that the calculations are limited to integer addition, integer subtraction and integer x4 which can be implemented as shift left by 2 bits. All of which means the algorithm can be implemented in assembly language/machine code for stunning speed on the most basic of processors.
If you want to see an HP48 implementation in assembly language have a look at glib.