home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 2679 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  6.3 KB
  1. Path: munnari.OZ.AU!metro!metro!news
  2. From: accolyte@wr.com.au (Accolyte)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: Demo/game to OS frien
  5. Date: 3 Feb 1996 13:29:11 GMT
  6. Organization: Information Services, The University of Sydney, NSW, Australia
  7. Distribution: inet
  8. Message-ID: <5927.6607T1391T965@wr.com.au>
  9. References: <4e8h9j$mp5@sinsen.sn.no> <4e8pk2$ntm@serpens.rhein.de>
  10.     <3873.6603T379T952@wr.com.au> <4ekma4$8b@serpens.rhein.de>
  11. NNTP-Posting-Host: dialup03.wr.com.au
  12. X-Newsreader: THOR 2.22 (Amiga;TCP/IP) *UNREGISTERED*
  13.  
  14.  
  15. >>> You are already dead at that point because you don't know how to
  16. >>> handle incoming interrupts.
  17. >>
  18. >>What??!? :) I know very well how to handle interrupts. You don't need
  19. >>the system for it.
  20. >
  21. > Don't laugh. You do not know how to handle interrupts from sources you
  22. > do not know.
  23.  
  24. Aha I see what you mean.. hmm.. in that case, I think an option to use
  25. system interrupts might be a good idea. But, it is important that there
  26. also be the option to take over interrupts, for people who like the
  27. speed.
  28.  
  29.  
  30.  
  31. >>>>C0d3rz  that  produce  bad code are not C00l at all.
  32. >>> No ? But they act as if they were.
  33. >>
  34. >>You're avoiding his point, again.
  35. >
  36. > I don't think that he has a point here.
  37.  
  38. Whether he did or not, there isn't enough quoted for me to remember ;)
  39.  
  40.  
  41.  
  42.  
  43. >>Yes you do. You say anyone who programs without the OS sucks.
  44. >
  45. > No, I don't. I say that everyone who programs _against_ the OS and
  46. > who relies on pure assumptions produces bad code.
  47.  
  48. Aha.. can't complain about that then. So you don't mind someone stealing
  49. the copper in their game for example?
  50.  
  51.  
  52.  
  53. >>Name some OS-friendly games, and some hardware-bashing game. Then
  54. >>lets compare the quality.
  55. >
  56. > Unless you can prove that the hardware-bashing games are of higher
  57. > quality than the OS-friendly games _because_ of their hardware-bashing
  58. > that's a pretty meaningless comparison.
  59.  
  60. Fair enough.. But unless you can find two equivalent programmers, and set
  61. a task for each of them, that's not going to happen.
  62.  
  63.  
  64.  
  65.  
  66.  
  67. >>> way because nobody notices. Gameplay doesn't suffer if you can render
  68. >>> 10% less pixels but the c0d3rz' ego does suffer.
  69. >>
  70. >>10% a ridiculously small figure.
  71. >
  72. > No.
  73.  
  74. Yes.
  75.  
  76. We're not making much progress are we :)
  77.  
  78.  
  79.  
  80.  
  81. > If you believe that you have to always "call a subroutine to plot a single
  82. > pixel" then this is right.
  83.  
  84. I *know* you don't have to call a subroutine to plot every pixel!
  85. Christ.. :)  It's as much an exaggeration as your concept of the typical
  86. "c0d3r".
  87.  
  88.  
  89.  
  90. >>>>Do you seriously believe
  91. >>>>that  a standard A1200 would have had any great games if everybody used
  92. >>>>the OS?
  93. >>>
  94. >>> Sure.
  95. >>
  96. >>You are mistaken.
  97. >
  98. > Well, then let me clarify. If something is preventing great games by
  99. > using the OS then it is the c0d3rz.
  100.  
  101. Uh.. Can you clarify that clarification? ;) How are "c0d3rz" stopping
  102. great games through 100% OS calls? Actually don't answer that unless
  103. you can put it in a sentence without the word "c0d3r", because I'm
  104. not sure what you mean. Anyone who hits hardware? Or anyone who hits
  105. hardware and doesn't have enough experience? <shrug>
  106.  
  107.  
  108.  
  109. >>>>I dare you to name ONE great game using *only* the OS!
  110. >>> I dare you name one c0d3r that actually tried.
  111. >>
  112. >>There you go again, avoiding the question because you can't answer it.
  113. >
  114. > I can answer it. But then you will reject my idea of "great game".
  115.  
  116. I guess we have different definitions. I expect a great game to be playably,
  117. and to run well on a modest system. Best if it takes advantage of
  118. accelerators and extra memory for example. It seems that for an OS game
  119. to be average it has to piss all over lower-end systems..
  120.  
  121.  
  122.  
  123.  
  124.  
  125. >>Whether a hw-coder tried or not is irrelevant.
  126. >
  127. > No, it isn't. You argue that the OS is bad (for game programming) because
  128. > otherwise there would be great games that used the OS. Don't you think
  129. > there could possibly be other reasons ?
  130.  
  131. Aha, I see.. of course there's other reasons. But I still say that given
  132. equally good coders - one who's into hw-hitting and one who refuses to use
  133. anything but system routines, the hw-hitting game will come out on top
  134. every time. Even if they only use the hardware for portions of the game.
  135. Remember, hitting hardware doesn't mean forsaking the OS completely.
  136.  
  137.  
  138.  
  139. >>Not rubbish. Do you think that hw-programming means you can't support
  140. >>faster machines?
  141. >
  142. > No. I think that faster machines are not supported by c0d3rz. That's a
  143. > difference. The reason is that c0d3rz base decisions on mere assumptions
  144. > (like: "self-mo code isn't going to break with caches" or "blitter-nasty
  145. > will stop the CPU u the blit is done").
  146.  
  147. I think your abuse of the word "coder" must be useless in arguing against
  148. hw programming. It seems to define the programmers that bang hardware AND
  149. suck. You do believe that it's possible to write hardware-banging code
  150. that's acceptable, don't you? Come on, how many self-respecting programmers
  151. forget to disable caches if they're going to self-modify code? And the
  152. "blitter-nasty trick" is plain stupid. If those mistakes really are common
  153. I'm not impressed.
  154.  
  155.  
  156.  
  157.  
  158. >>> Maybe it is not fast enough (which I don't believe and which is only
  159. >>> half of the story anyway). But the problem is that this argument comes
  160. >>> independent of the hardware you do have which simply means that the
  161. >>> argument is wrong and you must have another reason.
  162. >>
  163. >>Er.. interesting logic there ;)
  164. >
  165. > Well, either my logic is right or there is no logic reason for c0d3rz to
  166. > bang hardware.
  167.  
  168. The problem doesn't come independantly of hardware. We know what hardware
  169. we have - it's called AGA. AGA is our friend. Copperless chunky-only
  170. graphics cards can take a hike as far as I'm concerned.
  171.  
  172. Also, there are other reasons beside speed. What do you do if the original
  173. programmers of the OS didn't think of a technique you wanted to employ?
  174. No, I don't mean dodgy techniques like the ones you mentioned above - there
  175. are some quite valid things that simply won't work with the OS.
  176.  
  177.  
  178.  
  179.  
  180.  
  181.  
  182. >>We should really get you into IRC one time, this isn't getting anywhere
  183. >>in messaging.
  184. >
  185. > Ah.. That's again _pure_ c0d3r style. Why do you assume that I am _not_
  186. > on I Did you ever have a look ?
  187.  
  188. Ah.. that's again _pure_ OSlamic fundamentalist style. Why do you assume
  189. I'm ignorant (no comments you ;) ) when it's more likely I screwed up by
  190. making the statement ambiguous. I *know* you're on IRC. By the above, I
  191. meant some of the hw coders should meet some of the OS only coders in IRC.
  192.  
  193.  
  194.  
  195.  
  196.  
  197.