home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 2880 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  4.6 KB
  1. Path: comma.rhein.de!serpens!not-for-mail
  2. From: mlelstv@serpens.rhein.de (Michael van Elst)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: Amiga doesn`t need Planar!
  5. Date: 6 Feb 1996 14:35:01 +0100
  6. Organization: dis-
  7. Message-ID: <4f7le5$fmk@serpens.rhein.de>
  8. References: <john.hendrikx.4bul@grafix.xs4all.nl>
  9. NNTP-Posting-Host: serpens.rhein.de
  10.  
  11. john.hendrikx@grafix.xs4all.nl (John Hendrikx) writes:
  12.  
  13. >Not really.  I hardly call a write-mask 'hardware' anyway,
  14.  
  15. Ah. Every extra hardware that chunky needs is "hardly hardware" at all.
  16.  
  17. Do you see a biased view here ?
  18.  
  19. > MVE> Chunky could do the same. Also, chosing a color is more limited
  20. > MVE> compared to an arbitrary mask. If you want an arbitrary mask you have
  21. > MVE> to read it. If you want a single color mask then this is one value to
  22. > MVE> be remembered.
  23.  
  24. >So I suppose this is an disadvantage now?
  25.  
  26. NO. You get the same on either side.
  27.  
  28. >Of course?  What kind of platform do you have in mind anyway?  I'm talking
  29. >Pentium's, P6, 68060's, PPC's, etcetera...  memory is slow for these fast
  30. >processors.
  31.  
  32. You mean the x * 100MByte/s of memory bandwidth on the graphics card is slow ?
  33. It is just the CPU that is slow compared to the graphics hardware.
  34.  
  35. >If you want multiple layers with planar you LOSE colors. Ie, 8 bitplanes = 256
  36. >colors.  2x 4 bitplanes = 32 colors.
  37.  
  38. >Not with Chunky,
  39.  
  40. You are comparing apples and bananas. You say: "if you can use the harware to
  41. produce a layered display you lose colors if you use the same amount of memory"
  42. but "if you render the whole display you can simulate layering with software".
  43.  
  44. Don't you see that this has nothing to do with chunky vs. planar ?
  45.  
  46. >Well listen to this, cockpit + 3d landscape, 8 bitplanes. Planar does it 'the
  47. >easy way'.  Ie, it uses 3 bitplanes for the cockpit (for a brilliant 8 colors),
  48. >and 5 bitplanes for the 3d landscape (with a overwhelming 32 colors!!).
  49. >Redrawing the 3d landscape in planar is equivalent to filling the entire screen
  50. >with the 3d landscape, except that parts of it are covered by the cockpit (but
  51. >they are still drawn).
  52.  
  53. >On the other hand, Chunky checks each pixel with the mask,
  54.  
  55.  
  56. NO, THAT DOES YOUR SOFTWARE THAT USES A COMPLETELY DIFFERENT ALGORITHM WHICH WOULD
  57. ALSO WORK FOR A PLANAR DISPLAY.
  58.  
  59. Got that ?
  60.  
  61. >You still seem to think in terms of 68000 at 7 MHz doing Interceptor style
  62. >games with plain 1 color polygons.
  63.  
  64. From what I said everyone can see that I am NOT talking about this. I am NOT
  65. talking about 68000s nor slow CPUs not Amigas at all.
  66.  
  67. >For consoles yes, they don't have a 'big CPU' to handle this kind of stuff.
  68.  
  69. And why not ? Because it is too expensive for consoles. The special hardware
  70. that is NOW available is much cheaper and can do the same.
  71.  
  72. >is a much better way to solve these kind of speed-problems.  What use is that
  73. >expensive DSP when it is just sitting there having nothing to do,
  74.  
  75. You mean the $10 DSP that handles the audio ports ? Or the $100 DSP that decodes
  76. the network video streams ?
  77.  
  78. >or when apps
  79. >simply not use it but use their own CPU based routines?
  80.  
  81. C0d3r stuff ?
  82.  
  83. >Adding an extra CPU is more expensive, but it can do so much more.
  84.  
  85. Usually it is weaker than special hardware and hardly used too.
  86.  
  87. >Certainly
  88. >it will not be as fast as a real MPEG or JPEG decoder, but then again, what use
  89. >is a JPEG decoder if you want to do texturemapping, or doing complex sound
  90. >effects?
  91.  
  92. What if you want to do texturemapping _and_ real-time MPEG ?
  93.  
  94. >Do I really need to explain this in detail for you?  Do you really don't see
  95. >WHY a tmapped or shaded polygon is drawn one pixel at the time (as in multiple
  96. >calculations are performed per pixel to give each pixel the correct look)?
  97.  
  98. Now, for me texture mapped polygons are drawn in strips of 1-32 pixels because
  99. that's the length of the pattern buffer. It doesn't matter that pixels might be
  100. computed individually but these are hardly _drawn_ individually.
  101.  
  102. >There is no need for a bandwidth increase.  With a faster CPU you can just
  103. >display more CPU intensive effects, the bandwidth could remain the same.  In
  104. >other words, with a 486/25 I could play 'DOOM' on my clone at a decent speed,
  105. >now with my Pentium/90 I can play 'Magic Carpet' at a decent speed.  The
  106. >gfx-card is just as fast, still I gained a lot by upgrading my CPU.
  107.  
  108. And that's an effect of chunky hardware if "number of memory accesses" is all
  109. that matters as you said ?
  110.  
  111. > >> Our planar hardware doesn't benefit from faster CPU's.
  112.  
  113. > MVE> A same-technology chunky hardware wouldn't either.
  114.  
  115. >See above.
  116.  
  117. Yes, indeed. See above.
  118. -- 
  119.                                 Michael van Elst
  120.  
  121. Internet: mlelstv@serpens.rhein.de
  122.                                 "A potential Snark may lurk in every tree."
  123.