Forum unknown
· Programming
#Paint Bug?
5 messages in this thread
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.
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…
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.
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.
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…