Newsgroups: comp.sys.amiga.programmer
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!elroy.jpl.nasa.gov!ames!vsi1!zorch!xanthian
From: xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan)
Subject: Re: Lemmings - a tutorial Part V (last)
Message-ID: <1991Mar31.144257.28633@zorch.SF-Bay.ORG>
Organization: SF-Bay Public-Access Unix
References: <781@tnc.UUCP> <mykes.0774@amiga0.SF-Bay.ORG> <2149@pdxgate.UUCP>
Date: Sun, 31 Mar 1991 14:42:57 GMT
Lines: 104

In article <2149@pdxgate.UUCP> bairds@eecs.cs.pdx.edu (Shawn L. Baird) writes:
mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes:

[ ... some stuff deleted ... ]

>> No sources will be posted here, but I have done a small game (in 3
>> days in assembler) that I do intend to publish source code to at a
>> future date. And believe it or not, it does not kill the OS to the
>> point that it can't be restored. In other words, it runs from DOS and
>> returns to DOS, but it does NOT multitask.

[ ... some stuff deleted ... ]

>> When the Amiga first boots, it asks for a workbench disk. If you have
>> an autobooting hard drive and a bootable floppy is inserted, the
>> machine will boot from the floppy. In any case, the ROM Kernel loads
>> what is called the boot program from track 0 of the floppy disk into
>> RAM and does a JSR to it. The standard Amiga OS bootsector program
>> simply opens dos.library and then does an RTS and the system
>> continues to boot up into the normal Operating System.

>> Well, I wrote my own boot sector program that just doesn't return to
>> the OS. In this boot sector program, I call several ROM Kernel

[ ... rest deleted ... ]

> I'm a bit confused here. First you say it runs from DOS and returns to
> DOS. Then you say you wrote your own boot sector program that doesn't
> return to the OS. Which of the two is true? I suspect that, although
> you save the state of the OS there really isn't a reason to do so. Not
> only this, but using a custom bootblock will render the game only
> bootable on floppy disks and (from the descriptions of doing all of
> the floppy reading on your own) the disk itself will not be in
> AmigaDOS format, therefore there will be no way to install your
> program on a hard drive. What is the point of keeping the OS state
> when even if you did return to it the user has had to reboot at least
> once just to get started?

OK, since even Mike's followup to this didn't clarify the situation
much, let me try. I've sat and had Mike walk me through his "standard"
game code at greater length than he's described it here, and I just beta
tested the example game he was describing (easy since we share a host
machine).

The problem is, you've taken two different subjects for one.  Read Mike's
above two quoted excerpts as:  1) I have this example game showing the
basic principles I use, and it works like this; versus 2) When I make a
real commercial game for the Amiga, it works like this.

In fact, I took his example game, stuck it in Rad:, and ran it from the
command line. It is a pretty impressive example of the "fly a spaceship
down a corridor and shoot at gobs of nasties who are busily shooting
back, grab the various fuel and other pods before they get by, etc."
variety. It is highlighted by amazing graphics, a scrolling starfield
below the platform over which you fly your ship, that is three layers
deep and gives the perspective of depth as it moves by, sparkling
graphic imagry, thanks to an artist friend of Mike's, things just
_flying_ around.  It most reminded me of the old Apple ][+ game "AE"
in terms of the number and variety of nasties in sight.

No sound, but I only uploaded 49K of program! It used the usual
misdirection to achieve the illusion of higher performance from my stock
processor A2000; probably two thirds of the screen area was a static
frame and status display; all the dynamic stuff was being done in the
other 1/3 of the screen. That translates into lots less pixels to move
about. Everything but the stars seemed to be built out of the 16x16
tiles he described in a recent rec.games.programmer article. The tiles
that looked like open fretwork really were, you could watch the stars
slide by under them (more misdirection, but that's what I saw!)

Eventually I managed, after losing a couple of dozen games in a row (I'm
47, fuzzy eyed, and have a gimp arm, I'm never going to be an arcade
champ again) to evoke a bug (it _was_ a beta, after all), one of the
sprites smeared itself over the screen two centimeters wide and screen
height. I followed the directions for exiting the program, (touch a
mouse button), and despite the bug, I was right back in the workbench
looking at the shell window from which I had evoked the game, with
normal operations, no problems.

Just as he described, his game nuked multitasking while running, but
gave it back when done, good as new.

The most impressive thing was that this is a game Mike cobbled together
from standard parts, some artwork by a friend, and his usual code, but
slewed clear out of its normal environment to coexist with the OS, it
fit in 50K of code, he got it running in three days, and it's
_addictive_; clean up the bug and he could be selling it in the stores.

I don't much care for Mike's nuking the OS, and coding primarily at the
assembler level, but lose the arguments that his development therefore
_necessarily_ has to take a long time or that the game's playability
_must_ get lost when he's fighting assembler. He's got a great toolbox
of tested code, and it is a productivity engine, even in assembler.

I may disagree with him a _lot_ (we just started talking again at all
after long silence), but he's damned good at what he does, it supports
him in the good life, and he has a lot to teach about programming the
way he likes to do it, and he deserves to be heard by those wanting to
get a start programming the bare metal to make the big bucks.

Kent, the man from xanth.
<xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>
--
"Now if he'd just let me multitask from the HD!" -- Mr. Incorrigible  ;-)
