🚀 go-pugleaf

In article <1ivp1aINNpgj@life.ai.mit.edu> psteffn@hal.gnu.ai.mit.edu (Paul Steffen) writes:
>Hello, Dave.  I hope this doesn't sound like deja vu..  d:^)

Oh NO!  :)

>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...

Like I said elsewhere, I'm not about to claim that Atari did a good
job w.r.t. getting the "rules" out there, but there are plenty of obvious
rules of thumb that common sense dictates.  E.g.,:

	1. Your program should run from hard drives, not just drive A
	2. You shouldn't write self-modifying code.  Chips with 
	   instruction caches have been part of the Motorola line for
	   years now, and to think Atari would never go beyond the 
	   68000 is silly.
	3. Relying on any global system variable which isn't in the
	   Atari docs (also in the Megamax, Lattice, and MWC docs)
	   is RIGHT OUT.  There is NO reason to do this for games.
	4. Assuming you own the whole machine is also bad.  Again,
	   anyone should have seen multitasking coming to the ST
	   line; it's been around on personal computers since 1985 or
	   so.  Along with this are little things like not assuming
	   the screen is at $78000.

None of these things is hard to figure out or dificult to follow.  And
games are pretty simple, really; they don't need to do much but play
sounds and put images on the screen.  There's no need to use
undocumented traps or assume things about where the screen is in
memory.  Such practices are the product of ignorance or laziness.

(And though I said games are simple, I don't mean they're easy to
write.  The algorithms are straightforward; it's just that you have
to spend a lot of time optimizing them.)

>Face it, the OS does not have adequate graphics functions!  

Well I didn't mean that people whould write games using the VDI.
Obviously assuming the screen memory layout is ST low rez is not
so great in the long term, but that actually is an assumption you
have to make to get decent performance on an 8 MHz ST.  Given this,
Atari has done the right thing in making sure this video mode has
been supported in all their machines.

You have to assume some things, of course, like the fact that if you
put some data somewhere in memory, it'll be there when you come back to
it.  :)  The point is that many of the assumptions made by game
programmers have been unreasonable, and therefore losing.

>It seems contradictory that you are touting the PC when 99.9% of the
>games for that machine go straight to the hardware.

Doing graphics on the PC is difficult, but the situation is quite
similar to the ST in terms of required assumptions.  You have to assume
a certain screen memory format (as well as where the screen is mapped
into memory, of course, since the video ram is separated from the
normal ram), but that's about it.

>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.

While that's true, many times the demo techniques are inappropriate for
games because they're too memory-intensive or demo-specific.

>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?  

You should really ask Neil about his scrolling routines.   Send email
to <neil@cs.heriot-watt.ac.uk>.  BTW, you can most definitely do fine
omni-directional scrolling with tokenized maps in 1 frame.  Not only
that, but GW will even compare sprite vs. map token priorities and
over/underlap sprites and map tokens in real time if you want.  (Did I
mention the collision checking?)  These are all things you can set
right in the sprite editor -- you set the priority of each frame of a
sprite and it just goes under and over things appropriately.
Generalized, easy-to-use, works on all Atari machines.  It can be done.

>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).

As I've mentioned before, the Bitmap Brothers' scrolling routines are
somewhat inferior if you really take a look at them.  There are more
sophisticated (but legal) techniques than they use.  Again, ask Neil
about it -- that's his specialty.

It really is too bad that Neil and I never wrote a scrolling game to
show off GW.  The scrolling code was only ready late in the project,
and by that time I was devoting so much time to the system itself that
I really had no time to spare on a scrolling game.  (We have demos to
test the thing, of course, but that's hardly what people would want to
see.)  It takes a lot more work to design a good scrolling game than it
does to do pacman.  And I'm a really terrible artist, and was unable to
find anyone willing to invest the 1000 or so hours to do all the
graphics for a freeware scroller.

>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?

Yeah, as long as there's a PSG in the machine mapped to the same
locations in memory.  There's nothing "unsupported" about the sample
playback routines.  (They do work on the Falcon, by the way.)  The only
fiddly bit is a movep instruction, and Atari has documented its abuse
in that case.

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