home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / sys / amiga / programm / 18073 < prev    next >
Encoding:
Text File  |  1993-01-03  |  1.5 KB  |  34 lines
  1. Newsgroups: comp.sys.amiga.programmer
  2. Path: sparky!uunet!spool.mu.edu!think.com!enterpoop.mit.edu!bloom-picayune.mit.edu!athena.mit.edu!bwill
  3. From: bwill@athena.mit.edu (Brian F Williams)
  4. Subject: Re: Chunky Pixels vs. Bitplanes (was: Chunky Chip Set...)
  5. Message-ID: <1993Jan3.154450.23710@athena.mit.edu>
  6. Sender: news@athena.mit.edu (News system)
  7. Nntp-Posting-Host: marinara.mit.edu
  8. Organization: Massachusetts Institute of Technology
  9. References: <1993Jan1.141207.20262@mpifr-bonn.mpg.de> <doiron.0kil@starpt.UUCP> <1993Jan3.035112.5898@mpifr-bonn.mpg.de>
  10. Date: Sun, 3 Jan 1993 15:44:50 GMT
  11. Lines: 21
  12.  
  13.  
  14.     Just curious, but if you were to do a bitmap scaling, wouldn't
  15. the planar and chunky implementations run at the same speed?  Couldn't
  16. you do a 'chunky' scale on each bitplane, which in an 8-bit display
  17. would be 1/8 the size of the full display buffer for a real chunky
  18. display.  Yes, you'd do this 8 times, but each time with 1/8th the
  19. data.  Or is it impossible to manipulate a planar display like this?
  20.     You'd probably have to take special care so that pixels
  21. in each plane stay aligned (if the scaling isn't by an integer), but I
  22. don't think it would be that difficult.
  23.  
  24. --Brian
  25.  
  26. p.s. I prefer chunky implementations myself, but after using a Mac, which
  27. can have anywhere from 1 to 24 bit color, I've realized that no routine
  28. can be really fast on the average, you have to optimize your code for your
  29. specific needs.
  30. --
  31. internet: bwill@athena.mit.edu
  32. uucp    : mit-eddie!mit-athena!bwill
  33. bitnet  : bwill@athena.mit.edu
  34.