home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 2966 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.9 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: 7 Feb 1996 14:32:42 GMT
  6. Organization: Information Services, The University of Sydney, NSW, Australia
  7. Distribution: inet
  8. Message-ID: <2450.6612T66T607@wr.com.au>
  9. References: <4f6r3u$2db@sinsen.sn.no> <4f79mo$emb@serpens.rhein.de> <4fa2ru$13mk@columba.udac.uu.se>
  10. NNTP-Posting-Host: dialup36.wr.com.au
  11. X-Newsreader: THOR 2.22 (Amiga;TCP/IP) *UNREGISTERED*
  12.  
  13.  
  14. > Michael van Elst (mlelstv@serpens.rhein.de) wrote:
  15. >: tbk@sn.no (Thore Bjerklund Karlsen) writes:
  16.  
  17. >: >If you assume an
  18. >: >Amiga with native display, blitter and CIA should be there.
  19.  
  20. >: There you are. Assumptions instead of knowledge.
  21.  
  22. >: >Well known hardware.
  23.  
  24. >: So well known that most c0d3r stuff breaks on hardware they didn't have fo
  25. >: (and sometimes even there).
  26.  
  27. > Well, this discussion is getting a bit like a holy war, or so it
  28. > seems. I thought I might as well jump in with my two cents here...
  29.  
  30. > The point in demo programming getting the _most_ out of a certain
  31. > hardware configuration. As soon as the performance of commonly used
  32. > machines is increased, new demos are released to utilize it.
  33.  
  34. > Tell me, if I write a demo that crams the most out of a stock A500
  35. > with a rather complex display, would anyone be happy if it worked on
  36. > an A4000 looking exactly the same? I don't think so. The point is, to
  37. > the people on the seen the visual appearance of a demo is a rather
  38. > minor point. It's if it is _hard_ (or, preferably _impossible_) to do
  39. > that counts. (This is my impression, anyway, but feel free to correct
  40. > me if I'm wrong...)
  41.  
  42. > So, let's not deny that things will _always_ run faster (if it runs at
  43. > all) on a certain machine if the code is hand optimized for that
  44. > special piece of hardware with the best algorithms. This is quite
  45. > obvious, I think.
  46.  
  47. > On the other hand, if you want to write software for anything else
  48. > than to show off the limits of the hardware, then you should of course
  49. > instead put the main emphasis on the compatibility issues. The loss in
  50. > speed will mainly hit the low-end users, but if you concentrate on
  51. > using good algorithms, the result will be acceptable anyway. For
  52. > example, take Frontier. It runs with the workbench in the background -
  53. > there's even a patch available that lets you quit the game and return
  54. > to the workbench. So, it _is_ possible to do good games fully OS
  55. > compliant.
  56.  
  57. > I think that people used with hardware bashing are a great resource to
  58. > us, and that they could do a great job implementing algorithms that
  59. > are OS compliant. Of course, they will want to continue to develop
  60. > on-the-bone demos just to see where the absolute limits are...
  61.  
  62. > Flame, anyone? ;)
  63.  
  64. Nah :)  But just wondering, does Frontier use 100% system routines or
  65. does it hit hardware, making sure it's still friendly to the system?
  66. I don't think it uses 100% OS routines..
  67.  
  68.  
  69.