home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 1412 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  4.3 KB

  1. Path: informatik.tu-muenchen.de!fischerj
  2. From: fischerj@informatik.tu-muenchen.de (Juergen "Rally" Fischer)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: TMapping again!
  5. Date: 18 Jan 1996 19:05:49 GMT
  6. Organization: Technische Universitaet Muenchen, Germany
  7. Distribution: world
  8. Message-ID: <4dm5md$qfc@sunsystem5.informatik.tu-muenchen.de>
  9. References: <4d0ou6$835@astfgl.idb.hist.no> <Z31Wx*zA0@mkmk.in-chemnitz.de> <4d42di$9e9@maureen.teleport.com> <4d5lvi$emc@brachio.zrz.TU-Berlin.DE> <4d6v0t$3dt@maureen.teleport.com> <4djj0t$4ni@sunsystem5.informatik.tu-muenchen.de> <4dlo7d$h39@news.cs.tu-berlin.de>
  10. NNTP-Posting-Host: hphalle5.informatik.tu-muenchen.de
  11. Originator: fischerj@hphalle5.informatik.tu-muenchen.de
  12.  
  13.  
  14. In article <4dlo7d$h39@news.cs.tu-berlin.de>, rawneiha@hydra.zrz.TU-Berlin.DE (Philipp Boerker) writes:
  15. |> Organization: Technical University of Berlin, Germany
  16. |> Lines: 71
  17. |> Message-ID: <4dlo7d$h39@news.cs.tu-berlin.de>
  18. |> References: <4d0ou6$835@astfgl.idb.hist.no> <Z31Wx*zA0@mkmk.in-chemnitz.de> <4d42di$9e9@maureen.teleport.com> <4d5lvi$emc@brachio.zrz.TU-Berlin.DE> <4d6v0t$3dt@maureen.teleport.com> <4djj0t$4ni@sunsystem5.informatik.tu-muenchen.de>
  19. |> NNTP-Posting-Host: hydra.zrz.tu-berlin.de
  20. |> Mime-Version: 1.0
  21. |> Content-Type: text/plain; charset=iso-8859-1
  22. |> Content-Transfer-Encoding: 8bit
  23. |> 
  24. |> fischerj@informatik.tu-muenchen.de (Juergen "Rally" Fischer) writes:
  25. |> 
  26. |> 
  27. |> >|>  AAAAAA..........BBBBBCCCCCCDDDDD
  28. |> >|> 
  29. |> >|>  A = x fraction
  30. |> >|>  B = y integer
  31. |> >|>  C = y fraction
  32. |> >|>  D = x integer
  33. |> >|>  . = zero or more precision for x
  34. |> >|> 
  35. |> >|>  as you see the example above work...
  36. |> 
  37. |> >uhm has anyone actually seen the mapper work ? IMHO the fact that
  38. |> >CCCCCC y fraction also causes an adress, this could be used imho
  39. |> >for smoother mapping!
  40. |> 
  41. |> >I guess you normally use 32 equal pixels
  42. |> 
  43. |> I think that you rather have the same 32x32 64 times in your
  44. |> 256x256 texture. This will cause the y fraction to be ignored.
  45. |> 
  46. |> > but if you'd use 32 values
  47. |> >beeing interpolated between 2 pix of the "real 32x32 map", then it
  48. |> >should give you interpolation for free!
  49. |> 
  50. |> hm.
  51. :)
  52.  
  53. |> 
  54. |> >|> : Yes, I agree. Sharon, one of the coders of matrix, is actually a
  55. |> >|> : PC coder but his polygon engine on a 33 MHz 486 is slower than
  56. |> >|> : our (Sharon, Grond, Skyphos all/matrix) engine on a 25 MHz 030!
  57. |> >|> : That's the power of a large register set!
  58. |> 
  59. |> >well is you polyengine still faster using 8 planes ? ;)
  60. |> 
  61. |> I was refering to 8bit.
  62. |> 
  63. |> >he got a non-local-bus vga ? ;)
  64. |> 
  65. |> Local bus...
  66.  
  67. ooh =:o
  68.  
  69. well hm... polygon is just writing 32bit values to vram.
  70.  
  71. The 030 will do this at on AGA 7MB/sec. Or do you refer to 
  72. A3000+gfx-card ? ;)
  73.  
  74. average VLBs installed in a 486-33 should have about(?) 15mb/sec speed. 
  75. mhm. is the PC version writing bytewise ?
  76.  
  77. how much fps ? is it mem overwritten multiple times (fastmem render ?).
  78. then fastmem speeds cares.
  79.  
  80. are you sure the PC version is as optmized?
  81.  
  82. |> 
  83. |> >It depends on the routine if a large register set is needed.
  84. |> >inner loops can live with x86 chipset, but when it comes to
  85. |> >2st outer, the L1 caches have to play the role of a larger
  86. |> >register set.
  87. |> 
  88. |> But if you have real large register sets and superscalar processor
  89. |> design you maybe can do 2 rasterlines at once or more likely to frames
  90. |> for i-glasses...
  91. ??
  92.  
  93. |> 
  94. |> 
  95. |> >my friend always argues that you could see the cache as big register
  96. |> >set on intel
  97. |> 
  98. |> Then ask him how he does a 
  99. |> "shift left with mask out and insert" rdest,rsource1,rsource2
  100. |> within 1 cycle from datacache...
  101.  
  102. can 680x0 do that ? x86 operations with datacache as destination need
  103. 33 cycles AFAIK. add.l D0,var or in x86 add eax,var
  104.  
  105. |> 
  106. |> >, but I disagree, a mapper loads so much from mem that
  107. |> >your variables in cache are bombed by the texture data 
  108. |> 
  109. |> Hm, I don't think that you will set so many pixels, that you can
  110. |> fill 8k cache before you execute outerloop a second time...
  111.  
  112. doesn't care how much pix are read in innerloop, scanning a 64k pic
  113. will destroy cached instructions. don't know how fatal it is.
  114.  
  115. |> 
  116. |> Greets,
  117. |> Phil.
  118. |> ----------------------------
  119. |> grond/matrix
  120. |> rawneiha@sp.zrz.tu-berlin.de
  121. |> ----------------------------
  122. |> 
  123. ------------------------------------------------------------------------
  124.    fischerj@Informatik.TU-Muenchen.DE (Juergen "Rally" Fischer)   =:)
  125.  
  126.