🚀 go-pugleaf

In article <1itc67INN4vm@life.ai.mit.edu> dmb@case.ai.mit.edu (David Baggett) writes:
>In article <1993Jan11.113722.5383@gdr.bath.ac.uk> mapmh@gdr.bath.ac.uk (M Hagger) writes:
>>I'm curious, just what do you mean by shitty programmers?  In the real 
>>world do you seriously expect game writers (ie people trying to screw the
>>maximum performance out of a machine) to worry about their program being
>>a little incompatible with future generations of chips?  
>
>Yes.  Case in point of bad programming of this ilk: STOS.  Every time
>the slightest change was made to the OS they had to send out an
>update.  You don't have to break the rules to get the best performance
>possible out of the machine.  Get things fast is one thing.  Getting
>things fast, and properly, is far better.
 
Hello, Dave.  I hope this doesn't sound like deja vu..  d:^)
 
I'm curious what "rules" there are on the ST!?  Please tell me because
Atari certainly hasn't.  Or should I spend my yearly allowance and
become a registered developer?  The Developers Kit certainly shows how
much Atari cares.  Maybe Atari should publish tutorials like CBM instead
of leaving it to Abacus...
 
I've never programmed with STOS (after all, I have dignity), but from
what I've seen of it, it seems unlikely that they could have used Line-A
calls, no?  Face it, the OS does not have adequate graphics functions!  You
aren't going to produce a polished *_SMOOTH_* running game under VDI.
Sure, go out and buy a '486/66 and write your games for it!  It seems
contradictory that you are touting the PC when 99.9% of the games for
that machine go straight to the hardware.  Demo coders have proven that
there are still some things that can be done with the ST hardware and
it's up to the game developers to catch up.
 
>>Particularly if they are not even aware of the these new machines etc
>>when the software is written.
>
>In some cases of course, they are victims of what you describe here.
>If the computer company rips the rug out from under the programmers,
>there's no one to blame but the company.  But Atari hasn't really done
>that; they've said  (in their own muddled way) what you could and
>couldn't rely on, and they've done pretty well at not screwing
>programmers who followed the rules.
 
Yeah..  By not releasing 68020/68030 machines until recently, eh?  Well, I'll
tell you that it's common knowledge the mistakes that Atari has made in
the original ST computers that has made it compatability difficult.
Remember who wrote TOS 1.0?
 
>
>>Maybe you would prefer it if the games were a little slower or a little less
>>impressive, but I certainly wouldn't.
>
>Following the rules will NOT slow your program down.  Game Workbench
>runs fine on Falcons and TT's, and we never had those machines to
>develop on.  It was more time-consuming, in some sense, to be careful
>to follow the rules, but doing so did not affect efficiency any.
 
Maybe you should compare your Game Workbench productions to games
written with "illegal" means?  Does Game Workbench have support routines
that do fine virtual (or token map) scrolling in 1 frame?  I'm not even
talking about sync scrolling (heavens!)..  I'd be very impressed if you
could show me a game with the same polish and smooth execution that is
seen in a Bitmap Bros. games or even Delta Force games (in Syntax Terror &
Punish Your Machine demos).
 
Do you honestly believe that your ST or STe sound routines will survive
upwardly compatable forever?  Is there even OS support for the STe DMA?
 
 
>
>Dave Baggett
>--
>dmb@ai.mit.edu           MIT Artificial Intelligence Laboratory                  
>ADVENTIONS: interactive fiction (text adventures) for the 90's!
>dmb@ai.mit.edu *** Compu$erve: 76440,2671 *** GEnie: ADVENTIONS
 
Paul Steffen
STratoHAK/TPPi