FloodFill problem

Wed, 03 Jan 2001 Charles Vidal wrote:

Sorry, but it works now.
( I don’t what I have done wrong befoire :(.

The stop color is 0,0,0.

void floodfill(SDL_Surface *s,int x,int y,Uint8 r,Uint8 g,Uint8 b) {
Uint8 rg,gg,bg;
if (x<0 || y<0 || x>=s->w || y>=s->h ) return;
getRbgPixels(s,x,y,&rg,&gg,&bg);
if (rg==0 && gg== 0 && bg== 0 ) return;
if (rg==r && gg== g && bg== b ) return;
setRbgPixels(s,x,y,r,g,b);
floodfill(s,x+1,y,r,g,b);
floodfill(s,x-1,y,r,g,b);
floodfill(s,x,y+1,r,g,b);
floodfill(s,x,y-1,r,g,b);
}

This consumes lots of stack space… (Most compilers on most platforms will
expand the r, g and b arguments to int16 or int32 for proper stack alignment.)

Funny version:

Make the recursive function smarter, so that it does more work before giving up
and returning. For example, a Snake/Worm/… navigation algorithm could be
used, shooting off recursive branches when passing (not hitting, that is!)
adjacent filled or stop pixels. (This rule is required to make sure that the
worm doesn’t cut areas off, causing them not to be filled. I think…) Could
generate some interesting effects if slowed down to a few iterations per frame,
or combined with some modulation of the fill color. (The latter would need
separate storage to keep track of filled pixels.)

Serious version:

You could try iterating over the screen scanline by scanline, using a bit map
representing the filled pixels. (One bit per pixel, that is.) Substitute the
recursive calls for checks against this bitmap to generate a “do fill” result,
which, if true, results in the actual pixel check to be performed.

The bitmap check can be heavily optimized: Just shift bits in as you go, mask
out a 3 bit “word” (x-1, x and x+1 on the row above the current pixel), and
check the result against zero. If zero, the current pixel is not connected to
the fill area and should not be filled regardless of color.

Do every other sweep in reverse order (from bottom to top), and keep iterating
until no new pixels are to be filled.

Also, as pointed out earlier, it would be a lot faster and more reliable to
deal with pixel values, rather than RGB - especially if the actual target uses
a palette.

//David

…- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' ..- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter | --------------------------------------> david at linuxdj.com -’