home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 2051 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  6.4 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: Demo/game to OS friendly part II
  5. Date: 26 Jan 1996 05:00:55 GMT
  6. Organization: Technische Universitaet Muenchen, Germany
  7. Distribution: world
  8. Message-ID: <4e9n67$ron@sunsystem5.informatik.tu-muenchen.de>
  9. References: <4e0jhq$f0q@sunsystem5.informatik.tu-muenchen.de> <4e114i$4o8@serpens.rhein.de> <4e371l$92b@sunsystem5.informatik.tu-muenchen.de> <4e3jld$la@serpens.rhein.de> <4e5k20$rva@sunsystem5.informatik.tu-muenchen.de> <4e64u7$a2u@serpens.rhein.de>
  10. NNTP-Posting-Host: hphalle5.informatik.tu-muenchen.de
  11. X-Newsreader: TIN [version 1.2 PL2]
  12.  
  13. Michael van Elst (mlelstv@serpens.rhein.de) wrote:
  14. : fischerj@informatik.tu-muenchen.de (Juergen "Rally" Fischer) writes:
  15.  
  16. : >|> If you want hacks then shut down the system and reboot afterwards.
  17. : >naah, shut down, zzzt zzzt, how should I perform parallel reload from
  18. : >hd then ? :)
  19.  
  20. : Simple and easy: you shouldn't, you mustn't, you can't.
  21.  
  22. wait a minute, I can't ? So how vlt manages to download on hd
  23. while I run a editor ? :)
  24.  
  25. : >|> And stand for it.
  26. : >Or embed it into OS as much as possible, tell the user, and stand for it.
  27.  
  28. : You just create lots of garbage with this. You know that, I am telling
  29. : you for years and you "stand for it". That's the basic problem here.
  30.  
  31. The problem disappears if I also provide selection of the 100% os fallback!
  32.  
  33. : >But writepixelarray8 is known to be slower on current chipset Amigas...
  34.  
  35. : Doesn't mean that you have to use hacks.
  36.  
  37. Ok, I'll provide both and we'll se how the user decides.
  38. you would probably be the only one in this sloar system selecting
  39. "writepixelarray8()" on a vanilla A1200 ;)
  40.  
  41. : >Well, the medium version, checking for native bitmaps (can I assume
  42. : >blitter present then ?)
  43.  
  44. : No. Why ?
  45. mhm haven't you told me native = planar & in chipmem, and isn't chipmem
  46. something you can blitter around ?
  47.  
  48. : >and using less optimal 4 pass blitter should
  49. : >also still be a la RKM,
  50.  
  51. : Sure. I don't call this is a hack.
  52. yep so everybody's happy :)
  53.  
  54. : >but will loose on 2x2 quite much speed
  55. : >vs the hack.
  56. : >realtimish demos on 1x1 will also loose quite some fps.
  57.  
  58. : That's your opinion.
  59. why is this not your oppinion ? you mean 3 pass is not faster than 4
  60. pass ? you must be joking.
  61.  
  62. : >So if user got AGA and PAL he will be happy chosing the hack.
  63.  
  64. : Ah sure. He probably also feels happy that you didn't write
  65. : software that works on his next Amiga model because there
  66. : is no such model.
  67. So if user got no AGA or no PAL, he will be happy (?) selecting
  68. writepixelarray8().
  69.  
  70. : >|> >yes, in can optimize that way, but this could still be less ideal
  71. : >|> >than direct render to vram.
  72. : >|> 
  73. : >|> Sure. In the same way that WaitTOF() could suddenly busy-wait, no ?
  74.  
  75. : >Do I read this right as "I don't believe direct render can be faster" ?
  76. : >not in demos with realtime-fx, especially 50Hz ones ?
  77.  
  78. : No, you don't read this right. You simply _assume_ that the driver is
  79. : less than ideal than direct render to vram. This assumption is as
  80.  
  81. No. I say direct render could be faster. You said "No", you don't believe
  82. that there is a case where "direct render can be faster". There has been
  83. code proving you wrong in practice.
  84.  
  85. : valid is your other assumption about WaitTOF() to use busy-waiting.
  86.  
  87. I assume there exist drivers that do this. you told me. you told me
  88. not to use hi-pri waittof therefore. you flame about things you did
  89. tell.
  90.  
  91. : >struct display *getdisplay(320,256,8,MODE_DIRECT_RENDER|MODE_LORES);
  92.  
  93. : Sorry, fails.
  94.  
  95. how you want to know ? you don't know what my function does.
  96.  
  97. "fails." really useful answer...
  98.  
  99. : >Well, heehee, there have been cases where even a A1200 rendering to
  100. : >_CHIPMEM_ was faster than using fastmem+copy.
  101.  
  102. : Sure ? And there have been cases where it was slower.
  103. yes, sure. and yes, there are cases wher it is slower.
  104. conclusion: you get most power is interface can handle both.
  105.  
  106. : >This proves my point 
  107.  
  108. : No.
  109. this proves my point that direct render sometimes is faster. TAIC.
  110.  
  111. : >(which is "rendering to vram could be faster on a certain machine
  112. : >running a certain gfx-engine").
  113.  
  114. : You said that you need direct rendering to vram _because_ that is
  115. : faster. And that's wrong.
  116.  
  117. I need this possibility as there are cases where it is faster.
  118.  
  119. : >mhm, how does your idea handle the case "direct render" ?
  120.  
  121. : I don't care. I might even support this as an unportable exception.
  122.  
  123. I know :)
  124.  
  125. : But more likely I would make the driver API include those higher
  126. : level functions that would benefit from direct rendering. The user
  127. : code can then ignore this topic algotether.
  128.  
  129. what ? how to direct render if OS doesn't support it ?
  130. a hidden hint to bang the hardware by YOU ? ;) can't be ;)
  131.  
  132. : >ugh. look at all those "cool workastions", SGI, wow how cool it is,
  133. : >we love it, but no fullscreen animation, or jerk jerk. just because
  134. : >they got no lores.
  135.  
  136. : No. Because the system software does not support fullscreen animation.
  137. I bet the cheaper ones, the ones only costing as much as 20 A1200,
  138. got no zoom hardware anyway.
  139.  
  140. : >The philosophy of Amiga has always been beeing efficient.
  141.  
  142. : Poking hardware isn't efficient from a broader view.
  143. yep.
  144.  
  145. : >At least the AMIGA hardware can do it, but some people tell 
  146. : >not to use it ;)
  147.  
  148. : If that produces junk, sure.
  149.  
  150. On a vanilla A1200 it doesn't ;) Actually the only thing that can
  151. make my copper hack crash is - the OS! If 4.0 will make it crash
  152. I will ask myself why I didn't overtake the copper with a 080 poke.
  153.  
  154. : >that's ok, if it can be done far beyond a frame (it's DMA should not
  155. : >slow down direct render) then it's ok.
  156.  
  157. : Why ? It could still be faster than anything you are using now.
  158. yep. but not faster than same machine having lores, if blitterdma
  159. should brake cpu copying to vram.
  160.  
  161. : >But wouldn't it be more annoying if you got a quick cpu but run also 
  162. : >quarterscreen due to not having lores ? would be really lame.
  163.  
  164. : I know what is lame.
  165.  
  166. I don't believe ;)
  167.  
  168. : >no. If I had designed the interface, setdisplay(struct display *) would
  169. : >handle the outzoom without application noticing it.
  170.  
  171. : Your interface would just work on one hardware. Same as your c00l
  172.  
  173. It would outzoom withouth aplication noticing it.
  174. It would be efficient, especially if hardwarezoomers available.
  175.  
  176.  
  177. : -- 
  178. :                                 Michael van Elst
  179.  
  180. : Internet: mlelstv@serpens.rhein.de
  181. :                                 "A potential Snark may lurk in every tree."
  182.