home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / sys / amiga / programm / 18033 < prev    next >
Encoding:
Internet Message Format  |  1993-01-01  |  2.0 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.0med@templar.actrix.gen.nz>
  5. From: jbickers@templar.actrix.gen.nz (John Bickers)
  6. Date: 2 Jan 93 10:46:11 PST
  7. References: <Karsten_Weiss.0n2o@ibase.stgt.sub.org> <1hbngoINNglt@uwm.edu> 
  8.  <1992Dec31.011428.2926@mpifr-bonn.mpg.de> <doiron.0kd5@starpt.UUCP> <1993Jan1.141207.20262@mpifr-bonn.mpg.de>
  9. Organization: TAP
  10. Lines: 39
  11.  
  12. Quoted from <1993Jan1.141207.20262@mpifr-bonn.mpg.de> by mlelstv@speckled.mpifr-bonn.mpg.de (Michael van Elst):
  13.  
  14. > And as I also pointed out, bitmap scaling (that's what you thought of)
  15. > is about same speed for chunky and bitplanes.
  16.  
  17.     You seem to have some magnificent algorithms up your sleeve.
  18.     Perhaps we could get this thread onto more .programmer things if
  19.     you outlined some of these algorithms?
  20.  
  21. > YOU may do it that way. I simply use a table that maps several pixels
  22. > to their scaled counterparts.
  23.  
  24.     So to expand 4x, you have a 256x4 table mapping source bytes onto
  25.     destination longs? Makes sense!
  26.  
  27. > Most time consuming graphics operations consist of modifying larger areas,
  28. > drawing diagonal lines or lots of number crunching to generate an image.
  29.  
  30.     ...
  31.  
  32. > In the second case you have a major advantage for chunky pixels. But
  33. > the fact that lines cover less memory than filled areas and some
  34. > optimizations possible with non-vertical lines make this advantage less
  35. > important.
  36.  
  37.     It is not less important. You have to do the drawing portion of
  38.     the line 8 times, which taxes ones ability to hold all the
  39.     required values in registers.
  40.  
  41. > In the third case the rendering speed isn't important as the calculations
  42. > outweigh any efficiency differences.
  43.  
  44.     FractInt would be easier to port and run faster if it was using
  45.     chunky pixels.
  46.  
  47. > Michael van Elst
  48. --
  49. *** John Bickers, TAP.                   jbickers@templar.actrix.gen.nz ***
  50. ***    "Radioactivity - It's in the air, for you and me" - Kraftwerk    ***
  51.