home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 6849 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  4.6 KB
  1. Path: nntp.teleport.com!sschaem
  2. From: sschaem@teleport.com (Stephan Schaem)
  3. Newsgroups: comp.sys.amiga.programmer,comp.sys.amiga.games,alt.sys.amiga.demos,comp.sys.amiga.misc
  4. Subject: Re: AB3D II beats Quake....
  5. Followup-To: comp.sys.amiga.programmer,comp.sys.amiga.games,alt.sys.amiga.demos,comp.sys.amiga.misc
  6. Date: 3 Apr 1996 21:13:34 GMT
  7. Organization: Teleport - Portland's Public Access (503) 220-1016
  8. Message-ID: <4juplu$n44@nadine.teleport.com>
  9. References: <DosA8o.17B@info.uucp> <6538.6658T1031T2526@mbox.vol.it> <4jgn4o$l2b@hell.team17.com> <4jk515$q3l@nadine.teleport.com> <4jkdpu$1o6@hell.team17.com> <4joj14$ghj@nadine.teleport.com> <4js275$98s@hell.team17.com> <4jt8bh$a70@nadine.teleport.com> <4ju1qf$k4@hell.team17.com>
  10. NNTP-Posting-Host: kelly.teleport.com
  11. X-Newsreader: TIN [version 1.2 PL2]
  12.  
  13. Stefan Boberg (boberg@team17.com) wrote:
  14. : sschaem@teleport.com (Stephan Schaem) wrote:
  15. : >Stefan Boberg (boberg@team17.com) wrote:
  16.  
  17. : >: > I think they should do more then just the scan conversion...
  18.  
  19. : >:   Such as?
  20.  
  21. : > Clipping, geometry transform, bsp tree traversal, visibility test
  22.  
  23. :   BSP tree traversal? I have to disagree. That's the type of thing
  24. : compilers are good at optimizing.
  25.  
  26. :   Clipping/geometry transform: Possibly, although as far as I can see
  27. : from my experiments, the gain is quite small.
  28.  
  29.  If quake support a lores mode, it become more and more imporant.
  30.  the rasterization time can drop 400%, this mean other loop now weigh
  31.  that much more.
  32.  This can be true if you include basic 3d object in your scene... like
  33.  quake does with shield and else. little rendering for the transformation
  34.  involved, so optimizing the tranformation might be a good idea.
  35.  Look at a game like "into the shadows" , now with the number of vertices
  36.  its defenetly worth getting a few cycles out of the matrix operations.
  37.  
  38. : >:   I'm not sure about that. In DOOM, very little was in ASM.
  39.  
  40. : > This just mean Doom pass most of its time in very little code.
  41.  
  42. :   So does any game.
  43.  
  44.  I mean VERY little code, like basicly 80% of the time in a few hundreds
  45.  line routine :)
  46.   
  47. : >:   Yes you can do that. You simply use in-line assembly macros for
  48. : >: fixed-point multiplies / divides etc. I have such a system and it
  49. : >: works fine. Just change a switch (such as '-DFIXED_MATH') on the
  50. : >: command line and all code will use fixed-point.
  51.  
  52. : > Do you get good performance from this? 
  53.  
  54. :   Yes. Watcom is very good at allocating registers for inline ASM.
  55. : BTW, Id used the same approach in Doom.
  56.  
  57.  You also need to change your structures? or do you do unions and
  58.  keep 64bit or more alocated per variable? How about file format? 
  59.  
  60. : > Also I often find myself
  61. : > otimizjng the fix point setting. not alway 16:16 or 8:8, but maybe
  62. : > 8:24, 4:28 ... 
  63.  
  64. :   You can do this with macros too, if you really need to. It gets less
  65. : manageable though.
  66.  
  67.  To tell you the truth I dont like macro or conditionaly compliled/assembled
  68.  code for major purposes.
  69.  
  70. : >:   It's not bad practice. It's clever - on the Pentium, at least. Can
  71. : >: you figure out why it's done?
  72.  
  73. : > Nope... because the scanline loop use no MUL. and FPU add are slower
  74. : > and also you cant use FPU register directly as index or else
  75. : > so FPU make sense in the setup when fmul are faster then imul and you 
  76. : > dont need to convert from ftoi all the time, otherwise not.
  77.  
  78. :   You've missed it completely. You can use floats in scan conversion,
  79. : and it's faster than fixed-point on the Pentium (about twice as fast,
  80. : as a matter of fact). I'm sure if you just think about it, you'll see
  81. : why. But you're right, it's NOT in the core pixel-drawing loop.
  82.  
  83.  I use float in the rasterizing stage on pentium... like I said
  84.  fmul are faster then imul.
  85.  
  86. : >:   Taking polygon structures (vertices and edges) and turning them into
  87. : >: pixels.
  88.  
  89. : > does the edge include slope information? if so no reason to see a float
  90. : > operation in the 'scan-conversion' loop.
  91.  
  92. :   No. In my case, an edge is a reference to two vertices. It could
  93. : include slope information though, as a further optimization.
  94.  
  95.  Then it make sense to get slope information via float on pentium...
  96.  But do you think that this is why its so slow on 486? 
  97.  How much speedup do you get by using your fixedpoint macro VS float
  98.  on a 486 in that rendering function?
  99.  
  100. :   I should add that I focus most of my attention on
  101. : perspective-correct texture mapping. But the same optimization
  102. : strategies (involving floats) can be applied to affine tmapping.
  103.  
  104.  I use affine tmapping in my perspective correct texture mapping...
  105.  I tryed 7 variant, from 3 class out of 6 of perspective correct
  106.  rendering methode.... I choose one based on affine tmapping.
  107.  
  108.  Stephan
  109.