Path: utzoo!utgpu!watmath!clyde!att!rutgers!mailrus!ames!oliveb!amiga!jimm
From: jimm@amiga.UUCP (Jim Mackraz)
Newsgroups: comp.sys.amiga
Subject: Re: Non-distruction graphics
Message-ID: <3139@amiga.UUCP>
Date: 26 Nov 88 07:38:24 GMT
References: <6287@dayton.UUCP>
Reply-To: jimm@cloyd.UUCP (Jim Mackraz)
Organization: Commodore-Amiga Inc, Los Gatos CA
Lines: 75

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.