home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 2655 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  5.9 KB
  1. Path: grafix.xs4all.nl!john.hendrikx
  2. Date: Fri, 02 Feb 96 21:56:06 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.4b80@grafix.xs4all.nl>
  11. Organization: Grafix Attack BBS Holland
  12.  
  13. In a message of 02 Feb 96 Michael Van Elst wrote to All:
  14.  
  15.  >> What if my object-mask looks like %01010101010101?
  16.  
  17.  MVE> Then I'm much faster than chunky because I still hit memory by words.
  18.  
  19. So can Chunky, using the same 'write-mask' hardware as Planar does.  Planar
  20. needs to read the extra mask though, Chunky can simply interpret color 0 as a
  21. pixel not to be drawn.
  22.  
  23.  >> What about the amount of memory accesses?
  24.  
  25.  MVE> As I said: memory bandwidth is about the same for objects that are
  26.  MVE> large enough and smaller if you need less bits per pixel.
  27.  
  28. See below, planar doesn't benefit from larger mem-bandwidth as well as Chunky
  29. can.
  30.  
  31.  >> Yes, this is pretty simple to implement as well at one extra memory
  32.  >> access per pixel.
  33.  
  34.  MVE> Don't forget that this is a 100% increase.
  35.  
  36. Not quite, only if the pixel needs to be drawn (assuming a fast CPU/Blitter
  37. where a test+branch would be fast compared to memory-speed).  Also, with a bit
  38. of smart programming you could ensure that the mask is usually already in the
  39. cache, ie, by drawing horizontally.  But you're right, using multiple layers
  40. with Chunky is much slower than planar, but atleast you don't lose tons of
  41. colors like Planar (the price you pay for the speed).  It doesn't matter
  42. though, today's CPU's can do that without sweating.
  43.  
  44.  >> Planar could do it faster, but at a much higher price (it means losing
  45.  >> lots of colors).
  46.  
  47.  MVE> It means to have the same amount of colors. Why should chunky suddenly
  48.  MVE> have more bits ?
  49.  
  50. Then define what you mean with Multiple layers.  For me it is having a cockpit
  51. + the 3d view on one screen, but in different bitplanes (ie, using dual
  52. playfield mode).  With planar this implies that the cockpit and the 3d view are
  53. located in seperate planes.  So a 8 bitplane display would have 2 views with
  54. only 16 colors.  Chunky, with a bit more CPU effort, would retain 256 colors
  55. for both cockpit and 3d world.  The mask would simply be a map which marks the
  56. cock-pit graphics as 'masked', so when drawing the 3d view you check the mask
  57. before plotting each pixel.
  58.  
  59.  >> spectacular effects.  In the end it will always be the CPU which delivers
  60.  >> you the newest effects.
  61.  
  62.  MVE> And special hardware can deliver them cheaper. That's an old truth.
  63.  
  64. Yes, you're right.  It just takes so damn long before this kind of new hardware
  65. can be integrated into an existing platform.  It gives a platform which
  66. requires hardware for these kinds of effects a serious setback as platform with
  67. Chunky gfx and a fast CPU have been using them for years already.
  68.  
  69.  >> Not just me, texturemapping is simply popular because it makes things
  70.  >> look more realistic and is within the range of our current processors.
  71.  
  72.  MVE> You mean it is popular because PCs just have processors that are now
  73.  MVE> fast enough.
  74.  
  75. Sure, they have to, otherwise it wouldn't ever get popular. The test which
  76. shows that TMapping is popular though is that games which don't use it (ie,
  77. which use plain polygons) are not acceptable anymore today.
  78.  
  79.  >> all, and it also causes a lot of the often used operations like plotting
  80.  >> a pixel (games)
  81.  
  82.  MVE> Games rarely plot pixels.
  83.  
  84. On Amiga yes, on clones however TMapping, scaled objects, rotating objects and
  85. gouraud/phong shaded polygons is practically all you see these days, and this
  86. is done by calculating information on a pixel basis, and storing them one by
  87. one to memory:  plotting pixels.  Some optimisations to plot multiple pixels at
  88. the time are possible, but it still comes down to modifying very few pixels at
  89. one time.
  90.  
  91.  >> drawing a line (GUI's)
  92.  
  93.  MVE> Mostly with 1bit per pixel.
  94.  
  95. Only if the area you draw the GUI in is cleared first.  You got a point there
  96. though as this usually indeed is the case.
  97.  
  98.  >> No, I focus on the usefull effects.
  99.  
  100.  MVE> So useful effects are defined at what standard CPUs do ?
  101.  
  102. I didn't say that.  The things that planar does best are however not
  103. particularly usefull in my eyes.
  104.  
  105.  >> Planar has much more severe alignment (and thus more overhead) problems
  106.  >> and needs to access memory (for a 16-bit object) at 16 different locations
  107.  >> in memory, while with Chunky this is all located in close vicinity of each
  108.  >> other, making optimisations like plotting LONGs instead of WORDs possible.
  109.  
  110.  MVE> You mean the 128bit blitter is out ? It must have a 32bit bus ?
  111.  
  112. No actually I meant that a 128-bit bus for Chunky would be more beneficial for
  113. Chunky than for Planar.  Reason is that a 128-bit blitter needs to access 16
  114. different location in memory to access the 16 bitplanes, no matter if the
  115. object is 1 or 128 pixels in width.  The Chunky 128-bit blitter however can
  116. however draw a 1-8 pixel wide object in 1 128-bit access, a 9-16 pixel wide
  117. object in 2 128-bit accesses, and so on.  Only when the full 128-pixel width is
  118. used, only then the planar blitter will have a minimum of overhead.
  119.  
  120.  >> Yes, and we with our brilliant planar hardware are stuck with those
  121.  >> hardware limits as we can't upgrade our planar hardware without serious
  122.  >> problems.
  123.  
  124.  MVE> You mean that _chunky_ hardware wouldn't have had the same limitations
  125.  MVE> ? If the Amiga had a chunky display then C= wouldn't have made bad
  126.  MVE> decisions ?
  127.  
  128. The difference is that Chunky hardware can be "upgraded" by getting a faster
  129. CPU.  Our planar hardware doesn't benefit from faster CPU's.
  130.  
  131. Grtz John
  132.  
  133. -----------------------------------------------------------------------
  134.  John.Hendrikx@grafix.xs4all.nl   TextDemo/FastView/Etc... development
  135. -----------------------------------------------------------------------
  136. -- Via Xenolink 1.981, XenolinkUUCP 1.1
  137.