Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!apple!bionet!uwm.edu!psuvax1!rutgers!cbmvax!cbmehq!cbmdeo!jsmami!jsmoller
From: jsmoller@jsmami.UUCP (Jesper Steen Moller)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Implementing moving crosshair...
Message-ID: <18e0d964.ARN1167@jsmami.UUCP>
Date: 24 Mar 91 21:20:40 GMT
References: <1991Mar22.151348.23800@decuac.dec.com> <1991Mar22.122651.29232@kuhub.cc.ukans.edu>
Reply-To: cbmehq!cbmdeo!jsmami!jsmoller (Jesper S. Moller)
Followup-To: comp.sys.amiga.programmer
Organization: Danish SofTech
Lines: 123

In article <1991Mar22.122651.29232@kuhub.cc.ukans.edu>, markv@kuhub.cc.ukans.edu writes:

> In article <1991Mar22.151348.23800@decuac.dec.com>, baker@wbc.enet.dec.com writes:
> > -Message-Text-Follows-
> > 
> > 	Given an Intuition window, I want a pair of lines -- one running
> > 	from the top to the bottom of the window, the other running from
> > 	the left edge to the right edge.  The intersection point of the
> > 	lines should track the mouse.
> > 
> > 	I'm concerned about keeping up with all the MOUSEMOVE's, so I'm
> > 	looking for the most efficient way to implement the cross-hair 
> > 	lines themselves.  I can use either a Bob for each line, or I can
> > 	Draw the lines in COMPLEMENT and move them myself.  Is the use of
> > 	a Bob going to make any real difference ?
> 
> I think for this a BOB would be harder and slower.  I would draw the
> lines in COMPLEMENT (using COMPLEMENT again to remove them of course),
> and special case the code to only redraw the cross-hairs if they've
> moved and only 3-5 times a sec (the user wont need any more often, but
> MOUSEMOVE can spew a lot faster).

If you check for the values, this doesn't mean all that much.

> I do something similar for another program.  I've also seem some machines
> have a fair bit of "jitter" in the mouse values (it seems to be related
> to the physical values in the mouse XY registers being a bit touchcy),
> so I also use a running average of the last few (4) values.  Four was
> picked because I can keep the running average with integer arithmatic:

Why? Isn't it better to tell the user to clean his/her mouse instead.
Intuitions mouse position _is_ the correct one, and I never use
anything else. I have used the cross-hairs many times, and if you check
for changes in coordinates for every MOUSEMOVE, your're ok. Do check
for changes in x and y independently, though. If you inverse the cross-
hairs, you can easily move one of the lines and leave the other one alone.

> 	NewAvg = ((OldAvg * 3) + NewVal) >> 2;
> 
> or for the speed obsessed:
> 
> 	NewAvg = ((OldAvg << 1) + OldAvg + NewVal) >> 2;

I did some research on that when I wrote some 3D routines in assembler
back in 1988. If only doubling, add is better than lsl (or asl for
signed numbers), at least it was on word-sized ints (shorts). So the
optimum would be:

NewAvg = (OldAvg + OldAvg + OldAvg + NewVal) >> 2;

> > 	Also, I'd be interested in any suggestions that would speed up
> > 	tracking on rubber-band lines and stretchable bounding-boxes.

Hmm, experiment with using RectFill for horizontal lines, and Draw for
vertical. If my assumptions are correct, it should be a bit quicker
than using Draw always.
 
> Same rules, keep down the number of draws.  Also, pick the color with
> complement mode so that you only have to flip bits in one-bitplane.
> (JAM1, Color 0 or 1 works well).
  ^^^^^^ What?
COMPLEMENT is the one to use (as you say yourself).

BTW, due to a bug in graphics, FillRect with COMPLEMENT actually inverts
ALL bitplanes (not just the ones in APen). Watch out if you use FillRect().
A workaround (a little dirty...) is to tamper with the rastport's
rp_Mask field. Set this to 1<<DesiredBitPlane, and FillRect, then restore
it to the old value (might need a pair of Forbid()/Permit()). I used that
in my program, and I'm pretty confident that it won't break any Kickstart.


Another optimization:

If you program is using a lot of DMA bandwidth (e.g. 16 colour HIRES),
you gain a lot if you check for any newer MOUSEMOVEs before you draw.

In other words: Each time you get MOUSEMOVEs, update some internal variables.
Just before you reach your Wait (or WaitPort), update these.
As any messages you read in the

while(!0) {

    (void)WaitPort(window->UserPort);

    while(msg=GetMsg(window->UserPort) {

        /* any messages handled here are queued from Intuition */

        if(msg->Class==MOUSEMOVE) UpdateInternalCoords();

        }

    /* Here, Intuition has no more messages for you, so you're not busy! */

    UpdateCrossHairs();
    }

I have used this with luck. The only problem that comes to mind is that
some mouse coordinates are "lost". This doesn't mean a thing if you
want to move a window or to pick a coordinate or mark a brush. But if
you draw lines or pixels, it's rather annoying. Check out DPaint, for
instance. Choose heavy DMA, and choose "Draw" (upper right-hand icon),
and watch! That's why PhotonPaint has a "FollowMouse" switch.
"FollowMouse" corresponds to redrawing once each MOUSEMOVE, the opposite
to the method shown above.

I'm sorry this got so long, but implementing cross-hairs obviously isn't
a piece of cake. Nothing is these days.

> > 	Thanks much.
> > 	 Art Baker

> Mark Gooderum

Thanks, I hope my advice is worth that.

Jesper Steen Moeller, Denmark

--                     __
Jesper Steen Moller   ///  VOICE: +45 31 62 46 45
Maglemosevej 52  __  ///  USENET: cbmehq!cbmdeo!jsmoller
DK-2920 Charl    \\\///  FIDONET: 2:231/84.45
Denmark           \XX/