home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 2858 < prev    next >
Encoding:
Text File  |  1996-08-05  |  4.2 KB  |  124 lines
  1. Path: comma.rhein.de!serpens!not-for-mail
  2. From: mlelstv@serpens.rhein.de (Michael van Elst)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: Demo/game to OS frien
  5. Date: 6 Feb 1996 11:14:48 +0100
  6. Organization: dis-
  7. Message-ID: <4f79mo$emb@serpens.rhein.de>
  8. References: <4f6r3u$2db@sinsen.sn.no>
  9. NNTP-Posting-Host: serpens.rhein.de
  10.  
  11. tbk@sn.no (Thore Bjerklund Karlsen) writes:
  12.  
  13. >If  you code knowing that your program won't support gfx-cards, why not
  14. >also assume it is a standard Amiga?
  15.  
  16. BECAUSE PEOPLE HAVE OTHER HARDWARE THAN YOU.
  17.  
  18. *shit*
  19.  
  20. It's what we tell you all the time. You assume things that are incorrect
  21. outside your tiny little c0d3r world. That's why your stuff breaks.
  22.  
  23. >No  you  don't.   If  you  stop  the OS, only your own code is running.
  24. >Nothing to hack around.
  25.  
  26. Not even that is true because other hardware might still be running and interfere.
  27. And you have to know and observe more than with OS programming.
  28.  
  29. >>Well, I know that with HW programming (especially c0d3r style) you have
  30. >>to think about much more.
  31.  
  32. >How do you know that?
  33.  
  34. Because I know hardware and I know how to program it. What else do you think ?
  35.  
  36. >Please..   Pull the other one.  A VBLANK is defined as a VBLANK.  After
  37. >a  Loadview(0)  it  should  be 50/60 frames a second.
  38.  
  39. Of course that's not right. It could do 70 frames a second or 25.
  40.  
  41. >If you assume an
  42. >Amiga with native display, blitter and CIA should be there.
  43.  
  44. There you are. Assumptions instead of knowledge.
  45.  
  46. >Well known hardware.
  47.  
  48. So well known that most c0d3r stuff breaks on hardware they didn't have for testing
  49. (and sometimes even there).
  50.  
  51. >>>How  would  Turrican  2  be  using only the OS?  Shadow of the beast 3
  52. >>>Somehow I doubt it could have been done with the OS.
  53.  
  54. >>Maybe not exactly but pretty close.
  55.  
  56. >How  about  full  gfx-card  supporting  code,  TOTALLY  system-friendly
  57. >programming.  Would it still be "pretty close"?
  58.  
  59. Sure. That's what the system gives you. It is not limited to calling WritePixel().
  60.  
  61. >Gfx-card  support?   That's the only reason I can see for using the OS.
  62. >And that means using *only* the OS for gfx-rendering..
  63.  
  64. Do you know what OS programming means ? It means that you have a set of specifications
  65. for programs called an Application Programmers Interface and that you follow these
  66. specifications.
  67.  
  68. It doesn't mean calling WritePixel(). If the specs say that you can access the frame
  69. buffer here and there you can do that. If the specs say you can have your own interrupt
  70. services then you can do that. If the specs say that you must not access the interrupt
  71. table then you have to follow that rule.
  72.  
  73. >If it fails, it is shit code.
  74.  
  75. You mean close to all c0d3r stuff is shit code ? Then we agree.
  76.  
  77. >Yes,  but  what about those who have standard hardware?  Do you want to
  78. >scroll  an  8bpl-screen  with  the  blitter  on those machines, because
  79. >gfx-cards  don't support hardware-scrolling and copper-tricks needed to
  80. >get fast scrolling?
  81.  
  82. Why would I ? If a display is scrollable then I tell the system to scroll it.
  83. If the display is not scrollable then I have to move the bits accordingly.
  84.  
  85. >Oh, perhaps you're claiming there is another way of scrolling a screen?
  86.  
  87. No other method necessary.
  88.  
  89. >And I believe you answered something like:  "That's bullshit".
  90.  
  91. *sigh*
  92.  
  93. >"And  why  beholdest
  94.  
  95. Does this say something ?
  96.  
  97. >So tell me which interrupt could be different from what I assume!
  98.  
  99. For existing hardware this is interrupt 2 and interrupt 6 and possibly
  100. every vectored interrupt. These can occur and you have no way to know
  101. how to handle them.
  102.  
  103. >My machines?╗It has run on *EVERY* machine I have *EVER* tested it on.
  104.  
  105. Doesn't say much. No ?
  106.  
  107. >Hardware can't keep up with development, especially Amiga hardware.  If
  108. >gfx-cards  were  standard, I would certainly use the system.
  109.  
  110. Come on, that's the same shit your kind told "when 68020 were standard",
  111. "when 68060 were standard". When gfx-cards were standard then you surely
  112. would try to find a way to poke the gfx-card hardware.
  113.  
  114. >You *have* to use some tricks to get an acceptable result!
  115.  
  116. Oh sure. It needs lots of know-how to get an acceptable result. Mere assumptions
  117. of c0d3rz just produce junk though.
  118.  
  119. -- 
  120.                                 Michael van Elst
  121.  
  122. Internet: mlelstv@serpens.rhein.de
  123.                                 "A potential Snark may lurk in every tree."
  124.