home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 2551 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  7.1 KB
  1. Path: grafix.xs4all.nl!john.hendrikx
  2. Date: Wed, 31 Jan 96 20:34:14 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.4apt@grafix.xs4all.nl>
  11. Organization: Grafix Attack BBS Holland
  12.  
  13. In a message of 30 Jan 96 Michael Van Elst wrote to All:
  14.  
  15.  >> That's still a lot more work for a 7 bitplane screen, the only thing you
  16.  >> don't need to do is the reads, still 7 writes though.
  17.  
  18.  MVE> Yes. But read further :)
  19.  
  20.  >> Wrong, I was talking about a cookie-cutted object, and for all you know
  21.  >> it could have contained holes, or whatever.  A full mask is required here.
  22.  
  23.  MVE> Again, you just need to read from the borders. You don't need to read
  24.  MVE> where the mask would be a constant 1 and you don't need to read at all
  25.  MVE> if your planar hardware supports a write mask in the way the average
  26.  MVE> chunky system supports a (byte-)write mask.
  27.  
  28. What if my object-mask looks like %01010101010101?  You can't tell if the mask
  29. will be a constant 1, unless you hard-code this information with each object. 
  30. For a paint-program which can pick up a brush and paste it somewhere else it
  31. has no way of knowing this, atleast not at an acceptable overhead.
  32.  
  33.  >> If you take into account the extra effort required to make good use of a
  34.  >> deep planar display then dedicated hardware is likely to reflect upon
  35.  >> this.  In other words it will be more complex, need more memory accesses
  36.  >> and in general it will be slower than chunky hardware at higher costs.
  37.  
  38.  MVE> It will be more expensive. Sure. Because you already have a CPU that
  39.  MVE> can handle chunky. You need an extra one that handles planar. But if
  40.  MVE> you already want to offload graphics to some render engine the cost (in
  41.  MVE> terms of complexity) is about the same.
  42.  
  43. What about the amount of memory accesses?  You would need faster RAM, and RAM
  44. is usually the limiting factor when it comes to speed, and also often the
  45. biggest factor when it comes to the cost of the final product.
  46.  
  47.  >> The fact that the CPU is well equipped to handle Chunky display hardware
  48.  >> is a huge advantage, as then the CPU can be used to implement tricks not
  49.  >> directly supported in the hardware.
  50.  
  51.  MVE> Such as a multi-layer display ?
  52.  
  53. Yes, this is pretty simple to implement as well at one extra memory access per
  54. pixel.  Planar could do it faster, but at a much higher price (it means losing
  55. lots of colors).  What I meant was the more popular effects like
  56. TextureMapping, drawing shaded polygons and so on.  These are not commonly
  57. found on gfx-cards, and when they are games will likely have moved on to more
  58. spectacular effects.  In the end it will always be the CPU which delivers you
  59. the newest effects.
  60.  
  61.  >> With planar you have to rely on the hardware, if it gets outdated or you
  62.  >> want to do Gouraud shaded texturemapping instead of old-style plain
  63.  >> texturemapping which was supported in the hardware then you're at a loss,
  64.  >> and you'd have to resort to C2P and all that crap.
  65.  
  66.  MVE> This is just because you have some precedence for texturemapping.
  67.  
  68. Not just me, texturemapping is simply popular because it makes things look more
  69. realistic and is within the range of our current processors.  Planar offers
  70. some effects, but they are all childish in comparison and none of them enhance
  71. the speed of doing a realistic 3d environment.
  72.  
  73.  >> Yes, and I would have agreed with them a few years ago when 8-bit was
  74.  >> still 'too slow' to be usefull.  Now however even 24-bit screens zip along
  75.  >> nicely.
  76.  
  77.  MVE> You mean they "zip along nicely" because they are chunky ? Or because
  78.  
  79. No, they zip along nicely because they have got enough speed, and I do think
  80. that Chunky may have a great deal to do with that.  What I meant was that there
  81. is no need to use low-bitplane Planar displays because even deep Chunky
  82. displays are incredibly fast.  That kills one of the advantages of planar.
  83.  
  84.  MVE> you compare a 10 year old planar system with state-of-the-art hardware?
  85.  
  86. I still believe that Planar hardware is a bad choice over Chunky hardware
  87. because I think that Planar just isn't suited for todays needs.  The memory
  88. arrangement of a planar display doesn't give you much usefull advantages at
  89. all, and it also causes a lot of the often used operations like plotting a
  90. pixel (games) drawing a line (GUI's) or blitting a masked-object (Games, paint
  91. programs, gadget imagery, overlayed text, etcetera) to perform much slower.
  92.  
  93.  >> MVE> That's why it is popular.
  94.  
  95.  >> That's also why it is fast
  96.  
  97.  MVE> No.
  98.  
  99. Yes it is, Chunky hardware performs the most popular operations much faster
  100. than Planar hardware could.  With the most popular operations I mean things
  101. which are used for drawing a GUI and things now often seen in games.
  102.  
  103.  >> and easy to create new (not supported by the hardware directly) effects
  104.  >> with it.
  105.  
  106.  MVE> Depends on the effects. You seem to focus just on effects that a
  107.  MVE> standard CPU can do.
  108.  
  109. No, I focus on the usefull effects.  Doing effects which involve manipulating
  110. bitplanes seperately are just not as usefull, atleast not in today's world. 
  111. We've outgrown Planar.
  112.  
  113.  >> See above, I was talking about (real-life) cookie cutted objects,
  114.  
  115.  MVE> ... which require as much reading as with a chunky blitter. No ? :)
  116.  MVE> After all the memory bus is probably not pixel-sized, even for chunky.
  117.  
  118. Planar has much more severe alignment (and thus more overhead) problems and
  119. needs to access memory (for a 16-bit object) at 16 different locations in
  120. memory, while with Chunky this is all located in close vicinity of each other,
  121. making optimisations like plotting LONGs instead of WORDs possible.  Take an 8
  122. pixel wide and 8 bit deep object, one row could be plotted with Chunky in just
  123. 2 LONG writes. With planar you could do it with 8 BYTE writes.  The number of
  124. accesses is very important for overal speed.
  125.  
  126. The amount of bytes read is about the same (that is if you're object is a
  127. multiple of 8, 16 or 32 pixels wide depending on the memory-bus width), the
  128. amount of accesses is however much higher with Planar.
  129.  
  130.  >> MVE> That's the point. The CPU does not support planar displays. If all
  131.  >> you MVE> have is the CPU then you want a chunky display.
  132.  
  133.  >> But what reason would anyone have to use planar?  It requires extra
  134.  >> hardware(!!), you limit the CPU as it can do
  135.  >> -nothing- usefull at all when it comes to displaying graphics.
  136.  
  137.  MVE> Planar hardware has its own advantages. It surely requires extra
  138.  MVE> hardware. But then it is popular to use extra hardware except for the
  139.  MVE> clones that try to overcome every hardware limit just with increasing
  140.  MVE> CPU power.
  141.  
  142. Yes, and we with our brilliant planar hardware are stuck with those hardware
  143. limits as we can't upgrade our planar hardware without serious problems.  We
  144. can upgrade our CPU's however but that doesn't do us much good.
  145.  
  146. Grtz John
  147.  
  148. -----------------------------------------------------------------------
  149.  John.Hendrikx@grafix.xs4all.nl   TextDemo/FastView/Etc... development
  150. -----------------------------------------------------------------------
  151. -- Via Xenolink 1.981, XenolinkUUCP 1.1
  152.