home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / sys / atari / st / 19685 < prev    next >
Encoding:
Text File  |  1993-01-12  |  3.4 KB  |  68 lines
  1. Newsgroups: comp.sys.atari.st
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!sdd.hp.com!usc!cs.utexas.edu!torn!utgpu!gbcusg
  3. From: gbcusg@gpu.utcs.utoronto.ca (I. Barnett)
  4. Subject: Re: The compatibility story (Falcon & A1200)
  5. Message-ID: <C0r8Ew.Cyx@gpu.utcs.utoronto.ca>
  6. Organization: UTCS Public Access
  7. References: <1993Jan10.110720.14311@umiami.ir.miami.edu> <1993Jan10.171538.26344@news.uit.no> <1993Jan11.113722.5383@gdr.bath.ac.uk> <1itc67INN4vm@life.ai.mit.edu>
  8. Date: Tue, 12 Jan 1993 18:52:08 GMT
  9. Lines: 57
  10.  
  11. In article <1itc67INN4vm@life.ai.mit.edu> dmb@case.ai.mit.edu (David Baggett) writes:
  12. >In article <1993Jan11.113722.5383@gdr.bath.ac.uk> mapmh@gdr.bath.ac.uk (M Hagger) writes:
  13. >>I'm curious, just what do you mean by shitty programmers?  In the real 
  14. >>world do you seriously expect game writers (ie people trying to screw the
  15. >>maximum performance out of a machine) to worry about their program being
  16. >>a little incompatible with future generations of chips?  
  17. >
  18. >Yes.  Case in point of bad programming of this ilk: STOS.  Every time
  19. >the slightest change was made to the OS they had to send out an
  20. >update.  You don't have to break the rules to get the best performance
  21. >possible out of the machine.  Get things fast is one thing.  Getting
  22. >things fast, and properly, is far better.
  23. >
  24. >>Particularly if they are not even aware of the these new machines etc
  25. >>when the software is written.
  26. >
  27. >In some cases of course, they are victims of what you describe here.
  28. >If the computer company rips the rug out from under the programmers,
  29. >there's no one to blame but the company.  But Atari hasn't really done
  30. >that; they've said  (in their own muddled way) what you could and
  31. >couldn't rely on, and they've done pretty well at not screwing
  32. >programmers who followed the rules.
  33. >
  34. >>Maybe you would prefer it if the games were a little slower or a little less
  35. >>impressive, but I certainly wouldn't.
  36. >
  37. >Following the rules will NOT slow your program down.  Game Workbench
  38. >runs fine on Falcons and TT's, and we never had those machines to
  39. >develop on.  It was more time-consuming, in some sense, to be careful
  40. >to follow the rules, but doing so did not affect efficiency any.
  41. >
  42. >Dave Baggett
  43. >--
  44. >dmb@ai.mit.edu           MIT Artificial Intelligence Laboratory                  
  45. >ADVENTIONS: interactive fiction (text adventures) for the 90's!
  46. >dmb@ai.mit.edu *** Compu$erve: 76440,2671 *** GEnie: ADVENTIONS
  47.  
  48. Anyone who has seen the box of GARBAGE that you get from Atari when
  49. you become a developer should know that all developers have nothing
  50. to start with when writing programs for the ST.  The tools (C compiler,
  51. assembler, resource editor) you get are the worst I've ever seen on
  52. any computer.  Game writers have no choice but to search through the
  53. OS for tricks to use.  I happen to think STOS is a great piece of  
  54. software.  Take the line-A fiasco that Atari has created.  All of a
  55. sudden, Atari has said that routines we have been using for years are
  56. illegal and we have to use the vdi routines which are S**T (hence the
  57. existence of warp-9 and nvdi). If it wasn't for the MWC manual and the
  58. abacus books, I would still be in the dark about programming the ST.
  59. Developers are the most important resource a hardware vendor has and
  60. Atari has shown their developers absoultely no respect.  No wonder
  61. Atari's programming 'rules' are being broken by programmer.
  62.  
  63. I will now step down off my soap box...
  64.  
  65. Darren King, GBC --> gbcusg@gpu.utcs.utoronto.ca
  66.  
  67.  
  68.