Club Amiga de Montreal - CAM/CAM_CD_1.iso/files/605a.lha/Worm/Worm.doc

Text File | 1992-01-12 | 9KB | 147 lines

            WORM 47.023, ±.0000519

        By Paul Trauth, with special guest coder Jason Fonseca.
        Invaluable debugging help: David Vazquez (two heads are
                                           better than none...)

    I've written this little hack too damn many times. This is its latest,
and hopefully last, incarnation. This incarnation is of minor interest,
being as it is my first Amiga program, unless you want to count "Feh" in
its two or three incarnations. (I'd rather not.) Actually, it's not really
my first any more; I've written a couple of demi-demos, but this is my first
code that talks politely with the system instead of giving it the old heave-
ho. (Politely, but still the ol' heave-ho.) As far as I can tell, it lives
with the OS rather well, with the possible exception of not checking for
success in opening libraries. But then again, if you can't open
intuition.library or graphics.library, you most likely won't be able to get
this file loaded in anyway, since other crucial, ROM-resident libraries might
not be there either. You have been warned. (And if anyone knows a good reason
to be a good li'l coder and always check, and can give an example of when it
WOULD fail, let me know, and I'll start being a good boy.)

    This *final* version was written on January 10-11, 1992, last assembly
at around 4:15 AM. Yes, it sat around for a LONG time before gettin
finished; the last time I touched this was sometime in early to mid '91. I
used Devpac 2 to code and DPaint 3 for the images, though I converted the
sprites to hex data by hand. This was before I got nifty IFF hacking tools.

    This is probably the smallest screen hack out there, especially for
what it does. The executable is under 2.5K, a bit more than a third of the
size of the source, and quite smaller than this documentation (quite
possibly some of the worst [but not the least amusing] documentation
written by a native speaker of English!) as well. By the way, it DOES have a
potential use: on those long compiles, you can try and trap the worm in a
corner. It CAN be done, although eventually it tends to find a way out.

     A techie note of minor interest:
     The worm's XY coordinates are kept internally on a 1280×800 grid,
plotzed down to a 320x200 grid for output. This keeps things nice and
smooth, especially on those turns. Any more tech stuff, you gots to figure
out for yourself by staring at the vaugely commented source for hours on
end. At least I was nice enough to include source... working assembly is SO
hard to find, except for ripped demo sources. (Pleh. If I'm gonna take over
the system, I wanna run my OWN bad code, not bad code swiped from somebody
else...)

    And now, here's most of the doc file for the last version, thanks to
the wizardry of cross-file cut-n-paste. (I _love_ DME.)

----------------------------------------[Don't cut here.]-------------------
    What can we say. We apologise for this hack. It slipped out one long,
long night...

    Revision History.

    (No dates for older versions, we're senile already.)

    Original Concept and Algorithm (Sort of) from a 'Computer Recreationz'
column in Scientific American. Original was on an (ecch) IBM, using SIN and
COS and other (ugh) Trig functions to calculate.
    Totally re-hacked from the ground up into 6502 on a C64 by Paul Trauth,
using all 8 available sprites for worm display, as well as some totally
obnoxious sound effects. Used LOTS of little 16-byte long tables.
    Re-re-hacked on the Amiga in Benchmark Modula-2 (because it was all we
had sitting around, ugh) from about 10 PM 2/1/90 to 8 AM 2/2/90 by Jason
Fonseca and Paul Trauth. Mostly Jason wrote this version, Paul just sat
around converting the graphics into hex (yeecccchhhhh) numbers and offering
incoherent explanations of how his original C64 version worked.
    There were about four versions once we got the main engine running
(ooh, don't we sound professional?)... at first the worm didn't give a
flying about the pointer. We still have this version sitting around, just
because we like nostalgic moments. ("Wow, remember when all it would do was
wander around at the speed of light and go off the screen, coming back
every hour or so?" "Yeah, those were the days...") Then we decided that
that was kinda tacky. So we made the worm stay on-screen, after four or
five crashes and re-boots. (Not to mention all the crashes just trying to
get the SPRITES up in the FIRST place!) And now look what we have, this
completely multi-tasking (well, OK, it's not REALLY multi-tasking 'cause
you can't close it, but that's only because we couldn't get a window up
without it crashing...[But at least it multi-tasks with itself! Yep, that's
right, you can actually run multiple copys and it won't crash! It's really
annoying, what with the flicker and all, but hey, you can do it.
Nyaah.]...but that's coming in the next revision. Maybe.) little screen
hack that runs away from your pointer and even runs away from the right
spot on the screen! In fact, if you just let your mouse alone, the worm
will NEVER (Never never never ever never no, not never, well, maybe every
once in a while) run into the pointer because of the special neural network
we designed for it. Not really. We just thought that would sound good.
Actually, this is an excellent example of 'Goal-Directed Animation',
whatever that may be, I dunno, but it sounds good.
    We're proud of our little blue worm. Really. Trust us. Look for the
next release coming out Real Soon Now that might even have a close gadget
on it. And an icon. A real nice icon. The icon would have been on this
release but Paul left the disk with it at home. And of course there are the
other silly ideas, like several worms avoiding each other done with
VSprites, a few little tanks running around like the worm head constantly
pointing their turrets at the pointer, and other silly shit like that.
    Disclaimer (Every silly little program like this has to have an
obnoxiously obvious disclaimer.): We take no responsibility for any
crashes, memory loss, hairy palms, blindness, insanity, hardware damage,
dismemberment, or death that may occur through use (or abuse [How the hell
do you abuse this thing anyway?]) of this hyah little bit 'o wonderment.
    Disclaimer II: Jason had nothing whatsoever to do with this doc file
(at least that's what he wants YOU to think!); Paul typed it all. I make no
apologies for this file, it's late. No, early. Er...

    Thank you for your [lack of?] support.

-------------------[Still don't cut here.]----------------------------------
    Most of that silliness applies here, too. This version was developed
over a period of a few weeks, er, actually, most of a year... It would have
taken a LOT less time, but I just wasn't in a coding kind of mood for a
good part of that period, and for much of my coding moods, I was working on
other stuff... (an adventure game, a demo, my own blob routine... none of
which are finished. Figures.)
    This version DOES have a fully functional close gadget, I liked the bit
about not having one so much I just had to leave it in.
    Some 90% or so of this version was entirely designed by me, Paul.
(...You Jane? er...) I think that Jason was there (back-seat coding) while
I wrote the first version of the sprite-grabbing routine, which was
initially _much_ nastier. It originally made quite sure that it would be
able to get all the sprites by freeing them first. We eventually decided to
be nicer to other programs, and the Worm will now quietly suicide if it
can't get sprites 2-7.
    And, of course, David helped me sit here and figure out just why the
@#$% it wasn't positioning the sprites correctly. Arrgh.
    I seriously doubt this will work on 2.0. If this section of the docs is
still here when you read this, I haven't tried it. My coding techniques are
just manaical enough to have a good chance of crashing and burning under
2.0, and since I don't have $3-4000 or so lying around to get a 3000, or a
handy friend who did, or for that matter $100 to buy the ROM chips for my
zebra-striped 2000, I can't test it too readily.
    Oh. By the way. Jason gets 50% of full credit for the mouse pointer
avoidance algorithm. While the smooth, fast rotation routines and tables
were created by me for the first C64 version, we both busted our skulls
over that pointer avoiding bit. I get a headache just thinking about that
night.
    If you have any comments, job offers (Ha!), money (Ha! Ha!), spare SCSI
hard drives or whatnot for me, send 'em to:
    Paul Trauth/Ducksoft
    4752 Press Drive
    New Orleans, LA 70126

    Electronically, I can be reached on Usenet:
    paul_trauth@agwbbs!new-orleans.LA.US

    Enjoy.