jpexg@mit-hermes.ARPA (John Purbrick) (08/10/86)
I have an Atari 1040ST, and I've been playing with its bit-mapped graphics. One thing that the Mac does when running MacPaint is let you start a line by clicking on a point, then flopping the other end around with the mouse until you anchor it by clicking again. If the display is bit-mapped, what I'd expect to see is that every time the flopping line leaves a point on the screen, that point would have to be redrawn or you'd see a whole row of blank points in every object crossed by the line. Yet this doesn't happen. Surely the whole screen isn't redrawn every time a line is moved? An alternative would be to have two planes which are automatically or-ed together to generate the display, so one could be permanent and one temporary, but the ST certainly doesn't do this--does Macintosh? --John Purbrick
sansom@trwrb.UUCP (Richard Sansom) (08/11/86)
In article <2693@mit-hermes.ARPA> jpexg@mit-hermes.ARPA (John Purbrick) writes: >I have an Atari 1040ST, and I've been playing with its bit-mapped graphics. >One thing that the Mac does when running MacPaint is let you start a line >by clicking on a point, then flopping the other end around with the mouse >until you anchor it by clicking again. If the display is bit-mapped, what I'd >expect to see is that every time the flopping line leaves a point on the >screen, that point would have to be redrawn or you'd see a whole row of blank >points in every object crossed by the line. Yet this doesn't happen. Surely >the whole screen isn't redrawn every time a line is moved? An alternative >would be to have two planes which are automatically or-ed together to >generate the display, so one could be permanent and one temporary, but >the ST certainly doesn't do this--does Macintosh? > --John Purbrick The technique used is called XOR (eXclusive-OR). What happens is this: once the first point of the line has been clicked (or "anchored"), then everytime the mouse moves, a line is drawn from the anchor to the new pointer position. However, instead of blindly erasing whatever is underneath the line, the screen's bit image is preserved by XORing the line's bit image with the screen image. Now, the _next_ time the mouse moves, the line is again drawn using the XOR mask, thus restoring the background to its previous state. Once the mouse positions the pointer in its final location and is clicked, then the line is drawn "permanently". Of course, most programs also use the "double-buffer" as well, so that any individual action can be "undone". Anyway, here's an example of how this works: Screen: Line: Screen XOR Line: 0010000 0000010 0010010 0100010 0000100 0100110 0111000 0001000 0110000 <-- note "hole" in this byte 0000100 0010000 0010100 0001000 0100000 0101000 0000000 1000000 1000000 XOR Screen: Line: Original Screen: 0010010 0000010 0010000 0100110 0000100 0100010 0110000 0001000 0111000 0010100 0010000 0000100 0101000 0100000 0001000 1000000 1000000 0000000 Hope this helps you a bit (;-). -- __________ ______ ____ _____ ___ /_________//___ ||__|/____|/__/ Richard E. Sansom ___ ____/ / ____________ TRW Electronics & Defense Sector / / / /\ < | /| / One Space Park Drive, R3/1028 / / / / \ \ | / | / Redondo Beach, CA 90278 /__/ /__/ \__\|__/ |__/ {...decvax,ucbvax,ihnp4}!trwrb!sansom
pvf@bridge2.UUCP (08/12/86)
The rubberband line effect is easy to get on the ST. GEM supports
an XOR writing mode, where each graphic that you place on the screen
is automatically XORed with the existing pattern. As a previous
followup pointed out, this is the way to do the job.
The rubberband line is a simple call to polyline with the XOR writing
mode enabled. All you have to do is draw the line from the fixed point
to the variable point, under XOR writing mode:
1) When the variable point selector moves to a point, and,
2) When the variable point selector moves off that point.
Of course, this means that each line is "drawn" twice. First, to
make it visible, then again to make it invisible.
I have implemented some input routines that coordinate the mouse with
a rubberband line, and they are surprisingly fast considering that
the rubberband line is drawn twice for each individual point to which
the mouse moves during the operation.
BTW an interesting effect is a multiple rubberband line where there are
several fixed points and a single variable point. A three point system
is simplest. Just issue a polyline call supplying three points. The
first and last are the fixed points, the second has the coordinates of
the variable point.
This can easily be expanded to handle the display a closed polygon
with rubberband lines showing where the lines would be if you closed
the polygon at any particular time.
By the way, bad as they may be (in some peoples opinions), all the above
info was found in the ABACUS books and a little thought, so while they
may not be the best, they can help.tim@ism780c.UUCP (Tim Smith) (08/12/86)
In article <1232@trwrb.UUCP> sansom@trwrb.UUCP (Richard Sansom) writes: > >The technique used is called XOR (eXclusive-OR). What happens is this: [description of XOR] Nice theory. Too bad it's wrong! Take a close look next time you are running Macpaint. -- "I *DO* believe in Mary Worth" Tim Smith USENET: sdcrdcf!ism780c!tim || ima!ism780!tim Compuserve: 72257,3706 Delphi || GEnie: mnementh
wrs@k.cs.cmu.edu (Walter Smith) (08/13/86)
In article <1232@trwrb.UUCP>, sansom@trwrb.UUCP (Richard Sansom) writes: > > In article <2693@mit-hermes.ARPA> jpexg@mit-hermes.ARPA (John Purbrick) writes: > >One thing that the Mac does when running MacPaint is let you start a line > >by clicking on a point, then flopping the other end around with the mouse > >... > > The technique used is called XOR (eXclusive-OR). > ... Most programs do use XOR. MacDraw, for instance, leaves things in OR mode until you start to manipulate an object, then redraws that object in XOR to allow rubber-band feedback. However, if you look closely at a line being drawn in MacPaint, you will see that XOR mode is NOT being used. The line is solid black all the way through, whatever the original contents of the screen. Apparently, MacPaint saves the original bitmap not only for Undo, but also for redrawing the screen contents during rubber-banding. The CopyBits is carefully synchronized to the vertical retrace time for maximum smoothness. Another example of attention to detail (there are a lot of them in MacPaint), something Microsoft should probably investigate. - Walt -- Walter Smith, CS undergraduate, Carnegie-Mellon University uucp: ...!seismo!cmu-cs-k!wrs ARPA: wrs@k.cs.cmu.edu usps: 5139 Forbes Ave.; Pittsburgh, PA 15213
sansom@trwrb.UUCP (Richard Sansom) (08/14/86)
In article <1050@k.cs.cmu.edu> wrs@k.cs.cmu.edu (Walter Smith) writes: >In article <1232@trwrb.UUCP>, sansom@trwrb.UUCP (Richard Sansom) writes: >> >> In article <2693@mit-hermes.ARPA> jpexg@mit-hermes.ARPA (John Purbrick) writes: >> >One thing that the Mac does when running MacPaint is let you start a line >> >by clicking on a point, then flopping the other end around with the mouse >> >... >> >> The technique used is called XOR (eXclusive-OR). >> ... > >Most programs do use XOR. MacDraw, for instance, leaves things in OR mode >until you start to manipulate an object, then redraws that object in XOR to >allow rubber-band feedback. > >However, if you look closely at a line being drawn in MacPaint, you will see >that XOR mode is NOT being used... > >- Walt Oops, I guess I spoke too soon. I was thinking about some of the programs I had used in the past, and not specifically about MacPaint. Sorry if I upset anyone out there. -- __________ ______ ____ _____ ___ /_________//___ ||__|/____|/__/ Richard E. Sansom ___ ____/ / ____________ TRW Electronics & Defense Sector / / / /\ < | /| / One Space Park Drive, R3/1028 / / / / \ \ | / | / Redondo Beach, CA 90278 /__/ /__/ \__\|__/ |__/ {...decvax,ucbvax,ihnp4}!trwrb!sansom
marchesi@cernvax.UUCP (marchesi) (08/15/86)
In article <208@bridge2.UUCP> pvf@bridge2.UUCP writes: >......... >The rubberband line is a simple call to polyline with the XOR writing >mode enabled. All you have to do is draw the line from the fixed point >to the variable point, under XOR writing mode: > > 1) When the variable point selector moves to a point, and, > 2) When the variable point selector moves off that point. > >Of course, this means that each line is "drawn" twice. First, to >make it visible, then again to make it invisible. >......... ...again: MacPaint does *NOT* XOR...... (but I'd like to learn how it really works without having to trace it down myself...) pp ---------------------------------------------------------------------------- Paolo Petta p-mail: DD Division CERN CH-1211 Geneva 23 Switzerland e-mail: ...{seismo,philabs,decvax,...}!mcvax!cernvax!marchesi
jpexg@mit-hermes.ARPA (John Purbrick) (08/16/86)
> The rubberband line effect is easy to get on the ST. GEM supports > an XOR writing mode, where each graphic that you place on the screen > is automatically XORed with the existing pattern.... > The rubberband line is a simple call to polyline with the XOR writing > mode enabled.... I got no less than 5 replies to my original posting, only one of which disagreed with the above. The problem is, if you XOR, then of course any existing line crossed by the rubber-band (or "flopping") line will get a hole in it where the new line crosses. I thought I looked at a friend's Mac while doing this, and saw no such hole, but I'll check again. Here's the lone dissenter--name removed as it was private mail: Actually, MacPaint keeps the old screen buffer and copies it back each time you move the line to restore the original image. It doesn't do XOR--if you notice, the line always looks like it will when you finish moving it. Bill Atkinson has a special routine that copies his "save" bitmap VERY quickly to the screen for just this kind of application, thus the fixed window size. So what does everyone else think of this? To me, it has the ring of truth about it. --jp
wca@ut-ngp.UUCP (William C. Anderson) (08/17/86)
In article <2694@mit-hermes.ARPA>, jpexg@mit-hermes.ARPA (John Purbrick) writes: > Here's the lone dissenter--name removed as it was private mail: > > Actually, MacPaint keeps the old screen buffer and copies it back each > time you move the line to restore the original image. It doesn't do > XOR--if you notice, the line always looks like it will when you finish > moving it. Bill Atkinson has a special routine that copies his "save" > bitmap VERY quickly to the screen for just this kind of application, > thus the fixed window size. > > So what does everyone else think of this? To me, it has the ring of truth > about it. > --jp This is a possibility, but I think that there are more efficient ways to rubberband an OR line. One strategy that could be used is to do "reverse Bresenham": instead of *drawing* a line according to a Bresenham DDA algorithm, go out to the screen and *copy* the data that is in the area to be drawn over into some buffer, using the same positioning logic (DDA) that is used in Bresenham line drawing. Then draw the line. When you move the line, just replace the stuff you copied from the screen and recycle the procedure. A bit more complex than the XOR technique of drawing the line twice, but it does the trick with a minimum of copying and buffer space (which was certainly at a premium in the 128K Mac). I have seen this technique used in some Multibus graphics buffer boards. It's not too difficult and would require considerably less data moving and buffer space than copying the entire screen. Since Atkinson did lots of custom code for MacPaint, it is not inconceivable that he used this technique. But we'll never *really* know, will we? William Anderson - University of Texas Computation Center
bhyde@inmet.UUCP (08/18/86)
In MacPaint the tricks for managing to move an object around are much more sophisticated than XOR. An entire copy of the bit image being over drawn is maintained. During each cycle the saved copy is restored and then the tool's dynamic portion is smashed into that. Of course this requires that it be real quick and/or use the alternate video area.
steele@unc.UUCP (Oliver Steele) (08/18/86)
In article <2694@mit-hermes.ARPA> jpexg@mit-hermes.ARPA (John Purbrick) writes: > > Actually, MacPaint keeps the old screen buffer and copies it back each > time you move the line to restore the original image. It doesn't do > XOR--if you notice, the line always looks like it will when you finish > moving it. Bill Atkinson has a special routine that copies his "save" > bitmap VERY quickly to the screen for just this kind of application, > thus the fixed window size. > >So what does everyone else think of this? To me, it has the ring of truth >about it. > --jp Almost. You'll notice that there's no flicker when you move the line, as there would be if MP constantly copied the old screen buffer onto the real screen and then did the draw (even Atkinson&Quickdraw can't beat a vertical retrace on circles that huge). Rather, MP copies the effected portion of the old screen buffer onto a temporary buffer (affected portion=union of rectangle within which last instance was drawn and this instance), does the draw in the temp buffer, and then copies the temp buffer onto the actual screen. Atkinson gave a mini-speech here about {software,human}-engineering about a year ago, and said that using the mini-buffer slowed things down by about a third, but that it actually looked faster to the user since things didn't flicker when foo moved them. Incidentally, this is the way a lot of arcade games used to work on the old {1,2,4}meg 8-bit machines with fixed screen space, like the Model I/III TRS-80. Anybody remember Big Five Software? new screen. -- Oliver Steele----------------------------------steele@unc ...!{decvax,ihnp4}!mcnc!unc!steele (usenet) steele%unc@csnet-relay.csnet (arpanet)