wbnsnsr@nmtsun.nmt.edu (William Norris) (12/03/88)
Is there a simple way to swap two bitmaps without a third temporary bitmap? I've looked over the MINTERMS, but none seem to do the trick. How come the lower nibble in the MINTERM is always 0? If 0xC0 is a copy, shouldn't 0xCC be a swap? -- wbnsnsr@nmtsun.nmt.edu | /// Seulement William B. Norris IV |\\ /// l'Amiga peut POB #2185 C/S | \\// vous l'offrir. Socorro, NM 87801 |=-=-=-=-=-=-=-=-=-=-=-=-=
ali@polya.Stanford.EDU (Ali T. Ozer) (12/05/88)
In article <1576@nmtsun.nmt.edu> William Norris writes: >Is there a simple way to swap two bitmaps without a third temporary bitmap? Yes, but you need to do multiple blits. To swap A and B: A = A XOR B B = A XOR B A = A XOR B Here's what I do in IFF2PCS (a puzzle program), when the user specifies "show me the solution" (which causes what's on the screen to be swapped with the actual picture, in some bitmap somewhere): To swap: XORFromBMToBM (picbm, 0, 0, winbm, picx, picy, picw, pich); XORFromBMToBM (winbm, picx, picy, picbm, 0, 0, picw, pich); XORFromBMToBM (picbm, 0, 0, winbm, picx, picy, picw, pich); /* Note that the in picbm, the picture is at 0,0, while in winbm, it's ** at picx, picy. The size is picw by pich. */ And the routine XORFromBMToBM is: XORFromBMToBM (srcbm, srcx, srcy, destbm, destx, desty, sizex, sizey) struct BitMap *srcbm, *destbm; int srcx, srcy, destx, desty, sizex, sizey; { BltBitMap (srcbm, srcx, srcy, destbm, destx, desty, sizex, sizey, 0x0060L /* mode */, 0x00ffL, NULL); } Make sure you coerce the args into longs if using Manx with 16 bit ints. Ali Ozer
ali@polya.Stanford.EDU (Ali T. Ozer) (12/05/88)
I just wrote: >In article <1576@nmtsun.nmt.edu> William Norris writes: >>Is there a simple way to swap two bitmaps without a third temporary bitmap? >Yes, but you need to do multiple blits. ... Let me point out that on a 4-bitplane, 640x400 screen, swapping the whole screen using the three-XOR BltBitMap method takes a small but visible fraction of a second. For my purposes, it doesn't matter; it might in some real-time game or something. Actually, the visual effect is kind of neat as the bitmaps are XORed in and out in front of your eyes --- some sort of metamorphosis. Ali Ozer
guilford@rpics (Jim Guilford) (12/05/88)
In article <1576@nmtsun.nmt.edu> wbnsnsr@nmtsun.nmt.edu (William Norris) writes: >Is there a simple way to swap two bitmaps without a third temporary bitmap? > >I've looked over the MINTERMS, but none seem to do the trick. How come >the lower nibble in the MINTERM is always 0? If 0xC0 is a copy, shouldn't >0xCC be a swap? > > >-- >wbnsnsr@nmtsun.nmt.edu | /// Seulement >William B. Norris IV |\\ /// l'Amiga peut >POB #2185 C/S | \\// vous l'offrir. >Socorro, NM 87801 |=-=-=-=-=-=-=-=-=-=-=-=-= I don't have the RKM handy, so I can't give you a detailed answer about 0xC0. Off hand, I would say that the low order nibble is zer because the examples are only using two input sources. In this case there are 2^2 or four minterms (bits) needed. The only time you need to worry about the low order nibble is when you are dealing with three sources (don't quote me on this, this is off the top of my head). In any event, since there is only one destination, it is definately impossible to do a swap in one blit. It is possible to do a swap in three blits without a temp space. If you let your two bit maps be A and B, then the following will swap them: A <- A xor B B <- A xor B A <- A xor B If you check the math: A1 <- A0 + B0 B1 <- A1 + B0 == (A0 + B0) + B0 == A0 + (B0 + B0) == A0 + 0 == A0 A2 <- A1 + B1 == (A0 + B0) + A0 == B0 + (A0 + A0) == B0 Check the RKM, but I would guess that an XOR minterm is $60 ?? --JimG guilford@cs.rpi.edu ...!rutgers!nysernic!rpics!guilford
sns@acp.OZ (Stuart Nixon) (12/08/88)
In article <1576@nmtsun.nmt.edu>, wbnsnsr@nmtsun.nmt.edu (William Norris) writes: > Is there a simple way to swap two bitmaps without a third temporary bitmap? > > I've looked over the MINTERMS, but none seem to do the trick. How come > the lower nibble in the MINTERM is always 0? If 0xC0 is a copy, shouldn't > 0xCC be a swap? > > wbnsnsr@nmtsun.nmt.edu | /// Seulement I seem to remember a trick using three (3) XOR's to swap contents of registers. There should be no reason why the same can not be carried out on Bitmaps using the blitter. It will require three blits to carry out the swap. I have not worked out the MINTERMs to do XORs. However, if my memory serves me correctly, the logic is something like : B = A XOR B ; where A & B are regs/bitmaps/bits/whatever A = A XOR B B = A XOR B ; tada! bits swapped There may be a still quicker way of doing this with the blitter, as it has the ability to accept three inputs. Still, this should give you some ideas... Hope this helps. sns sns Stuart Nixon Software, via Australian Computer Products Phone : +61 9 322 6497 Uucp : ...{uunet,mcvax,ukc}!munnari!acp.oz!sns ACSnet: sns@acp.oz
jimm@amiga.UUCP (Jim Mackraz) (12/13/88)
In article <1946@imagine.PAWL.RPI.EDU> guilford@turing.cs.rpi.edu (Jim Guilford) writes: )In article <1576@nmtsun.nmt.edu> wbnsnsr@nmtsun.nmt.edu (William Norris) writes: )>Is there a simple way to swap two bitmaps without a third temporary bitmap? )> )>I've looked over the MINTERMS, but none seem to do the trick. How come )>the lower nibble in the MINTERM is always 0? If 0xC0 is a copy, shouldn't )>0xCC be a swap? )> )>William B. Norris IV |\\ /// l'Amiga peut Clearly, the blitter can't swap on a single blit, since there is only one destination channel (it can only change one region at a time). So, you can use the old "triple XOR trick", which JimG describes. Or, if you can figure out how it works, you can use SwapBitsRastPortClipRect(). There are some alignment issues, but they are probably unavoidable. Anyway, this function is used to bring up/down menus. 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.