home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 4843 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  6.5 KB
  1. Path: nntp.teleport.com!sschaem
  2. From: sschaem@teleport.com (Stephan Schaem)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: Amiga doesn`t need Pl
  5. Date: 5 Mar 1996 19:54:56 GMT
  6. Organization: Teleport - Portland's Public Access (503) 220-1016
  7. Distribution: world
  8. Message-ID: <4hi66g$nf8@nadine.teleport.com>
  9. References: <john.hendrikx.4ixx@grafix.xs4all.nl>
  10. NNTP-Posting-Host: kelly.teleport.com
  11. X-Newsreader: TIN [version 1.2 PL2]
  12.  
  13. John Hendrikx (john.hendrikx@grafix.xs4all.nl) wrote:
  14. : In a message of 01 Mar 96 Stephan Schaem wrote to All:
  15.  
  16. :  >> I don't think so, maybe the 50 MHz version, but they still won't get 25
  17. :  >> FPS orso at 320x256 1x1 (talking DOOM here, not some WolfenStein clone
  18. :  >> with floors which I see all too often).
  19.  
  20. :  SS> rendering a static scene should acheive 25fps in 320x200 (60hz) with
  21. :  SS> a 25mhz 030 (50% walls 50% floor/ceiling). I'm just talking about
  22. :  SS> rendering 
  23. :  SS> it to fastmem, no c2p into chipmem... I just wanted to point out that 
  24. :  SS> the CPU is not the problem in the amiga to play something like doom. 
  25. :  SS> (Well 14mhz 020 are)
  26.  
  27. : So you tested this?  Remember TextDemo?  It gets max 6 FPS on my 68030/22, of
  28. : which about 30% is C2P (info:  320x240 1x1, 'DOOM' shading using a look-up
  29. : table).  That gets you let's say about 9 FPS (being VERY generous) if C2P was
  30. : disabled.  Not even near 25 FPS, and I'm pretty damn sure it cannot be sped up
  31. : more than 25% orso.
  32.  
  33.  18fps with a lighting table should be possible. I was just talking about
  34.  rendering 4 quad. 21cycle per pixel for floor, 19 for walls with 
  35.  lighting table.
  36.  
  37. :  >> Do you really think so?  On 030 the fastest instructions available take 2
  38. :  >> cycles, while most instructions on 486 take 1 cycle.  486 also has much
  39. :  >> faster Mul and Div instructions. You would be better of comparing the 040
  40. :  >> with the 486.
  41.  
  42. :  SS>  well,  the 68030 as 16 'general' purpose register (Let not argue on
  43. :  SS> the details:) as a separate data/inst cache . Does the 486 halt during
  44. :  SS> buss access? Do you know how many cycles are needed to tmap a gouraud
  45. :  SS> lighted pixel on a 486? on a 030 is 28cycle or so.
  46.  
  47. : 28 cycles, with a huge look-up table, and all kinds of stupid limitations which
  48. : are completely impractical for a REAL game.
  49.  
  50.  No limitation at all. and it uses a 64k lighting table.. . I have NO idea
  51.  how someone can do lighting in 8bit index mode without a table!
  52.  Each point in your polygon as a pair of UV unsigned 8bit coordinate
  53.  in a 256byte width texture. (UV is an offset to the texture pointer)
  54.  And I said , if you need texture bigger then 256x256 , SPLIT your polygon.
  55.  The destination buffer can be any size... and support for 24bit RGB tripplet
  56.  is a breeze to ad.
  57.  
  58. :  SS> Also this take 6 cycle on a 030:  addi.l #32bitvalue,(localvariable,a7)
  59. :  SS> how many on a 486 and 386? (Sorry I dont have any x86  stuff:( )
  60.  
  61. : What's the point?  Isn't it clear that the 486 is much faster than the 030? The
  62. : difference in cache-size alone gives the 486 a huge speed-up.
  63.  
  64.  Much faster at double the clock speed and big L2 cache maybe.
  65.  The point is the x86 suffer alot from its origin.
  66.  
  67. :  >>  SS> Again the problem is not c2p but slow video memory...Does PC alway
  68. :  >>  SS> cache video memory on the L1 cache? I hear many people rendering in
  69. :  >>  SS> local mem then doing a copy.
  70.  
  71. :  >> Of course the video memory is not cached in the L1 cache, for the same
  72. :  >> reason as ChipRAM isn't cached on Amiga.  To copy the stuff to video ram
  73. :  >> why not simply ask the DMA controller to copy that shit for you while you
  74. :  >> render the next frame?  Also why wouldn't the same trick to get 'free'
  75. :  >> cycles on Amiga while doing ChipRAM writes work with the clones much
  76. :  >> faster Video RAM? While writing the pixel to video ram the processor
  77. :  >> continues to calculate the next TMapped pixel.
  78.  
  79. :  SS>  I'm very unfamiliar with PC... but I heard that the PC dma is dead
  80. :  SS> slow like 4meg second to dma system memory... does all PC video card
  81. :  SS> have DMA?
  82.  
  83. : Most clones have got a DMA controller on the motherboard which you can simply
  84. : ask to move memory to a specific location (ie, its very general purpose).  The
  85. : speed depends heavily on what kind of clone you have, but 4 MB/second is
  86. : probably the lower-limit at the moment.
  87.  
  88.  Well, there was a discusion on this in comp.sys.algorithm (not really the
  89.  place, but) the end word was to forget about it. its too slow and while
  90.  the dma copy from mem to port port to mem the bus is locked, so byebye
  91.  100mhz 486 while the motherboard copy the data a 4meg second.
  92.  The problem is, result maybe vary ... but the above is a possible case
  93.  
  94.  
  95. :  >> I doubt this 10 cycle routine of yours is very usefull for realistic
  96. :  >> purposes judging from all the 'unrealistic' TMap routines I've seen here
  97. :  >> lately (ones with rely on 64K boundaries or too big or too small
  98. :  >> Textures).
  99.  
  100. :  SS> It texture anything using 64K tmap with 24bit/16bit/8bit fixpoint
  101. :  SS> and gouraud lighting. I do not see why using segment is 'unrealistic'
  102. :  SS> ?!
  103.  
  104. : So how big are the look-up tables?  What is the minimum size of a texture?
  105.  
  106.  256x256 texture, 64k lighting table.
  107.  
  108. :  >> It DIDN'T work in local fastmem (did I say that?).  This included C2P
  109. :  >> time.  It was run in 320x240 1x1, 8-bit, full floors, ceilings and walls
  110. :  >> in DOOM style.
  111.  
  112. :  SS> I bet that if you had a 300mhz 060 the c2p wont be any faster then the
  113. :  SS> 25mhz 040... The 060 is not to blame.
  114.  
  115. : And that's exactly my point, you can't get a fast 'exact' DOOM clone for Amiga
  116. : as the ChipRAM will always bog it down far too much.  Requiring a fast 040 or
  117. : 060 to get a 'playable but still not as fast as my friends 486/33' 'exact' DOOM
  118. : clone is quite unrealistic.
  119.  
  120.  My only point was that the CPU is not at fault. I really have the impression
  121.  from you that if my A3000 had a 25mhz 486 doom would be smooth as a baby 
  122.  but.
  123.  
  124. :  SS> This is what I beleive the amiga as enought power even with a 25mhz
  125. :  SS> 030 to  do doom(but flat shaded tmaping) at ~15-20fps if it had a
  126. :  SS> local bus video card.
  127.  
  128. : Backing down from your 25 FPS claim above?  If you back down a little bit
  129. : further to say 10 FPS then I might actually agree with you.
  130.  
  131.  flat shaded top speed is ~18fps... the 25fps figure was for plain tmamping.
  132.  you can do doom with that but require 8x the tmap space. BUT thats not
  133.  too crazy because Z lighting with mipmapping is not to absurde. And tmap
  134.  can be expanded on the fly.
  135.  
  136.  I still think my A3000 25mhz 030 with a local bus video card can do 25fps
  137.  doom rendering at 320x200. Stop blamming the 680x0 :)
  138.  
  139.  Stephan
  140.