Re: filling area by color atack safety

Groovy hepcat Lew Pitcher was jivin' in comp.lang.c on Mon, 18 Mar 2024
01:27 am. It's a cool scene! Dig it.

On 16/03/2024 04:11, fir wrote:

  [Snip.]

int RecolorizePixelAndAdjacentOnes(int x, int y, unsigned old_color,
unsigned new_color)
{
 if(old_color == new_color) return 0;
 
 if(XYIsInScreen( x,  y))
 if(GetPixelUnsafe(x,y)==old_color)
 {
 SetPixelSafe(x,y,new_color);
 RecolorizePixelAndAdjacentOnes(x+1, y,  old_color, new_color);
 RecolorizePixelAndAdjacentOnes(x-1, y,  old_color, new_color);
 RecolorizePixelAndAdjacentOnes(x, y-1,  old_color, new_color);
 RecolorizePixelAndAdjacentOnes(x, y+1,  old_color, new_color);
 return 1;
 }
 
 return 0;
}

  [Snippity doo dah.]

Take fir's example code above; a simple single call to
RecolorizePixelAndAdjacentOnes() will effectively recolour the
origin cell multiple times, because of how the recursion is handled.

  No, I don't think so. You seem to have missed the fact that it checks
the colour of the "current" pixel, and only continues (setting new
colour & recursing) if it is the old colour.
  Of course, I'm infering (guessing) the functionality, at least
partially (Unsafe? Safe?), of GetPixelUnsafe() and SetPixelSafe() based
on their names.

  [Snip Lew's examples.]

--


----- Dig the NEW and IMPROVED news sig!! -----


-------------- Shaggy was here! ---------------
              Ain't I'm a dawg!!