>After I got VERY used to Nick's How To Draw a
>Playfield file as a template for EVERY demo/game I've
>done thus far, I decided it's time to un-assemble,
>using DiStella, a game and "see how they did some
>things". Wow, was I in for a shock.
>
>I chose Space Jockey (I know, it's pretty boring)
>because I liked the way the flying saucer sprite
>rotated...it just seems to work so smoothly.
>
>Anyway, the code was insane. And I don't mean that it
>was too hard to figure out...just that it was
>spaghetti code...I was appalled that it even worked!
>After spending three days "untangling" it, I figured
>out how to successfully code it like Nick's template.
>
>Have you guys found that this is the general case on
>some of these games?
Remember that just because something's done in an official 2600 game doesn't
mean that it's the best way to do anything. I'd guess it's mostly just a
function of how the programmer likes to do things. If s/he/it was a C
programmer taking his first steps into assembly, it'll probably have a lot
of spaghetti, with lots of subroutine calls and such and just generally
inefficient coding. If it came from an assembly veteran, it'll be
straightforward, except where it needs to not be to be fast or compact or
both. I'd wager that the source of my own INV is a lot cleaner (except for
the invader-kernel bit which illustrates the latter part of the previous
sentence) than something that a complete assembler newbie like Pete Holland
on this list would be writing. Certainly later in its lifespan the 2600 had
a high number of inexperienced programmers writing for it, to say the
least...
--
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
