home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / sys / amiga / programm / 18077 < prev    next >
Encoding:
Text File  |  1993-01-03  |  3.5 KB  |  90 lines
  1. Newsgroups: comp.sys.amiga.programmer
  2. Path: sparky!uunet!math.fu-berlin.de!uni-paderborn.de!urmel.informatik.rwth-aachen.de!Germany.EU.net!mpifr-bonn.mpg.de!specklec.mpifr-bonn.mpg.de!mlelstv
  3. From: mlelstv@specklec.mpifr-bonn.mpg.de (Michael van Elst)
  4. Subject: Re: Chunky Pixels vs. Bitplanes (was: Chunky Chip Set...)
  5. Message-ID: <1993Jan3.204843.15155@mpifr-bonn.mpg.de>
  6. Sender: news@mpifr-bonn.mpg.de
  7. Nntp-Posting-Host: specklec
  8. Organization: Max-Planck-Institut f"ur Radioastronomie
  9. References: <Karsten_Weiss.0n2o@ibase.stgt.sub.org> <1hbngoINNglt@uwm.edu>             <1993Jan3.035112.5898@mpifr-bonn.mpg.de> <doiron.0kl6@starpt.UUCP>
  10. Date: Sun, 3 Jan 1993 20:48:43 GMT
  11. Lines: 77
  12.  
  13. In <doiron.0kl6@starpt.UUCP> doiron@starpt.UUCP (Glenn Doiron) writes:
  14. >Yes, but you could use 256-color chunky pixels instead of 1024 color planar
  15. >pixels and chunky would be faster.
  16.  
  17. Simply to get more colors when needed.
  18.  
  19. >I still, however, don't understand why
  20. >you are using scaling like it's the next best thing since the Amiga, you
  21. >are operating under reduced capacity.
  22.  
  23. Because often you don't need full capacity. Using screens with different
  24. resolutions is one solution to the problem. Having layers that simply
  25. leave bitplanes untouched is another solution.
  26.  
  27. A very popular example for this is a text window on top of a coloured
  28. background.
  29.  
  30. >(inner loop)
  31. > x'=x * (1/xscale)
  32. > y'=y * (1/yscale)    ;which does scaling
  33. > getpixel(x',y'): putpixel(x,y)
  34.  
  35. Well, this isn't really scaling (which would need to calculate new
  36. pixel values, f.e. with a linear filter). However, you wouldn't use
  37. this algorithm in the form given as you want to avoid multiplications
  38. and divisions.
  39.  
  40. > xrot=cos(theta)/xscale
  41. > yrot=sin(theta)/yscale
  42. >(inner loop)
  43. > x'=x * xrot
  44. > y'=y * yrot    ;which will do your scaling and rotation in one fell swoop. 
  45. > getpixel(x',y'): putpixel(x,y)
  46.  
  47. >The key to why chunky is so much faster lies in the last getpixel/putpixel
  48. >pair.
  49.  
  50. Both examples use very expensive operations for each pixel. The rendering
  51. is only a small fraction and splitting a pixel value into bits is only
  52. a small part of the rendering operation.
  53.  
  54. >I've put up an algorithm that clearly shows why chunky is ridiculously
  55. >faster, using a general purpose algorithm that can scale/magnify/rotate any
  56. >image to any degree (no sanity checks :).  You're welcome to continue to
  57. >argue, but I really think that for all intents and purposes I've proven my
  58. >point.
  59.  
  60. Can't see that. You get to the point where you use single writepixel
  61. and readpixel operations where you don't need that just because this
  62. is the optimal case of chunky and the worst case of bitplanes. And you
  63. simply 'forget' that your calculations take more time than the pixel
  64. operations.
  65.  
  66. >OK, ok, take your depth scaling.  Your welcome.  As I said before, if you
  67. >want to cut down to 128 colors, why not just go to 16?  Chunky would be
  68. >faster THEN.
  69.  
  70. 16 might be to small, and 16 color chunky is still quite slow as no
  71. processor used will support nibble operations. Most advantages of chunky
  72. displays come from the fact that the processor explicitely supports
  73. operations on a 'chunk' (8 bits in most cases).
  74.  
  75. >Bingo.  Chunky is still faster.
  76.  
  77. Why faster ? Same operation, same amount of data, same speed.
  78.  
  79. >Your correct, the _ratio_ is still the same, but the _amount of time_
  80. >wasted goes up incrementally, 2x, 4x, 8x etc.
  81.  
  82. Can't follow your argument here.
  83.  
  84. Regards,
  85. -- 
  86. Michael van Elst
  87. UUCP:     universe!local-cluster!milky-way!sol!earth!uunet!unido!mpirbn!p554mve
  88. Internet: p554mve@mpirbn.mpifr-bonn.mpg.de
  89.                                 "A potential Snark may lurk in every tree."
  90.