home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / sys / amiga / programm / 18034 < prev    next >
Encoding:
Internet Message Format  |  1993-01-01  |  3.1 KB
  1. Path: sparky!uunet!wupost!waikato.ac.nz!comp.vuw.ac.nz!actrix!templar!jbickers
  2. Newsgroups: comp.sys.amiga.programmer
  3. Subject: Re: Chunky Pixels vs. Bitplanes (was: Chunky Chip Set...)
  4. Message-ID: <jbickers.0mem@templar.actrix.gen.nz>
  5. From: jbickers@templar.actrix.gen.nz (John Bickers)
  6. Date: 2 Jan 93 11:33:59 PST
  7. References: <1992Dec30.115759.22097@mpifr-bonn.mpg.de> <doiron.0ka3@starpt.UUCP> 
  8.  <1992Dec31.011428.2926@mpifr-bonn.mpg.de> <C03uC5.15o@unix.portal.com> 
  9.  <1992Dec31.174137.10865@mpifr-bonn.mpg.de> <jbickers.0mdl@templar.actrix.gen.nz> <1993Jan1.142652.20451@mpifr-bonn.mpg.de>
  10. Organization: TAP
  11. Lines: 56
  12.  
  13. Quoted from <1993Jan1.142652.20451@mpifr-bonn.mpg.de> by mlelstv@speckled.mpifr-bonn.mpg.de (Michael van Elst):
  14. > In <jbickers.0mdl@templar.actrix.gen.nz> jbickers@templar.actrix.gen.nz (John Bickers) writes:
  15.  
  16. > >    So do you concede that 8-bit chunky pixels are indeed faster than
  17. > >    8-bit planar pixels for CPU-driven drawing operations?
  18. > 
  19. > *sigh*. They are slightly faster for area operations and significantly
  20. > faster for non-horizontal line drawing. But I was not talking about
  21.  
  22.     Well, that's the key thing. As for the rest (< 8 planes), the
  23.     differences are not so clear-cut. On the one hand you have to
  24.     shift and mask so much for bitplanes, on the other you waste bits
  25.     for chunky pixels, or end up stuffing several pixels into each
  26.     byte, which approaches having planes (exactly equivalent for 1-bit
  27.     pixels, eh?).
  28.  
  29.     You also lose all the marvellous things you can do with the
  30.     bitplane pointers, but if such pointers aren't documented in the
  31.     future it doesn't matter, eh? :)
  32.  
  33. > >    Can you present your algorithm for bitmap scaling that performs as
  34. > >    well as a chunky-pixel based algorithm?
  35. > 
  36. > It uses a 256k table (64k longwords) or less when I have a processor that can
  37. > do several instructions during video memory accesses. Why would that slow down 
  38. > the algorithm ?
  39.  
  40.     This is a nice approach, though it gets more complicated when you
  41.     want to scale by some factor other than 2 or 4. For each end of
  42.     the horizontal lines you are scaling, you also need to mask off
  43.     the source and destination areas, if any, that shouldn't be
  44.     affected. You may also have to shift the results if the source and
  45.     destination are not aligned with each other.
  46.  
  47. > >    Me. A digital dissolve is basically filling an area by writing
  48. > >    single pixels.
  49. > 
  50. > Hmm. I thought it was a mapping operation.
  51.  
  52.     Well, call it what you will but it's still filling an area by
  53.     writing single pixels.
  54.  
  55. > >    Horizontal wipes do indeed fill the screen with vertical lines.
  56. > 
  57. > True.. Now, who talks about special cases :) BTW, you do not want to
  58. > make a horizontal wipe arbitrarily fast. It could become invisible :)
  59.  
  60.     Heh. I would like to be able to complete a vertical rectangle
  61.     within one frame though. You can do it quite nicely by copying in
  62.     8-pixel wide strips, until you get a case where you need to mask
  63.     and shift.
  64.  
  65. > Michael van Elst
  66. --
  67. *** John Bickers, TAP.                   jbickers@templar.actrix.gen.nz ***
  68. ***    "Radioactivity - It's in the air, for you and me" - Kraftwerk    ***
  69.