home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 3382 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.3 KB
  1. Path: grafix.xs4all.nl!john.hendrikx
  2. Date: Wed, 07 Feb 96 22:58:27 GMT+1
  3. Newsgroups: comp.sys.amiga.programmer
  4. Distribution: world
  5. Subject: Re: Amiga doesn`t need Planar!
  6. MIME-Version: 1.0
  7. Content-Type: text/plain; charset=iso-8859-1
  8. Content-Transfer-Encoding: 8bit
  9. From: john.hendrikx@grafix.xs4all.nl (John Hendrikx)
  10. Message-ID: <john.hendrikx.4cop@grafix.xs4all.nl>
  11. Organization: Grafix Attack BBS Holland
  12.  
  13. In a message of 06 Feb 96 Michael Van Elst wrote to All:
  14.  
  15.  >> Sure it has, just the fact that Planar needs to go through all kinds of
  16.  >> trouble to collect all bits in a single true-color pixel, and only then
  17.  >> being able to perform a 'shade to 90% intensity' operation on it,
  18.  
  19.  MVE> Do you believe that you actually _read_ your graphics buffer ? Ever
  20.  
  21. So how are you suggesting this should be done?  Source = Gfx mem, Destination =
  22. Gfx mem, same location.  Maybe it is referred to as a Read/Modify/Write
  23. operation, it still involves reading.
  24.  
  25.  MVE> tried this on a chunky SVGA card ?
  26.  
  27. No, atleast not by programming it at the hardware level.
  28.  
  29.  >> a whole.  Unlike scaling or rotation, which could have done without
  30.  >> actually knowing what colors the pixels actually are (ie, you could rotate
  31.  >> or scale 1 bitplane at the time, so Planar can do this too).
  32.  
  33.  MVE> ..to stay with your argumentation. No. You do want to interpolate
  34.  MVE> pixels to avoid aliasing artifacts.
  35.  
  36. Yes, that would make things look better.
  37.  
  38.  >> CPU Chunky vs CPU Planar           --> Planar looses big time CPU Chunky
  39.  >> vs Hardware Planar      --> About equally matched Hardware Chunky vs
  40.  >> Hardware Planar --> About equally matched (???)
  41.  
  42.  MVE> This all depends on the kind of operations you do and wether you
  43.  MVE> restrict your comparisons to cases that are handled well by chunky
  44.  MVE> displays.
  45.  
  46. Of course.  The question is what kind of display would be best suited for a
  47. modern computer system, let's say the next PPC604 equipped Amiga?  I'm talking
  48. both games and apps here, as I think Amiga needs both to survive.
  49.  
  50.  >> You forget however to mention that the 68040/25 isn't all that recent
  51.  >> technology either.  A PPC604/133 would need extremely fast memory to get 0
  52.  >> ws on a cache miss, something like 5 ns memory.
  53.  
  54.  MVE> Check your databooks :) No, the PPC604/133 does not have a 133MHz bus
  55.  MVE> clock.
  56.  
  57. Hehehe, wishfull thinking I guess -- I should have known better.  It however
  58. points out a memory access is quite slow, so lots of extra operations can be
  59. performed for each pixel without losing speed.  You're right though that the
  60. CPU <-> gfx-card bus isn't necessarily what determines the speed of the
  61. gfx-card.  But that's where the hardware on the card itself comes in.
  62.  
  63.  >> doesn't cut it is the amount of effects possible with the CPU... you
  64.  >> can't put them ALL in hardware...
  65.  
  66.  MVE> I don't have to put them ALL in hardware.
  67.  
  68. Yep, probably right here.  The people using the hardware will just 'sigh' and
  69. use the hardware as it is so much faster, although not entirely what they
  70. intended (ie, Phong shade polygons was what is intended, but hardware can only
  71. do Gouraud shaded ones).
  72.  
  73. Grtz John
  74.  
  75. -----------------------------------------------------------------------
  76.  John.Hendrikx@grafix.xs4all.nl   TextDemo/FastView/Etc... development
  77. -----------------------------------------------------------------------
  78. -- Via Xenolink 1.981, XenolinkUUCP 1.1
  79.