CompuServe Thread

Forum unknown · Programming

#Paint Bug?

5 messages in this thread
#85766From: Dale RiceSep 21, 1987 11:45 AM
Ah! Your suggestion was very useful. I found that the following sequence will "fill without spill" from some mouse location (mx,my) to a border of any color: RP&=WINDOW(8) RP& is pointer to rast port mx=MOUSE(1):my=MOUSE(2) mouse location CALL SetAPen&(RP&,currcolor) currcolor has been set previously AREA(mx,my) is AREA command necessary so that proper pointer to BitMap structure is created? CALL FLOOD&(RP&,1,mx,my) voila! Note that FLOOD works only in mode=1 (the "color mode"). In mode=0, as you suggested, color still spills out of borders. Thus I hypothesize that there is a bug in the ROM Kernal FLOOD routine. Perhaps this routine is called by the AmigaBASIC PAINT command, thus the bug surfaces there as well.
#85874From: Ed SilvaSep 22, 1987 12:33 AM
Mode=0: "…You specify an x,y coordinate, and from that point the system searches outward in all directions for a pixel whose color is the SAME as the specified in the outline pen…" Mode=1: "…Whatever pixel is found at x,y defines the area to be filled…" this is what the ROM kernel book says (more or less) on page 2-51 i have the books with the white cover…
#85911From: Dale RiceSep 22, 1987 10:38 AM
My Kernal ROM book (1986: Commodore Electronics) says about the same thing, p47. NEVERTHELESS, if you use mode=0 in the way you described, the color spills past the border consistantly. Try it. I am writing a paint program as an exercise. I am creating nearly identical versions of the program for both the Amiga 1000 and the Apple IIGS, so that I may compare program development times on both machines. Ideally this would be done in C on both machines, but I don't yet have C for the Amiga, and my IIGS C is strange and buggy. The program I am creating is VERY similar to the "Micro Illustrator" program supplied with the KoalaPad for the CBM-64, Apple IIe, etc. Eventually I will place it in the museums computer lab. You may wonder why I don't simply use Deluxe Paint, etc. We have to create most of the software we use on the museum floor, rather than use off-the-shelf stuff. Though this is a "hands-on" museum, visitors are too overwhelmed by most of the "store-bought" software. We spend a lot of time creating less fully featured, "reverse-engineered" versions of other peoples software, especially with simpler and more "friendly" user-interfaces. Incidentally, even though AmigaBASIC has some annoying idiosyncracies, I am impressed by it. (It is BASIC, after all). It has a faintly "C-ish" or " "Pascal-ish" flavor to it. I like the STRUCTURE command, the way you can use sub-programs to add new commands to the language, the way the Kernal tools interface with the language through the LIBRARY and FUNCTION commands. Block IF…THEN…ELSE…ELSEIF is a dream. It occurs to me that these are the same kind of problems Apple should have faced in order to tap their IIGS "toolbox" from, say, 16-bit BASIC. Yet, though Commodore seems to have easily solved these problems, no such BASIC has appeared for the IIGS. Could there be truth to the rumors that Apple is deliberately retarding the IIGS so that it will not compete with the MacIntosh line? They've done stranger things.
#85911From: Dale RiceSep 22, 1987 10:38 AM
My Kernal ROM book (1986: Commodore Electronics) says about the same thing, p47. NEVERTHELESS, if you use mode=0 in the way you described, the color spills past the border consistantly. Try it. I am writing a paint program as an exercise. I am creating nearly identical versions of the program for both the Amiga 1000 and the Apple IIGS, so that I may compare program development times on both machines. Ideally this would be done in C on both machines, but I don't yet have C for the Amiga, and my IIGS C is strange and buggy. The program I am creating is VERY similar to the "Micro Illustrator" program supplied with the KoalaPad for the CBM-64, Apple IIe, etc. Eventually I will place it in the museums computer lab. You may wonder why I don't simply use Deluxe Paint, etc. We have to create most of the software we use on the museum floor, rather than use off-the-shelf stuff. Though this is a "hands-on" museum, visitors are too overwhelmed by most of the "store-bought" software. We spend a lot of time creating less fully featured, "reverse-engineered" versions of other peoples software, especially with simpler and more "friendly" user-interfaces. Incidentally, even though AmigaBASIC has some annoying idiosyncracies, I am impressed by it. (It is BASIC, after all). It has a faintly "C-ish" or " "Pascal-ish" flavor to it. I like the STRUCTURE command, the way you can use sub-programs to add new commands to the language, the way the Kernal tools interface with the language through the LIBRARY and FUNCTION commands. Block IF…THEN…ELSE…ELSEIF is a dream. It occurs to me that these are the same kind of problems Apple should have faced in order to tap their IIGS "toolbox" from, say, 16-bit BASIC. Yet, though Commodore seems to have easily solved these problems, no such BASIC has appeared for the IIGS. Could there be truth to the rumors that Apple is deliberately retarding the IIGS so that it will not compete with the MacIntosh line? They've done stranger things.
#85874From: Ed SilvaSep 22, 1987 12:33 AM
Mode=0: "…You specify an x,y coordinate, and from that point the system searches outward in all directions for a pixel whose color is the SAME as the specified in the outline pen…" Mode=1: "…Whatever pixel is found at x,y defines the area to be filled…" this is what the ROM kernel book says (more or less) on page 2-51 i have the books with the white cover…