GPAINT is broken

there is an I shape. When the top leftmost pixel is GPAINTed, the resulting flood misses the top right arm, a bug in the GPAINT filling behavior.

For example, this shape: If you use GPAINT to fill a shape like this (zoomed in view) It doesn't work...

_{oh how terrible!} Do you know why this would happen? Also, where did you start the GPAINT from?

I'm a bit confused by the topic. Are you concerned that it bled through the black lines to fill multiple boxes or that it didn't fill all of them?

I'm a bit confused by the topic. Are you concerned that it bled through the black lines to fill multiple boxes or that it didn't fill all of them?

I think it didn't fill all of them.

12me, use an outline of the whole shape instead of pixel by pixel outlining to explain what you mean.

ACLS
BACKCOLOR -1
FOR J%=0 TO 5
 FOR I%=0 TO 6
  GPSET I%+100,J%+100,_READ()*&hFF<<24
 NEXT
NEXT
GPAINT 101,101,&hFFFF0000
DATA 1,1,1,1,1,1,1
DATA 1,0,0,0,0,0,1
DATA 1,1,1,0,1,1,1
DATA 1,1,1,0,1,1,1
DATA 1,0,0,0,0,0,1
DATA 1,1,1,1,1,1,1
DEF _READ()
 READ TMP
 RETURN TMP
END

Works on 3.3.2, I get the image that 12me21 got.

you guys are really bad at this apparently there is an I shape. When the top leftmost pixel is GPAINTed, the resulting flood misses the top right arm, a bug in the GPAINT filling behavior. I wonder what kind of bug would cause it to not finish though. (EDIT: I only came back to this a long time after writing it so it's a bit... out of order.)

The V360's code also shows a bug with GPAINT coordinates 103,101 (the middle pixel on the top gets painted, neither 'arm' gets painted), 103,104 (same as 103,101, showing that the bug is asymmetrical in the up-down sense), 102,104 (now the left half of the top gets painted but not the right), 104,104 (now the right half of the top gets painted, and not the left). For the record, I have notified SmileBoom of this issue, by giving them a link to this page.