Recursive floodfill Memory Access Violation

[A-man]

I have a recursive function floodfill() which looks like this:

procedure floodfill(x, y, color: integer);
begin
 debugbitmap(image);
 image.pixels[x,y] := color; 
 wait(1);
 if(isvalid(x-1, y))then
   floodfill(x-1, y, color);
 if(isvalid(x+1, y))then
   floodfill(x+1, y, color);
 if(isvalid(x, y+1))then 
   floodfill(x, y+1, color);
 if(isvalid(x, y-1))then
   floodfill(x, y-1, color);
end;

 

This executes fine, and works as it should, however on larger images, it appears to run out of memory, or try writing to an unaccessable memory address. My theory is that each time the function calls itself, memory must be allocated for the x, y, and color parameters. I realize now I should make color global to avoid allocation of the same thing over and over, but my question is how can I avoid the memory violation? The error I get is:

"Access violation at address 014B7200 in module 'scare.exe'. Write of address 7EF21FF4"

 

For extra information, the isvalid() function determines if the pixel is within the image boundaries, as well as if it is the correct color to be filled.

 

EDIT: is there a way to reserve a certain amount of memory beforehand? If I only store x,y per iteration, the most I would need to store is 2 integers per pixel of the image.

Edited September 12, 2012 by A-man

[LordJashin]

I have a recursive function floodfill() which looks like this:

procedure floodfill(x, y, color: integer);
begin
 debugbitmap(image);
 image.pixels[x,y] := color; 
 wait(1);
 if(isvalid(x-1, y))then
   floodfill(x-1, y, color);
 if(isvalid(x+1, y))then
   floodfill(x+1, y, color);
 if(isvalid(x, y+1))then 
   floodfill(x, y+1, color);
 if(isvalid(x, y-1))then
   floodfill(x, y-1, color);
end;

 

This executes fine, and works as it should, however on larger images, it appears to run out of memory, or try writing to an unaccessable memory address. My theory is that each time the function calls itself, memory must be allocated for the x, y, and color parameters. I realize now I should make color global to avoid allocation of the same thing over and over, but my question is how can I avoid the memory violation? The error I get is:

"Access violation at address 014B7200 in module 'scare.exe'. Write of address 7EF21FF4"

 

For extra information, the isvalid() function determines if the pixel is within the image boundaries, as well as if it is the correct color to be filled.

 

EDIT: is there a way to reserve a certain amount of memory beforehand? If I only store x,y per iteration, the most I would need to store is 2 integers per pixel of the image.

 

This confuses me, I don't understand what that function is for...exactly but. Try using HideDebugImgWindow at the end of the function? Maybe try putting IsValid before image.pixels[x, y] := color ?

[FHannes]

Do you check you don't revisit pixels you've already been to? Also, a recursive floodfill function can overflow the memory, I suggest you make it iterative. Finally, SCAR 3.35 already comes with FloodFill(Tol)(Ex).

[A-man]

The isvalid() function checks if the pixel is already colored, and I'm writing it as recursive for the purpose of learning to write recursive functions. My programming professor suggested it might be caused by a stack overflow. How does the iterative algorithm work?

 

Offtopic: is there a reason 2d arrays are implemented using T2dintarray instead of the conventional array[0..x][0..y]? I thought SCAR was written using PASCAL syntax.

[LordJashin]

The isvalid() function checks if the pixel is already colored, and I'm writing it as recursive for the purpose of learning to write recursive functions. My programming professor suggested it might be caused by a stack overflow. How does the iterative algorithm work?

 

Offtopic: is there a reason 2d arrays are implemented using T2dintarray instead of the conventional array[0..x][0..y]? I thought SCAR was written using PASCAL syntax.

 

SCAR uses a compiler, that has similar syntax, but I would say it is more closely related to Delpih/Rad Studio syntax. I think SCAR uses PAX Compiler, but I'm not sure on that or Titan compiler? Arrays can be done tons of ways, but the T2DIntArray is just provided so that it is shorter than having to do the full array[] of array or w/e....

[FHannes]

Well, making an iterative floodfill in SCAR is rather messy as you need to use arrays, normally I'd suggest using a stack or w/e to push points onto.