void floodFill(unsigned x, unsigned y, uint8_t fillColour)
{
if((x % 10) == 0)
{
// so I can watch the fill...
Pokitto::Display::update();
}
if((x >= Pokitto::Display::width) || (y >= Pokitto::Display::height))
return;
unsigned colour = Pokitto::Display::getPixel(x,y);
if(colour != fillColour)
{
Pokitto::Display::drawPixel(x, y, fillColour);
if(x < Pokitto::Display::width)
floodFill(x + 1, y);
if(x > 0)
floodFill(x - 1, y);
if(y < Pokitto::Display::height)
floodFill(x, y + 1);
if(y > 0)
floodFill(x, y - 1);
}
}
If that doesn’t work then the problem is almost certainly that the return stack can’t handle it and you’ll have to take a corecursive approach and maintain your own stack.
To be honest, I’m not really suprised it’s falling over.
If you tried to fill from point 0,0 the stack could potentially reach 220 frames on top of whatever was there before it.
Recursion is really only suitable when you won’t need much depth or when the process uses a tail-call which can be optimised away.
The logic was good enough to start testing. It’s most definitively a stack, the function calls itself at least a few hundred times, it is a well known issue with this type of flood fill routine.
Did you test with >= for width and height?
The non-recursive method takes things off the stack and puts them in the heap, but there’s not that much heap either, so it might not solve the problem.
@spinal,
For the record, if you ever see anything with the prefix std::,
it’s almost certainly from the standard library and you need an include for it.
Standard library includes don’t have a .h after them and are generally included with angle brackets.
If in doubt, check the docs.
Really? Odd, min is not supposed to be a macro.
Defining DISABLEAVRMIN before including the PokittoLib is supposed to prevent it from making that macro.