Path: ...!weretis.net!feeder6.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: fir <fir@grunge.pl>
Newsgroups: comp.lang.c
Subject: Re: filling area by color atack safety
Date: Wed, 20 Mar 2024 01:26:34 +0100
Organization: i2pn2 (i2pn.org)
Message-ID: <utdaf8$2ec1d$1@i2pn2.org>
References: <ut3669$21eur$1@i2pn2.org> <ut4020$2s8ov$1@dont-email.me> <ut6ul9$3gr73$1@dont-email.me> <311nck-im1.ln1@hendrix.foo>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 20 Mar 2024 00:26:17 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="2568237"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="+ydHcGjgSeBt3Wz3WTfKefUptpAWaXduqfw5xdfsuS0";
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:27.0) Gecko/20100101 Firefox/27.0 SeaMonkey/2.24
X-Spam-Checker-Version: SpamAssassin 4.0.0
In-Reply-To: <311nck-im1.ln1@hendrix.foo>
Bytes: 3473
Lines: 74

Peter 'Shaggy' Haywood wrote:
> 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.]
>

Safe and Unsafe means that Safe checks if the x,y is in the array of 
pixels, when Unsafe just writes without checking - i draw in array of 
unsigned 32 bit ARGB or GBRA (never remeber) pixels - then i blit that
'bitmap' on window client size as it can be done in winapi

here are exact code

inline void SetPixelUnsafe(int x, int y, unsigned color)
{
   extern int frame_size_x ;
   extern int frame_size_y ;
   extern unsigned int* frame_bitmap ;

   frame_bitmap[y*frame_size_x+x]=color;
}


inline void SetPixelSafe(int x, int y, unsigned color)
{
    //  if(frame==0) ERROR_EXIT("frame is zero in setpixelsafe ");
      if(x<0)              return;
      if(x>frame_size_x-1) return;
      if(y<0)              return;
      if(y>frame_size_y-1) return;

      frame_bitmap[y*frame_size_x+x]=color;
}


there was soem mistake in that function before as if i check already i 
should be using Unsafe versions of setpixel and getpixel but i tested 
this for work not for optimisation so i didnt care