jasonf@cetemp.Eng.Sun.COM (Jason Freund) (07/06/90)
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? Detailed descriptions or source code welcomed. Specifically, I want to reverse a brush in 320 X 200 EHB (6 bit plane) mode (I know that any paint program does this, but I want to be able to do it inside of a program) Thanks Jason Freund jasonf@cetemp.Corp.sun.com
mcmahan@netcom.UUCP (Dave Mc Mahan) (07/07/90)
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