GPAINT is broken
Root / SmileBASIC Bug Reports / [.]
12Me21Created:
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.
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 ENDWorks 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.