joe@dayton.UUCP (Joseph P. Larson) (11/26/88)
Well, in my never-ending search for Amiga Knowledge, I'm working on
a little draw program. I've implemented the ever-famous rubber-band
line (hold down mouse, move around and line follows, let go and line
solidifies). However, as I move around, I'm destroying what was on
the screen before. My algorithm works something like this:
a. Set startX and startY
b. While mousebuttondown at every IntuitionTick
erase old line drawn on last iteration
draw new line between startX,startY and currX,currY
What I need instead of draw and erase (erase is basically redraw old
line with background color) is draw and recover old. The best method
I have discovered for this would be to write a DrawXOR routine to replace
my use of Draw(). It would XOR the bits in the line with what they are
now instead. Then to erase I can XOR them again. But this sounds rather
slow.
So -- anyone got a better solution? Maybe I should add another bit plane
and just fiddle with the bits in that plane? Ick.
Maybe I have to manipulate everything myself instead of calling Intuition
text and draw routines?
-Joe
--
When you fall on your head do you land on your feet?
UUCP: rutgers!dayton!joe (Feed my Dayton Hudson Department Store Company
ATT : (612) 375-3537 picture Joe Larson/MIS 1060
(standard disclaimer...) collection) 700 on the Mall Mpls, Mn. 55402jimm@amiga.UUCP (Jim Mackraz) (11/26/88)
In article <6287@dayton.UUCP> joe@dayton.UUCP (Joseph P. Larson) writes:
)
)Well, in my never-ending search for Amiga Knowledge, I'm working on
)a little draw program. I've implemented the ever-famous rubber-band
)line (hold down mouse, move around and line follows, let go and line
)solidifies). However, as I move around, I'm destroying what was on
)the screen before. My algorithm works something like this:
)
) a. Set startX and startY
) b. While mousebuttondown at every IntuitionTick
) erase old line drawn on last iteration
) draw new line between startX,startY and currX,currY
)
)What I need instead of draw and erase (erase is basically redraw old
)line with background color) is draw and recover old. The best method
)I have discovered for this would be to write a DrawXOR routine to replace
)my use of Draw(). It would XOR the bits in the line with what they are
)now instead. Then to erase I can XOR them again. But this sounds rather
)slow.
This is the standard trick. It's not particularly slow. Mr. Blitter
is helping, too, and any other trick might cost more.
Do it by SetDrMd( rp, (long) COMPLEMENT );
)So -- anyone got a better solution? Maybe I should add another bit plane
)and just fiddle with the bits in that plane? Ick.
You still have to erase the bits, which is only a little faster than XOR.
)Maybe I have to manipulate everything myself instead of calling Intuition
)text and draw routines?
The hard part of a draggy frame is avoiding unsightly beam collisions, as
found in V1.2 Intuition window dragging/sizing. Standard beam avoidance
technique is to wait out the beam counters. Be warned that on some very
strange Commodore monitors (the A2024), the beam counters are, well ... not
what they seem.
Always be sure to trigger a beam counter trick to fail safe: test for top
of frame or something to make sure you didn't miss your trigger.
)-Joe
This last week I implemented the draggy box in two sprites. Sort of
"Draggy Brackets."
Although using sprites permits you to double buffer the graphics, or to more
easily do "incremental" changing (you really don't ever need to erase the entire
verical lines, since you get to _move_ them instead), I didn't go that
far.
It's a lot of detail. You need to know about screen modes and interlace.
You also need to account for dragged screens (hint: be sure not to assume
that Screen->LeftEdge will always be zero!).
The case of real skinny box also is a pain.
I guess there would be a payoff, if you made it real smooth. Maybe I'll
spend more time on it, and distribute it next DevCon or something.
It would certainly help if Intuition could rely on using this trick: it would
eliminate the need to lock up EVERY window while size/dragging a window frame.
But because not all modes (or View positions!) or application situations guarantee
that I can grab two sprites, it is probably a doomed concept in the system code.
Maybe we can give it over to Workbench, though. Give me a cookie DaveB.
jimm
--
Jim Mackraz, I and I Computing
amiga!jimm BIX:jmackraz
Opinions are my own. Comments regarding the Amiga operating system, and
all others, are not to be taken as Commodore official policy.ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (11/26/88)
In article <6287@dayton.UUCP> joe@dayton.UUCP (Joseph P. Larson) writes: > [ ... ] I'm working on >a little draw program. I've implemented the ever-famous rubber-band >line... However, as I move around, I'm destroying what was on >the screen before. [ ... ] > >What I need instead of draw and erase (erase is basically redraw old >line with background color) is draw and recover old. The best method >I have discovered for this would be to write a DrawXOR routine to replace >my use of Draw(). [ ... ] But this sounds rather slow. > Not slow at all; the graphics.library can draw XOR lines for you. This is the incantation: SetDrMd (rastport, COMPLEMENT); Move (rastport, <here>); Draw (rastport, <there>); There is a bug with COMPLEMENT as documented. The manual says that the FgPen is XORed into the destination. This is wrong. All bits in the destination pixel are complemented (on a 4 plane display, a pixel that was 1 would turn into 14). However, COMPLEMENT does observe the RastPort.Mask field, so you can stick the value you wish to XOR into the bitmap into there. This capability may be necessary if you wish to XOR in a line of a specific color. If you ever choose to add DPaint-style brush grabbing to your program, you may find the above approach insufficient. I started out with the above approach when I first started on Onion, and later had to dump it when things got a little more sophisticated. However, for your purposes, it should be quite sufficient. _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Leo L. Schwab -- The Guy in The Cape INET: well!ewhac@ucbvax.Berkeley.EDU \_ -_ Recumbent Bikes: UUCP: pacbell > !{well,unicom}!ewhac O----^o The Only Way To Fly. hplabs / (pronounced "AE-wack") "Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctor
glenns@microsoft.UUCP (Glenn Steffler) (11/26/88)
In article <6287@dayton.UUCP> joe@dayton.UUCP (Joseph P. Larson) writes: [ wants to draw lines, and then restore old stuff ] >What I need instead of draw and erase (erase is basically redraw old >line with background color) is draw and recover old. The best method >I have discovered for this would be to write a DrawXOR routine to replace >my use of Draw(). It would XOR the bits in the line with what they are >now instead. Then to erase I can XOR them again. But this sounds rather >slow. Are you writing a home brew draw? The Exec draws plenty fast for me... Besides, I seem to have read that the blitter has built in XOR capacity. This then could not be any slower than normal drawing. Albeit, the blitter would have to do a READ and a WRITE to XOR, but it's quick at them type things, it was made for it. >So -- anyone got a better solution? Maybe I should add another bit plane >and just fiddle with the bits in that plane? Ick. TALK ABOUT SLOW!! UGGG!! Another plane ? >Maybe I have to manipulate everything myself instead of calling Intuition >text and draw routines? Wha??? Are you drawing to the window while you are also drawing your lines? If so, then yes, this could be tricky. Otherwise, save hastle and use Intu. > When you fall on your head do you land on your feet? I generally spew blood all over, gag on my spit and die. -- Buggs - Bill the cat for V.P. -- Opps, make that Zippy the Quale for V.P. !
dale@boing.UUCP (Dale Luck) (12/01/88)
In article <1011@microsoft.UUCP> glenns@microsoft.UUCP (Glenn Steffler) writes: > >Albeit, the blitter would have to do a READ and a WRITE to XOR, but it's >quick at them type things, it was made for it. > Regardless of drawing mode, the blitter needs to read and write. We are only modifying one bit in a word and all accesses to chip mem with the blitter are word accesses. -- Dale Luck Boing, Inc. {uunet!cbmvax|pyramid}!amiga!boing!dale Although I do contract work for Amiga-LosGatos, my opinions probably don't represent those of Commodore or its management or its engineers, but I think the world would be a better place if they did.