Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!lll-winken!sun-barr!newstop!sun!amdahl!netcom!mcmahan
From: mcmahan@netcom.UUCP (Dave Mc Mahan)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Flipping a brush horizontally
Message-ID: <11748@netcom.UUCP>
Date: 7 Jul 90 06:59:07 GMT
References: <138441@sun.Eng.Sun.COM>
Distribution: comp.sys.amiga.tech
Organization: Dave McMahan @ NetCom Services
Lines: 48


 In a previous article, jasonf@cetemp.Eng.Sun.COM (Jason Freund) writes:
>
>	I need source code (or at least an algorithm) to 
>flip a dpaint brush horizontally.  Flipping a brush vertically
>is easy, but to flip it horz. requires bit manipulations (I think)
>
>	Is the best way to do it : go across each row of image backwards from
>right to left -- pushing each bit on a stack and then popping it off into
>the new (reversed) image?

Personally, I would not use the stack.  I feel it is too slow and cumbersome,
as well as taking lots of CPU time.  Depending on how much speed you need (is
there REALLY any such thing as too fast?  :-)  I would set a pointer to the left
edge of the brush and one pointer to the right edge (This approach assumes that
you are working in 'C' or assembler and that the brush is a multiple of 8 bits
wide).  I would then read the value from left_ptr into a temp variable, read
the value of right_ptr into a temp variable, and use a lookup table of 256
entries to calculate the bit reversal of both bytes.  Then, I would store the
new value for the left and right sides.  Finally, the left pointer would
increment to the next byte, the right would decrement to the next byte, and the
process would repeat until (left_ptr == right_ptr).  If you can live with just
a noodge less speed and slightly more code complexity, you can get away with
just two 16 value (byte-sized) lookup tables.  One table would figure the bit
reversal from high nibble to low by using the high nibble (shifted right by 4)
as an index and the other table would figure the bit reversal from low nibble
to high.  Both values would be OR'ed together before being saved.  For slightly
less speed than this technique, you could get away with only one 16 value (byte-
sized) lookup table and use it for finding both the high and low nibble values.

Are you now totally confused?  :-)  If so and you want more info, send me 
e-mail.  I'll even figure out the lookup tables for you to use.  To be totally
honest with you, I kind of suspect that programs doing this use the blitter
for maximum speed and smoke.  Blitting isn't something I have done, so I guess
I can't help you there.  If you want to do the above with an arbitrary bit
alignment, you will again have to add more code.  I'd suggest reading stuff in
as 16 bit values (using pointers as described above) shifting to align to what
you need, flipping, re-shifting, and then writing out.  Slower, but it will
work.  The 16 bit pointers would increment 1 byte at a time.  Since using a
16 bit pointer on the 68000 odd-aligned addresses causes a visit from Mr. Guru,
you might need 2 pointers for each value.  As one can see, the complexity of
the 68000 version without blitter help gets tougher by far if we allow
arbitrary bit-alignment.


>Jason Freund

    -dave