home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / sys / amiga / programm / 17837 < prev    next >
Encoding:
Internet Message Format  |  1992-12-27  |  3.2 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 Pixel Mode for Low End Chip Set?
  4. Message-ID: <jbickers.0m6w@templar.actrix.gen.nz>
  5. From: jbickers@templar.actrix.gen.nz (John Bickers)
  6. Date: 28 Dec 92 10:50:02 PST
  7. References: <Karsten_Weiss.0n2o@ibase.stgt.sub.org> <1hbngoINNglt@uwm.edu>     
  8.  <jbickers.0m2n@templar.actrix.gen.nz> <72410@cup.portal.com>   
  9.  <1992Dec26.170503.14668@mpifr-bonn.mpg.de> 
  10.  <jbickers.0m3z@templar.actrix.gen.nz><1992Dec27.011313.18163@mpifr-bonn.mpg.de
  11.  > <jbickers.0m50@templar.actrix.gen.nz><1992Dec27.155756.23491@mpifr-bonn.mpg.de>
  12. Organization: TAP
  13. Lines: 53
  14.  
  15. Quoted from <1992Dec27.155756.23491@mpifr-bonn.mpg.de> by mlelstv@specklec.mpifr-bonn.mpg.de (Michael van Elst):
  16. > In <jbickers.0m50@templar.actrix.gen.nz> jbickers@templar.actrix.gen.nz (John Bickers) writes:
  17.  
  18. > >    This isn't always the case. For example, if you want to replace
  19. > >    all the blue pixels with red pixels in order to free up a color
  20.  
  21. > Then you don't do this directly in display memory. Or use some blitter
  22. > function to generate a mask and then change the pixels through the mask.
  23.  
  24.     You're kidding, right? Sure it's _possible_ to do it with planes,
  25.     but don't you think it is easier (and it is definitely faster) to
  26.     do it with chunky pixels?
  27.  
  28. > >    Who said anything about calling WritePixel()? Though with chunky
  29. > >    pixels WritePixel() should be faster, making use of such OS
  30. > >    routines more acceptable, which is a plus for RTG.
  31. > 
  32. > WritePixel wouldn't be much faster with chunky pixels. The large overhead
  33. > comes from clipping and calculating bitplane/bitmap addresses.
  34.  
  35.     Well, it should be. Bypassing WritePixel() with chunky pixels will
  36.     be quicker than bypassing WritePixel() with planes. There is only
  37.     one address calculation, and only one write to memory.
  38.  
  39. > Yep, drawing thin lines is a plus on chunky pixel architectures. Floodfills
  40.  
  41.     Any kind of lines.
  42.  
  43. > on the other hand can be faster with bitplanes. Not sure about curve drawing
  44.  
  45.     I don't see how flood filling can be faster with planes. The
  46.     classic method is mostly ReadPixel() and WritePixel() operations,
  47.     which chunky pixels excel at.
  48.  
  49. > but most curve drawing routines I know need several multiplications per point.
  50.  
  51.     So? There are incremental algorithms for drawing some sorts of
  52.     curves (like circles), and having chunky pixels isn't going to
  53.     make the calculation of the curve faster, but it WILL speed up the
  54.     WritePixel() part of the routine significantly.
  55.  
  56.     Anyway, I'm all for a chunky pixel chipset. Even better if it can
  57.     be mixed with other modes on-screen. Not being a hardware person,
  58.     it's easy for me to think that the best way to handle graphics
  59.     boards (with RTG) would have been to have the Copper be able to
  60.     switch to an external graphics source, so external boards could be
  61.     "screens" in the system, scrollable and all. Being able to do this
  62.     without an external graphics board at all would be great.
  63.  
  64. > Michael van Elst
  65. --
  66. *** John Bickers, TAP.                   jbickers@templar.actrix.gen.nz ***
  67. ***    "Radioactivity - It's in the air, for you and me" - Kraftwerk    ***
  68.