# FloodFill stack overflow

This is a discussion on FloodFill stack overflow within the A Brief History of Cprogramming.com forums, part of the Community Boards category; >except that the floodfill quality suffers how's that? the idea of segmenting the target image, checking adjacency, and running through ...

1. >except that the floodfill quality suffers

how's that? the idea of segmenting the target image, checking adjacency, and running through your call with a maximum reiterative depth should work as well as if you didn't have the problem of the stack. and i might do this before dealing with the stack manually, but as i'm aware you are more handy with the stack than i am so it's at your discretion...

2. Yes the quality does suffer. Since the algorithm is recursive, any small adjustment to the main algo, or the way in which it is called can cause catastrophic effects. Remember, that one mistake or incosistency will be multiplied literally thousands of times resulting in poor floodfill.

3. well it doesn't have be completely reiterative... for example call a setup function which does call the filling function with adjacently connected solid colorstate... if your maximum possibly filled coordinate plane is 640 by 480, call every hmm... 10 pixels [2d isometricallly tho, since those are the nature of the rate of spreading in your function...]... hmm we'll have to talk about this in live bubba, get online if you can... asap... it'd be easier to describe... oh, or you could use salem's references btw, but that wouldn't be as fun would it! DOS- ON!

4. Salem you are talking about the parity algo. You check on the line that was clicked and go left and right from origin. If the value is 1, you have left the figure, if the number is 2, you are back in the figure, if the number is 3, draw a line on current scanline between 2 and 3, and so on, and so on.

That would work. And it should fill arbitrary shapes. I saw that algo in my research, I just was not sure whether to use it or not.

Similar to the polygon fill algo which is used to get a solid fill of polygons at an arbitrary angle.

There is one problem, that I can see. What if there is another figure left/right of the current figure and the same color as the current one, but not attached to the current figure. It would still fill that shape since it met the requirements.

5. The second link looks more promising than the first. I need to fill an area that does not have defined points - like drawing a shape in a drawing program and then filling it.

I already know how to fill/texture vertex based polies.

Thanks Salem for the links. I looked through several pages of searches, but did not find the second link. I did find the first on my own, however.

6. oh i see the behaivior now... if you do unwinding with a switch on the reiterative statement, [setting a static unwinding flag, which if set takes the case of an empty function, thus returning until the depth of recursion is to a lower level], you'd have to save the coordinates where to redo the loop, as well as save those coordinates where the path diverged [first began to reiterate, to fill the left holes after each unwinding which are lost when you lose the recursion from manual unwinding]. Hmm that's a mouthful...

7. Hey. I am new to C++ but from what i have read of this thread, the stack is receiving every single parameter you pass, and thus making it stack up very quickly. (f i am wrong in my thinking anywhere, feel free to let me know)

In order to lessen your parameters, you could use a static variable or a global variable to get the parameters through without using them as parameters, or you could group parameters together with a class or struct and just pass that (or a ref to that if speed is a concern).

I may be wrong!

thanx for taking the time to read.

~Inquirer

Page 2 of 2 First 12