home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 2863 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  7.9 KB
  1. Path: grafix.xs4all.nl!john.hendrikx
  2. Date: Mon, 05 Feb 96 21:30:36 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.4bul@grafix.xs4all.nl>
  11. Organization: Grafix Attack BBS Holland
  12.  
  13. In a message of 03 Feb 96 Michael Van Elst wrote to All:
  14.  
  15.  >> MVE> Then I'm much faster than chunky because I still hit memory by
  16.  >> words.
  17.  
  18.  >> So can Chunky, using the same 'write-mask' hardware as Planar does.
  19.  
  20.  MVE> You mean that you now start to add extra hardware ? You start losing
  21.  MVE> the cost advantages of using the CPU for rendering.
  22.  
  23. Not really.  I hardly call a write-mask 'hardware' anyway, its nothing compared
  24. to what a planar card needs to get slightly good results.
  25.  
  26.  >> Planar
  27.  >> needs to read the extra mask though, Chunky can simply interpret color 0
  28.  >> as a pixel not to be drawn.
  29.  
  30.  MVE> Chunky could do the same. Also, chosing a color is more limited
  31.  MVE> compared to an arbitrary mask. If you want an arbitrary mask you have
  32.  MVE> to read it. If you want a single color mask then this is one value to
  33.  MVE> be remembered.
  34.  
  35. So I suppose this is an disadvantage now?  You could just as easily use a
  36. bitmask, it is simply almost never necessary.
  37.  
  38.  >> Not quite, only if the pixel needs to be drawn (assuming a fast
  39.  >> CPU/Blitter where a test+branch would be fast compared to memory-speed).
  40.  
  41.  MVE> Which of course it isn't.
  42.  
  43. Of course?  What kind of platform do you have in mind anyway?  I'm talking
  44. Pentium's, P6, 68060's, PPC's, etcetera...  memory is slow for these fast
  45. processors.  Even with caches they are slow as they can't hold the entire
  46. screen in the cache (IF gfx-mem is cached at all).
  47.  
  48.  >> with Chunky is much slower than planar, but atleast you don't lose tons
  49.  >> of colors like Planar (the price you pay for the speed).
  50.  
  51.  MVE> Lose ? You mean you lose tons of colors with a 24bit display since you
  52.  MVE> don't have an 48bit one ?
  53.  
  54. If you want multiple layers with planar you LOSE colors. Ie, 8 bitplanes = 256
  55. colors.  2x 4 bitplanes = 32 colors.
  56.  
  57. Not with Chunky, you can just compare each pixel plotted with a mask, slower of
  58. course (but I'm talking modern CPU's and Gfx cards here anyway), but you can
  59. use 256 colors.
  60.  
  61.  >> Then define what you mean with Multiple layers.  For me it is having a
  62.  >> cockpit + the 3d view on one screen, but in different bitplanes (ie, using
  63.  >> dual playfield mode).  With planar this implies that the cockpit and the
  64.  >> 3d view are located in seperate planes.  So a 8 bitplane display would
  65.  >> have 2 views with only 16 colors.  Chunky, with a bit more CPU effort,
  66.  >> would retain 256 colors for both cockpit and 3d world.
  67.  
  68.  MVE> You actually mention it: "with a bit more CPU effort". You actually
  69.  MVE> have to redraw the scene completely while you do not have to do
  70.  MVE> anything for the planar display. Of course your CPU does that in zero
  71.  MVE> time and doesn't need any extra memory accesses.
  72.  
  73. Well listen to this, cockpit + 3d landscape, 8 bitplanes. Planar does it 'the
  74. easy way'.  Ie, it uses 3 bitplanes for the cockpit (for a brilliant 8 colors),
  75. and 5 bitplanes for the 3d landscape (with a overwhelming 32 colors!!).
  76. Redrawing the 3d landscape in planar is equivalent to filling the entire screen
  77. with the 3d landscape, except that parts of it are covered by the cockpit (but
  78. they are still drawn).
  79.  
  80. On the other hand, Chunky checks each pixel with the mask, before even STARTING
  81. any calculations to create the 3d landscape.  As modern 3d landscapes are
  82. usually fractals or tmapped the whole system works on a pixel-basis anyway, so
  83. this extra mask check is low-overhead.  Chunky doesn't draw unneeded pixels
  84. however, unlike planar.  The cockpit is never damaged.  It costs CPU power, but
  85. compared to the rest which is going on (ie, a 3d fractal landscape) it is
  86. nothing substantial.
  87.  
  88. You still seem to think in terms of 68000 at 7 MHz doing Interceptor style
  89. games with plain 1 color polygons.
  90.  
  91.  >> Yes, you're right.  It just takes so damn long before this kind of new
  92.  >> hardware can be integrated into an existing platform.  It gives a platform
  93.  >> which requires hardware for these kinds of effects a serious setback as
  94.  >> platform with Chunky gfx and a fast CPU have been using them for years
  95.  >> already.
  96.  
  97.  MVE> Unfortunately there are limits to what a generic CPU can do and what
  98.  MVE> it costs. That's why special texture mapping hardware becomes popular.
  99.  
  100. For consoles yes, they don't have a 'big CPU' to handle this kind of stuff.  It
  101. will come for the clones too, as soon as they find out that at 640x480 or
  102. 800x600 their Pentium/133 can't cut it anymore.  But as for computer platforms
  103. a powerfull CPU is almost a requirement anyway (you can't add hardware for ALL
  104. CPU intensive jobs) you might as well take advantage of it. Actually the future
  105. might turn out a bit differently.  P6's seem to be extremely good at
  106. multiprocessing.  If it ever becomes cheap, then 'special hardware' may never
  107. become popular again.  Just pop in more of those cheap CPU's, giving your
  108. system a speed up at EVERYTHING, not just TMapped polygons, or decoding MPEG
  109. streams, or whatever...
  110.  
  111. In general I'm strongly against specific hardware for one specific goal, I
  112. think having the ability to have multiple general purpose CPU's in one system
  113. is a much better way to solve these kind of speed-problems.  What use is that
  114. expensive DSP when it is just sitting there having nothing to do, or when apps
  115. simply not use it but use their own CPU based routines?  What use is MPEG/JPEG
  116. hardware 99% of the time?  Sure, I can't say the same thing for the blitter,
  117. but I can say it for polygon and tmapping hardware.  This stuff is usually just
  118. sitting on your card doing nothing.
  119.  
  120. Adding an extra CPU is more expensive, but it can do so much more.  Certainly
  121. it will not be as fast as a real MPEG or JPEG decoder, but then again, what use
  122. is a JPEG decoder if you want to do texturemapping, or doing complex sound
  123. effects?
  124.  
  125.  >> Sure, they have to, otherwise it wouldn't ever get popular.
  126.  
  127.  MVE> And now that they are popular you lose again against special purpose
  128.  MVE> hardware.
  129.  
  130. Oh sure, but any platform having to rely on the 'coming' of such special
  131. purpose hardware is dead by then.  Consoles are good examples of this, they
  132. never survive longer than a few years.  Amiga just barely made it, and it still
  133. isn't entirely sure it will survive long enough for us to see a machine which
  134. is fast enough to do its own special fx.
  135.  
  136.  >> one to memory:  plotting pixels.  Some optimisations to plot multiple
  137.  >> pixels at the time are possible, but it still comes down to modifying very
  138.  >> few pixels at one time.
  139.  
  140.  MVE> That's like saying that a rectangular blit plots pixels because it
  141.  MVE> writes pixels at a time.
  142.  
  143. Do I really need to explain this in detail for you?  Do you really don't see
  144. WHY a tmapped or shaded polygon is drawn one pixel at the time (as in multiple
  145. calculations are performed per pixel to give each pixel the correct look)?
  146.  
  147.  >> The difference is that Chunky hardware can be "upgraded" by getting a
  148.  >> faster CPU.
  149.  
  150.  MVE> It suddenly gains bandwidth ? Come on.
  151.  
  152. There is no need for a bandwidth increase.  With a faster CPU you can just
  153. display more CPU intensive effects, the bandwidth could remain the same.  In
  154. other words, with a 486/25 I could play 'DOOM' on my clone at a decent speed,
  155. now with my Pentium/90 I can play 'Magic Carpet' at a decent speed.  The
  156. gfx-card is just as fast, still I gained a lot by upgrading my CPU.
  157.  
  158.  >> Our planar hardware doesn't benefit from faster CPU's.
  159.  
  160.  MVE> A same-technology chunky hardware wouldn't either.
  161.  
  162. See above.
  163.  
  164. Grtz John
  165.  
  166. -----------------------------------------------------------------------
  167.  John.Hendrikx@grafix.xs4all.nl   TextDemo/FastView/Etc... development
  168. -----------------------------------------------------------------------
  169. -- Via Xenolink 1.981, XenolinkUUCP 1.1
  170.