function for circle not continous on jhd12864e

[marthoma]

void GLCD_Circle(unsigned int cx,unsigned int cy ,unsigned int radius)
{
unsigned int x, y;
int	radiusError;
x = radius;
y = 0;
radiusError = 1 - radius;
while(x >= y)
  {
			set_pixel(cx+x, cy+y); 
			set_pixel(cx+y, cy+x);	
			set_pixel(cx-x, cy+y); 
			set_pixel(cx-y, cy+x); 
			set_pixel(cx-x, cy-y);
			set_pixel(cx-y, cy-x); 	
			set_pixel(cx+x, cy-y); 
			set_pixel(cx+y, cy-x); 
			y++;
			if ( radiusError < 0 )
			{
				radiusError += 2 * y + 1;
			}
			else
			{
				x--;
				radiusError += 2 * (y - x + 1);
			}	
	}
}

this code is is not plotting pixels near the x axis...wat could be wrong here?

 

[marthoma]

please ....im indeed in need of a solution here...i have tried with all kinds of circle algorithms...but none is gvg result.that means im making mistakes with the data types ryt?

- - - Updated - - -

void GLCD_Circle(unsigned int cx,unsigned int cy ,unsigned int radius)
{
unsigned int x, y;
int	radiusError;
x = radius;
y = 0;
radiusError = 1 - radius;
while(x >= y)
  {
	set_pixel(cx+x, cy+y); 
	set_pixel(cx+y, cy+x);	
	set_pixel(cx-x, cy+y); 
	set_pixel(cx-y, cy+x); 
	set_pixel(cx-x, cy-y);
	set_pixel(cx-y, cy-x); 	
	set_pixel(cx+x, cy-y); 
	set_pixel(cx+y, cy-x); 
	y++;
	if ( radiusError < 0 )
	{
		radiusError += 2 * y + 1;
	}
	else
	{
		x--;
		radiusError += 2 * (y - x + 1);
	}	
    }
}

now it looks much better...

 

[andre_luis]

I would be more confortable using the 1 = x² + y² relation.

To be honest, I could not understand what formula you used to do that, once didn´t see any sin or cos function there, that presumably must be calculated extarnally to the above routine.

 

[FvM]

I would be more confortable using the 1 = x2 + y2 relation.

Not in terms of effective calculation...

It looks like a valid circle algorithm at first sight. See https://en.wikipedia.org/wiki/Midpoint_circle_algorithm

I believe 1 million implementations of the algorithm can be found on the internet. Code debugging is still up to you.

marthoma, I don't see a difference between both codes.

 

[andre_luis]

A probable cause could be due to marthoma is probably using small integer values, which could result in a circle with a quite grid shape.

 

[FvM]

The said algorithm is using integer pixel positions and should work for arbitrary circle sizes.

I must confess that I didn't check the posted code against the "1 million" existing implementations and also don't know if the twofold posted code is the claimed "not working" or "working" one.

In fact you can test the code with pencil and paper method on a piece of quadrille paper and check against the computed results. I would expect a qualified error report (e.g. a screenshot or sketched image) if there are any differences. I recently had a problem with GLCD routines which turned out as a CCS C compiler bug.

 

[andre_luis]

In fact you can test the code with pencil and paper method on a piece of quadrille paper and check against the computed results. I would expect a qualified error report

Depending on magnitude of the absolute values of the argument ( e.g. radio in a range of few unities instead houndred of unities ) the error will be noticeable, even shifting the circle center as he mentioned, due to effect of the numerical rounding.

 

[FvM]

I see what you mean. You'll see "rounding" if you compare the result with a circle drawn with infinite resolution. But there's no rounding in the algorithm. It's just using integers.

The problem reported in the original post isn't related to this point, because the alorithm produces perfectly mirrored octants.

 

[andre_luis]

this code is is not plotting pixels near the x axis

i have tried with all kinds of circle algorithms...but none is gvg result

I assumed that once he probably used the same input to test all the other algorithms, the problem could be related to the arguments, due some one of these functions should work. I could have been wrongly interpreted the root of the problem, and jumped to one possible cause, but we surelly need more details about the test.