On 2005-09-19 at 12:34:27 [+0200], Stefano Ceccherini wrote: > > >Ok, I think I found the problem. > > Me again :) > Sorry to reply to my own posts, but I think that can be fixed by changing > the line > "top = bottom + 1;" > > in OrRegionComplex() to > > "top = max_c(bottom + 1, min_c(first.data[a].top, second.data[b].top));". This won't work. E.g. when all rects in "second" are already through, b will point to the last of its rects, whose top will be <= the previous band's bottom. Thus the next band's top will be "bottom + 1" again, even if there's still a rect in "first" which starts farther down. I can say that it doesn't work with certainty, because the change you proposed, was what I tried myself first. :-) The idea I had after that, though I never tried that (since just replacing the ASSERT by a return was so much simpler :-), was to use the line you propose, but only when both regions aren't though yet (i.e. the bottom of their last rects has not been passed yet). Otherwise the concerned region(s) would be ignored in the calculation of the next "top". CU, Ingo PS: BTW, I'm not sure, if the conditions for updating the indices in ROr() couldn't be improved. Currently for the first region it is: if (first.data[x].bottom >= top && *indexA == -1) *indexA = x; Though I suspect we could as well compare with ">= bottom" here, since a rect that doesn't fullfil this condition too, will be skipped in the next iteration anyway. Then the final check if (*indexA == -1) *indexA = i1; should probably better set *indexA to first.count - 1. PPS: This passing of similar parameters and backpassing of indices through pointers between the involved functions looks a bit like refactoring the stuff into a helper class that uses non-static methods might be a good idea.