home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / sys / amiga / programm / 15763 < prev    next >
Encoding:
Internet Message Format  |  1992-11-12  |  3.2 KB
  1. Path: sparky!uunet!know!hri.com!noc.near.net!nic.umass.edu!caen!batcomputer!munnari.oz.au!bunyip.cc.uq.oz.au!news.qut.edu.au!qut.edu.au!podesta
  2. From: podesta@qut.edu.au
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: New hardware reference guide?
  5. Message-ID: <1992Nov13.085247.58456@qut.edu.au>
  6. Date: 13 Nov 92 13:52:47 GMT
  7. References: <Bx7782.CKD@kingston.ac.uk> <1992Nov5.184916.17436@sth.frontec.se> <1927@lysator.liu.se> <BxAMtH.Aos@cck.coventry.ac.uk> <36816@cbmvax.commodore.com>
  8. Organization: Queensland University of Technology
  9. Lines: 54
  10.  
  11. In article <36816@cbmvax.commodore.com>, peter@cbmvax.commodore.com (Peter Cherna) writes:
  12. > 
  13. > Well, we have extensive experience in figuring out why so many of these things
  14. > stopped working.  We looked at a bunch that broke when a 1MB Agnus was
  15. > installed.  We looked at a bunch that broke under ECS.  We looked at a
  16. > bunch that broke with the A3000.  A bunch that broke with 2.04.  A bunch
  17. > more that broke with AGA and 3.0, and sadly, we fully expect to have the
  18. > same darned problem next time we rev something too.
  19.  
  20. So what are some reasons that they break???
  21. I know some of mine broke because I wasn't blitter waiting everywhere.
  22. On faster machines, the processor would reach the next blitter job before
  23. the blitter was finished that last, while on A500s it would not and there
  24. would be no problem.
  25.  
  26. > 
  27. > From our experience, we've indeed seen some software that circumvents
  28. > the OS because that was the only way to achieve the effect desired.
  29.  
  30. Definitely true in demos. If the OS could do it, there would be no
  31. point in making a demo out of it.
  32.  
  33. > But by and large, the most common reason appears to be "NIH" syndrome (not
  34. > invented here).  It appears to be common to underestimate the performance
  35. > of the system routines, to misunderstand how to use the system routines,
  36. > to misunderstand the intricacies of the hardware, etc.
  37. > 
  38.  
  39. Underestimate the performance of the system routines?????????
  40. Come on, is that possible. True, that 2.x is much better than 1.x and
  41. 3.x sounds great, but there's still NO way your gonna write a game
  42. like Shadow of the Beast III that will run on a 1meg A500 using system routines!
  43. And to compete with the Console games, and to get people to buy your games,
  44. and just to feel proud of your games, you need to target that kind of level
  45. of speed, graphics and gameplay. There's no market for games and demos that
  46. only run on 68020 machines and above. Even when there is, this just
  47. means people will expect better demos and games so we still won't be able
  48. to go through the OS
  49.  
  50. > We frequently see code that goes to the hardware that is significantly
  51. > less efficient than it could easily be, or even than the OS is.  The
  52. > only thing which is rare in all of this is code which takes over the machine
  53. > completely and DOES work on all Amigas.  Perhaps you are among those who can
  54. > write code that works on most Amigas, but you're in the tiny minority...
  55.  
  56. In demos??? They must be pretty lame if some hardcoded effects are slower than
  57. the system software...Remember that demos and games can use the fact that
  58. they are not generic - we don't have to worry about window clipping or
  59. multiple tasks or I/O because these are all controlled.
  60.  
  61. > 
  62. >      Peter
  63.  
  64. James Podesta. ((soon) BappSci - Computing Honours :) a.k.a Rincewind
  65.